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
Conversation
|
bcde660
to
545a45d
Compare
There was a problem hiding this 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
545a45d
to
dee8b51
Compare
Seems there is a permissions issue with posting the results of benchmarking 😵💫 ready to rebase when that's fixed. |
Working on it |
243cf7f
to
0d306ff
Compare
dang that altert looks suspicious, let me re-run... |
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 |
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.
0d306ff
to
751fed2
Compare
Yea sorry just the env is unstable it seems. We can't assume that there are regressions yet |
29489bf
to
c713027
Compare
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. |
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 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. |
I will be gone for a month after 2 weeks. So github will probably slowdown a bit without me. |
@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) |
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"] |
There was a problem hiding this comment.
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.
There was a problem hiding this 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 |
There was a problem hiding this comment.
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>, |
There was a problem hiding this comment.
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 andRc<dyn smth>
to theComponentState<COMP>
instead.
I agree that we should do this. Want to create an issue for this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this 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
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 intovirtual_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. Nopub
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
cargo make pr-flow