Multiple root nodes

[mathiversen]

Hello,
First and foremost, thanks for making this excellent library public!

Are there any plans of supporting multiple root nodes when writing html?

This is not a major blocker for me but having the possibility to return multiple root nodes will make it a bit easier to work with semantic html, and make the html a bit easier to read.

Vue only used one root-node in v1/2 but switched to a multi-root setup in the new vue 3. Discussions and links can be found here link.

[Pauan]

I'm not entirely sure what you mean, dominator has always supported multiple root nodes:

dominator::append_dom(&dominator::body(), Root1::render());

dominator::append_dom(&dominator::body(), Root2::render());

You can append the root wherever you want, it doesn't have to be in the body:

rust-dominator/examples/todomvc/src/lib.rs

Line 13 in ac5391e

dominator::append_dom(&dominator::get_id("app"), App::render(App::deserialize()));

[mathiversen]

Sorry for not being clear enough. What I'm referring to is the html-macro, and the Dom struct in particular. For example:

    fn render_button(app: &App, text: &str, route: Route) -> Dom {
        html!("li", {
            .children(&mut [
                link!(route.to_url(), {
                    .text(text)
                    .class_signal("selected", app.route().map(move |x| x == route))
                })
            ])
        })
    }

The Dom requires only one root-node and this limits the possibility of how to construct "components".

rust-dominator/src/dom.rs

Lines 230 to 233 in ac5391e

	pub struct Dom {
	pub(crate) element: Node,
	pub(crate) callbacks: Callbacks,
	}

The way it works now is similar to how it used to be with Vue 1/2 and React. But mentioned libraries have transitioned to a structure where it's possible to have multiple elements in a fragment, see below:

Vue 3/React with mutliple nodes/elements at root level (React is similar with <> instead of <template>):

<template>
  <heading>...</heading>
  <p>...</p>
  <footer>...</footer>
</template>

Compared to:

<template>
  <div>
    <heading>...</heading>
    <p>...</p>
    <footer>...</footer>
  </div>
</template>

[Pauan]

Oh, I see, you mean being able to return multiple Dom elements.

Unlike React / Vue, Dominator does not use VDOM, we always use real DOM nodes, and the DOM does not support having multiple elements like that (though there is a proposal for it).

So if you want to return multiple Dom nodes, you should return a Vec<Dom>:

fn render_button(app: &App, text: &str, route: Route) -> Vec<Dom> {
    vec![
        html!(...),
        html!(...),
    ]
}

And now the parent can use .children to append it:

html!("div", {
    .children(render_button(app, text, route))
})

Because the methods can be called multiple times, there is no problem with using many components:

html!("div", {
    .children(render_header(app, route))
    .children(render_button(app, text, route))
    .child(...)
    .text(...)
    .children(&mut [
        ...
    ])
    .children(render_button(app, text, route))
    .children(render_footer(app, route))
})

If you want the children to be dynamic, you can return impl SignalVec<Item = Dom> instead:

fn render_button(app: &App, text: &str, route: Route) -> impl SignalVec<Item = Dom> {
    app.children.signal_vec_cloned().map(|x| html!(...))
}

And the parent uses .children_signal_vec:

html!("div", {
    .children_signal_vec(render_button(app, text, route))
})

[mathiversen]

Oh, that's very nice! Thanks for the detailed explanation 🙇 I didn't know that you could return a vec of dom's, that's really helpful. I hope to get some time this weekend to play with the lib and read the docs some more!

[dakom]

I also find it useful to use a dummy container so that it expresses the intent, has inline styling, and basically behaves like an empty fragment in terms of layout:

html!("empty-fragment", {
    .children(&mut render_header(app, route))
    .children(&mut render_button(app, text, route))
    .children(&mut render_button(app, text, route))
    .children(&mut render_footer(app, route))
})

fwiw, even though all of this does mean additional nesting, in practice I don't find that to be a real problem at all, just slightly more annoying to debug in the browser itself (but that's difficult with modern web dev anyway, e.g. auto-generated class names and so on)