Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce explicit internal datastructures modeling dom state #2330

Merged
merged 36 commits into from Mar 6, 2022

Conversation

WorldSEnder
Copy link
Member

@WorldSEnder WorldSEnder commented Jan 6, 2022

Description

Prior to this change, reconciliation of the virtual DOM works by mutating the incoming virtual DOM internally, taking an optional ancestor parameter.
With this change, for each (most) type of virtual node, there is an explicit second structure modeling the state that is relevant only after the virtual DOM has been applied (reconciled). In effect, this slims down some of the vdom structures and gets rid of some unwraps by making illegal state unrepresentable.

The introduced structure is called "Bundle" throughout the code, coming from the mathematical sense, meaning here "living above the virtual dom".

Tries to continue tackling #758. Most of the vdom should be more easily removable now that it is rid of state logic.

Should make it easier to implement #2154 as "host logic" (listener registration) can more easily be added to the bundle structure.

As a side effect of a change to the list reconciler, fixes #2327 .

Might impact future considerations in #1154.


Please apply the performance label.

How to review this change

Most of the test cases have been moved into the new dom_bundle module, as it tests how the vdom is reconciled and rendered. There might be some test cases that only inspect the vdom structure, but I've honestly not looked too closely. It might make sense to split those off (back into virtual_dom).

The change should be invisible to most, if not all users of yew. Please take a few minutes to double check that I haven't accidentally removed trait impls from vdom structures. Further moved methods are all internal (pub(crate)) to yew. No pub methods should have been moved.

Obviously, some fields have been removed or renamed in the virtual_dom structures, but I don't think this is defined as a "stable" public interface of yew?

Checklist

  • I have run cargo make pr-flow
  • I have reviewed my own code
  • I have added tests

@WorldSEnder
Copy link
Member Author

WorldSEnder commented Jan 6, 2022

Test cases seem to spuriously fail due to bumpalo = "3.9.0" not compiling on older releases of rust. Fixed now

See fitzgen/bumpalo@55b3fa5

@voidpumpkin voidpumpkin added A-yew Area: The main yew crate performance labels Jan 6, 2022
@hamza1311 hamza1311 mentioned this pull request Jan 6, 2022
3 tasks
@hamza1311 hamza1311 added this to the v0.20 milestone Jan 6, 2022
Copy link
Member

@voidpumpkin voidpumpkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To me all this looks good. Great work!

But i would like to see this PR benchmark results after we update the benchmarks in #2352

@WorldSEnder
Copy link
Member Author

Seems there is a permissions issue with posting the results of benchmarking 😵‍💫 ready to rebase when that's fixed.

@voidpumpkin
Copy link
Member

Seems there is a permissions issue with posting the results of benchmarking 😵‍💫 ready to rebase when that's fixed.

Working on it

@WorldSEnder WorldSEnder force-pushed the dom-bundle branch 2 times, most recently from 243cf7f to 0d306ff Compare January 10, 2022 20:51
@voidpumpkin
Copy link
Member

dang that altert looks suspicious, let me re-run...

@WorldSEnder
Copy link
Member Author

Might not be that suspicious after all, but I'll wait for some "normal" PRs to go through the benchmarking suit and see if they pass before I trust it. In any case, I'll have to check I understand what is measured and why it regresses

@WorldSEnder
Copy link
Member Author

Hm, similar "regressions" detected in #2337 which means you are right, something is fishy.

the new bcomp is especially nice and lost a few unwraps owed to not having
to reserve space for a scope before rendering.
Note also that bsuspense has been slimmed a bit, storing the suspended flag
implicitly in the state.
some naming is not perfect yet and has to be adjusted still.
@voidpumpkin
Copy link
Member

Yea sorry just the env is unstable it seems. We can't assume that there are regressions yet

@WorldSEnder
Copy link
Member Author

I won't bother merging master all the time while the old virtual dom is changing as rapidly as it is now, if that means I have to port conflict after conflict because git doesn't seem to understand how to resolve them naturally.

@voidpumpkin
Copy link
Member

voidpumpkin commented Jan 31, 2022

I won't bother merging master all the time while the old virtual dom is changing as rapidly as it is now, if that means I have to port conflict after conflict because git doesn't seem to understand how to resolve them naturally.

Yeah its a weird situation. Originally i was not approving PR's to wait until yours gets merged, but then every time I would check up on this PR it was super WIP. Later you even stated its not mergable.

If you want we can slow down for a week or something to let you catch up and merge this in.
@hamza1311 would you be ok with that?

@WorldSEnder
Copy link
Member Author

WorldSEnder commented Jan 31, 2022

This week is a bit stressful for me because of university, so the "pause" doesn't have to happen immediately, I'd much rather prefer to not add pressure before my exam anyway :)

I suppose #2421 could be merged in by next week, so unless @futursolo has any other planned PRs upcoming, maybe a good point in time would be after that one.

@hamza1311
Copy link
Member

hamza1311 commented Jan 31, 2022

I was waiting that hoping @voidpumpkin or @siku2 would review this before me and I can keep their review in mind. I haven't been able to sit down and focus on any PRs for the last little bit (my own PR is sitting with failing CI)

I'd be fine with not merging anything else until this one is in.

@voidpumpkin
Copy link
Member

This week is a bit stressful for me because of university, so the "pause" doesn't have to happen immediately, I'd much rather prefer to not add pressure before my exam anyway :)

I suppose #2421 could be merged in by next week, so unless @futursolo has any other planned PRs upcoming, maybe a good point in time would be after that one.

I will be gone for a month after 2 weeks. So github will probably slowdown a bit without me.
So you with this PR will be in @siku2 and @hamza1311 hands :)

@hamza1311
Copy link
Member

@WorldSEnder can you fix the conflicts? I'll make this PR the first thing I review after the conflicts resolved (I assumed it's mostly good because last time i reviewed it, it was fine)

@WorldSEnder
Copy link
Member Author

One last assignment due for uni, I'll see if I can get this done over the weekend

@@ -82,7 +82,7 @@ dependencies = ["test"]
[tasks.test]
private = true
command = "cargo"
args = ["test", "--all-targets", "--workspace", "--exclude", "website-test"]
args = ["test", "--all-targets"]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change should fix #2403 . As I understand it, tasks are inherited and run for all workspace members anyway, unless overwritten.

@futursolo futursolo mentioned this pull request Feb 23, 2022
3 tasks
hamza1311
hamza1311 previously approved these changes Mar 2, 2022
Copy link
Member

@hamza1311 hamza1311 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Sorry, it took such a long time to get reviewed

@@ -1,17 +1,16 @@
//! This module contains the `App` struct, which is used to bootstrap
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with keeping it here. If we support any platform other than web, then it'll have to but that's for the future.

pub struct CreateRunner<COMP: BaseComponent> {
pub initial_render_state: ComponentRenderState,
pub node_ref: NodeRef,
pub props: Rc<COMP::Properties>,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is possible (and I think worth doing) is removing the Boxes in scheduler and storing and Rc<dyn smth> to the ComponentState<COMP> instead.

I agree that we should do this. Want to create an issue for this?

Copy link
Member

@voidpumpkin voidpumpkin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@hamza1311 hamza1311 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good! Finally we can merge this in

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-yew Area: The main yew crate performance
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Keyed lists and reordering of multiple children
4 participants