xilem_core: Add a WithoutElements ViewSequence

[Philipp-M]

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]

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]

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]

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

[DJMcNab]

A docs nits, but otherwise I think it's better to land this than not.

Sorry it's taken so long to review; this hasn't been on my critical path.

[Philipp-M]

Sorry it's taken so long to review; this hasn't been on my critical path.

Hmm now I almost forgot about this myself. I merged main into here and fixed the conflicts, as some time went by, maybe give it a quick review again?

[DJMcNab]

Mostly looks good. I've not run any manual tests

[DJMcNab]

I'm surprised that this change has no other impacts; it seems a bit random to have in here

[Philipp-M]

Yeah I've included it here, as I was testing it with returning a WidgetViewSequence but that didn't work IIRC, as sequences are using dyn Widget instead of DynWidget which is used only within AnyWidgetView. I don't exactly remember anymore what did happen, but DynWidget cause(d/s) problems.

Currently WidgetViewSequence is not really used, which is why it doesn't seem to have an effect, and unfortunately it's not possible to mix with other view sequences like FlexSequence.
I guess it could also be removed, as we're only using "specialized" view sequences.
I think I'll leave it in here for now, and delay further changes (removal?) to follow-up PRs, I think in this form it's slightly more correct.