Implement AnyView in xilem_masonry
#206
Conversation
| ) -> ChangeFlags { | ||
| // TODO: Does this need to have a custom view id to enable events sent | ||
| // to an outdated view path to be caught and returned? | ||
| // Should we store this generation in `element`? Seems plausible |
There was a problem hiding this comment.
It's not really decoupled from the widgets then, is it? (Which AFAIK is necessary, for views not being wired up directly with widgets but being able to receive events from somewhere else, async list is an example for that (via the waker that stores the current view id path)).
I think it's one of the reasons why View::build returns a ViewId, and rebuild is able to change it (e.g. in this method, because there's a new view).
There was a problem hiding this comment.
I don't follow how the suggestion in here would break views not directly hooked up to widgets.
You are right that this does need to resolved before merging though. The correct place for this state to go is actually in View::State, but that doesn't exist yet. The element is a Xilem specific widget, so it's fine-ish to include a simple counter.
There was a problem hiding this comment.
Yeah, this does need to happen in View::State.
This isn't actually problematic because we don't have async wiring yet, but the current state is wrong
|
This is in a far from perfect state, and it has confirmed that we need to bring back the But we're merging now despite that to unblock work |
xilem_masonry_anyview.webm