Why use dynamic dispatch Children?

[ZihanType]

type Children = Box<dyn FnOnce(Scope) -> Fragment>;

pub fn Component(
    cx: Scope,
    children: Option<Children>,
) -> impl IntoView {
    ...
}

pub fn Component<Children>(
    cx: Scope,
    children: Option<Children>,
) -> impl IntoView
where
    Children: FnOnce(Scope) -> Fragment,
{ ... }

Why use the dynamic dispatch Children above instead of the static dispatch Children below?

[gbj]

Fairly simple reason: in terms of performance the primary constraints on WASM are binary size and the actual DOM rendering process in the browser. Adding a generic bound to a component will cause the Rust compiler to monomorphize it, creating a completely new copy of the component code for each different generic. Because closures are always unique types, this would copy the size of the component code x the number of times you used it.

There's no difference in terms of the DOM rendering costs between the two, so there's no difference there. And the cost of dynamic dispatch is small relative to that larger rendering cost.

If you find yourself in a situation in which you think it's making a difference, you can simply use a "render prop" (i.e., passing a function as a prop) instead of children and benchmark the difference.

[ZihanType]

In Leptos, closures are dispatched both statically and dynamically, what are the considerations for this?

[gbj]

In Leptos, closures are dispatched both statically and dynamically, what are the considerations for this?

I'm happy to give an answer if there are specific instances you're curious about.

In general the consideration is not static vs dynamic dispatch per se but “does this need to be stored in the reactive runtime?" (if so, must be boxed/stored on the heap) and “what's the binary size vs. runtime speed trade-off?” We do pretty regular benchmarking of the speed of the reactive system, as well as of binary sizes for example applications and frontend framework rendering benchmarks.

[ZihanType]

In Leptos, closures are dispatched both statically and dynamically, what are the considerations for this?

I'm happy to give an answer if there are specific instances you're curious about.

In general the consideration is not static vs dynamic dispatch per se but “does this need to be stored in the reactive runtime?" (if so, must be boxed/stored on the heap) and “what's the binary size vs. runtime speed trade-off?” We do pretty regular benchmarking of the speed of the reactive system, as well as of binary sizes for example applications and frontend framework rendering benchmarks.

For example, in the Show component, there are 3 parameters of the closure type, of which 2 are statically dispatched and 1 is dynamically dispatched. And, both the children parameter and the fallback parameter return the view, but one is dynamically dispatched and the other is statically dispatched.

[gbj]

For example, in the Show component, there are 3 parameters of the closure type, of which 2 are statically dispatched and 1 is dynamically dispatched. And, both the children parameter and the fallback parameter return the view, but one is dynamically dispatched and the other is statically dispatched.

Oh, I understand. In this case it's largely about developer ergonomics: children is always boxed (see reasons in conversation above), but it's done automatically by the view macro. fallback and when are both provided by the user, so taking generics means that users don't have to manually box them (when=Box::new(/* ... */))

It's also worth saying that we can't have optional generic props at present, which is part of why children is boxed. Now that I think of it, the example you gave initially wouldn't compile, I don't think -- when children is None the type of the Children generic can't be inferred. So in general an optional function property (whether it's children or something else) needs to be handled via dynamic dispatch.

[ZihanType]

Oh, I understand. In this case it's largely about developer ergonomics: children is always boxed (see reasons in conversation above), but it's done automatically by the view macro. fallback and when are both provided by the user, so taking generics means that users don't have to manually box them (when=Box::new(/* ... */))

It's also worth saying that we can't have optional generic props at present, which is part of why children is boxed. Now that I think of it, the example you gave initially wouldn't compile, I don't think -- when children is None the type of the Children generic can't be inferred. So in general an optional function property (whether it's children or something else) needs to be handled via dynamic dispatch.

Thank you very much, you have answered my question completely!