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

xilem_core: Add a WithoutElements ViewSequence #608

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Philipp-M
Copy link
Contributor

This is similar as the fork view, but it allows using Views/ViewSequences without elements within a ViewSequence context that contains elements, see #461 (comment) for the original motivation.

Taking xilem_web as example, this should be possible (as well as something similar as in the linked comment):

fn run_once_fragment() -> impl DomFragment<()> {
    without_elements(run_once(|| {}))
}

The WidgetViewSequence is "fixed" as well, by using the "right" widget type (DynWidget is only used in AnyView, whereas I think Box<dyn Widget> is more general and correct).

@DJMcNab
Copy link
Member

DJMcNab commented Sep 27, 2024

I haven't had chance to review this yet. One thing I'm wondering is whether we can make an alternative for ViewMarker for these kinds of sequences?

@Philipp-M
Copy link
Contributor Author

Good point.

You mean to avoid the extra wrapper, and directly use the no element views in sequences?

At least something like this:

impl<V: View<State, Action, Context, Message, Element = NoElement> + NoElementViewMarker, ...>
    ViewSequence<State, Action, Context, Element, Message> for V {}

is not possible, because of ambiguity again... (We would need something like negative trait bounds?)

The other possible idea I tried, is directly implementing the ViewSequence for the concrete NoElement views, but this has another issue because of the super-trait bound View: ViewMarker which leads to ambiguity again.

I'm not sure if it's worth it, but we could remove the super trait requirement View: ViewMarker and put it to the concrete Views (like WidgetView), not sure about the exact implications, but it's probably not optimal, that the compiler doesn't scream when implementing View without also implementing ViewMarker...

Or do you mean something else?

@DJMcNab
Copy link
Member

DJMcNab commented Sep 27, 2024

I mean, I was especially saying that we should do that investigation.

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

Successfully merging this pull request may close these issues.

2 participants