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

Dynamic optional view #28

Open
keis opened this issue Aug 31, 2024 · 2 comments
Open

Dynamic optional view #28

keis opened this issue Aug 31, 2024 · 2 comments

Comments

@keis
Copy link
Contributor

keis commented Aug 31, 2024

Being able to use Option<View> as a view is very convenient but does not allow for the state Some/None to change. Being able to dynamically change this would be really useful.

I've been able to emulate something like this by stitching Cond together with a helper Unwrap ViewTemplate. So looks pretty doable to me but I've yet to fully wrap my head around the state tracking in quill works.

@keis
Copy link
Contributor Author

keis commented Aug 31, 2024

For reference my hacky solution right now looks like this

Cond::new(inner.is_some(), Unwrap(inner), ())

And the create of that Unwrap wrapper of Option looks like

fn create(&self, cx: &mut Cx) -> Self ::View {
    self.0.as_ref().unwrap().create(cx)
}

@viridia
Copy link
Owner

viridia commented Aug 31, 2024

I've run into this issue as well, and have resorted to similar ugly workarounds.

The basic problem is that normally, view states (that is, the associated type View::State) don't have runtime type identification, so dynamically changing the view type (in this case from Some<View> to None) means that the State type no longer corresponds to the view.

The cleanest solution, for now, is to wrap the optional view in Dynamic. What Dynamic does is wrap the State in a boxed Any. It also keeps around a copy of the previously-rendered view. When the view is rebuilt, it does a type check to determine if the stored state still matches the View::State type. If it doesn't, then the we raze and rebuild the view.

The downside is that this has an extra cost of boxing and type checking. For Quill, because the view hierarchy is re-created every update, it's designed to be cheap - it's just filling in slots in a giant tuple. For bevy_reactor, OTOH, I took a different approach because the view hierarchy is only built once, so there's less pressure to try and optimize the building of views.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants