Fine-grained reactivity vs too fine grained reactivity

[ignatz]

Disclaimer: this is a bit meta and the "right" level of granularity certainly depends on many factor.

As I'm wrapping a bunch of floem widget factories, I came to notice that many/most receive a lot of closures, which is dandy to inject signals, e.g.

let (reader, writer) = create_signal<String>("initial");
label(move || reader.get())

As I'm becoming more familiar with the implementation and widgets, i came to wonder if it wasn't "simpler" and just as costly to write something like:

let (reader, writer) = create_signal<String>("initial");
dyn_container(move || reader.get().clone(), |value| static_label(value))

minus maybe some copies (which could easily be addressed), this may seem like more typing at first but assuming that many labels will actually not be reactive, would be less typing and a simpler API, i.e. static by default and reactive when needed.

I assume this is why there's text() a.k.a. static_label(). Though the same argument could be made for widgets, e.g. img(), svg(), ... and probably many more closure-heavy widgets. In other words, I'm wondering if it could make sense to make at least all "static asset" widgets (maybe others) less-reactive by default and wrap them in reactive containers to swap 'em in and out? Should there even be a reactive label, img, svg, ...?

Given you have to maintain a large number of widget APIs, I'm confident that you've carefully thought about this. This makes me think that I'm probably just missing something.

[dzhou121]

Closure doesn't mean you have to use signal in it. So you can do

label(|| "initial")

[jrmoulton]

I'm wondering if it could make sense to make at least all "static asset" widgets (maybe others) less-reactive by default and wrap them in reactive containers to swap 'em in and out?

I don't see how this is anything but more typing and more difficult to reason about.

So naturally I was also wondering what were you're guiding principles or tradeoffs you considered when picking between static and reactive?

The default is fine grained reactivity. Static versions are made available if it's a common enough use case.

We definitely want the reactive updates to be as small as possible or you end up doing lots of extra work. This is the reason for fine grained reactivity in the first place

[ignatz]

I don't see how this is anything but more typing and more difficult to reason about.

Mind elaborating? - I'm seeing the opposite. I'm not arguing that there isn't a ton of wiggle room and plenty of room for subjective esthetics. I've done my fair share of frameworks and was certainly surprised when I first saw that tab() takes four function objects :)... This is clearly a strawman, even though 4 is an impressive number, tab is inherently a reactive widget.

As for typing, you can clearly tune, e.g.:

label(|| "static")
label(move || reader.get())
// vs.
label("static")
dyn(move || reader.get(), |v| label(v))

The default is fine grained reactivity. Static versions are made available if it's a common enough use case.

There's a beauty in fewer ways of doing things, whether that's everything gives you its own tracking scope or you wrap it. That's why we're here to argue. Ultimately, you're mileage will vary based on what's more common to you.

For example, a common use case for images will be to download them in the background. You can clearly model this with signals, with a wrapped static image, or you could even offer a flavor receiving a future of bytes with fallback builders for the loading and error case. The list of common use cases can get quite long for any one widget. One benefit I can see with wrapping is that you can keep the widgets lean and push some of the responsibility up the stack in a more reusable manner, e.g. you could wrap a static image in a dyn_container for signals and in a future_container for futures 🤷‍♀️

We definitely want the reactive updates to be as small as possible or you end up doing lots of extra work. This is the reason for fine grained reactivity in the first place

Maybe I'm missing something, maybe we're talking past each other? In the label example the work should be the same: render the text and redraw one quad?

Barking up the tree: fine-grained reactivity, doesn't imply finest-grained reactivity - whatever that means. Speaking in hyperbole, I wouldn't want to draw glyphs on individual quads and then only re-render individual glyphs. In practice, folks will call anything fine-graind reactivity that is retained mode graphics w/o rebuilding the entire tree on every frame (and optionally diffing a virtual dom to reduce work).

FWIW, I'm here to discuss because I'm really enjoying floem. I was mostly wondering if you've considered a different split of responsibilities, where fewer widgets take on the responsibility of reactivity. If nothing else it would my current c-abi wrapping work easier :shellfish:.

I can certainly buy into stylistic preferences, one solution being more generic (to then layer simplifications on top), one approach being terser in the most common use-case, you having more important things to work on :) ...

I also do think I got my answer regarding "guiding principles". If I understood correctly, you want pretty much every widget to be reactive and as such closures everywhere. In common-enough cases you may additionally introduce static flavors. FWIW, I'm fine with that. I'm just not sure that any of the proposed APIs does inherently less work or is more performant than the other. Ideally you'd tell me that I'm wrong and then I've learned something 😅 . Either way, I appreciate your time, your answers, and I really enjoy floem.

[jrmoulton]

Hopefully my reply didn't come across as dismissive. I really enjoy floem and am just happy other people do as well :) And I agree with pretty much everything you've said.

Back to this:

At some point I was mostly wondering why wouldn't I just leave reactivity to a few containers and keep most static?

The biggest reason that I can see is that when you let the reactivity be handled by containers you lose the caching of values inside of the inner elements. When a dyn_container rebuilds its child everything needs to be re-run. So all taffy layout, inner layout, and styling are recomputed and can't be cached. When you let the reactivity be handled by the elements that element can cache those properties and then only request updates for layout/styling as necessary.

[dzhou121]

@ignatz I get what you mean now. So a reactive widget would be too "overkill"/"verbose" for users who just want the static version.

A "simple" solution would be providing one reactive and one static for the same widget (which Floem currently does for some widgets but not all), but this solution does have these problems:

1. More work for Floem maintainers since you'd need to write those 2 variants.
2. It's putting a burden on users' mind since every time you write a view you'd need to decide "do I need the reactive one or the static one".

And the solution what @ignatz proposed was to provide all widgets as static ones, and then have one single way to achieve reactivity. I think that works for simple widgets like label, svg, img etc, so widgets that don't have child widgets, but not so much for things like list, stack, because of the caching @jrmoulton mentioned.

Thanks @ignatz for bringing this up, and I think it's always a good thing to push the boundaries on how to improve developer experience. How to solve this problem here remains an open question, and any thoughts would be welcomed.

[ignatz]

The biggest reason that I can see is that when you let the reactivity be handled by containers you lose the caching of values inside of the inner elements. When a dyn_container rebuilds its child everything needs to be re-run. So all taffy layout, inner layout, and styling are recomputed and can't be cached. When you let the reactivity be handled by the elements that element can cache those properties and then only request updates for layout/styling as necessary.

That makes sense. In the general case, a dyn_container will rebuild all children eliminating any chance of them caching. With the call-out of taffy, I did look a bit into label's implementation and it doesn't seem like there's a lot work that persists a self.update(). I guess it's not too surprising that when you change the text that not a lot of text layouting can be reused 🤷‍♀️

Maybe there's a guiding principle in there along the lines of: when a widget is a container and manages a list of things, it makes sense to be reactive because it may cache work for a subset of elements that didn't change?

A "simple" solution would be providing one reactive and one static for the same widget (which Floem currently does for some widgets but not all), but this solution does have these problems:

1. More work for Floem maintainers since you'd need to write those 2 variants.
2. It's putting a burden on users' mind since every time you write a view you'd need to decide "do I need the reactive one or the static one".

Right. I'm with you. I'm arguing against offering multiple widgets (also because I want to wrap less). Playing devils advocate, the solution that you, I and everyone else is arguing against is the current state :hide:. This thread is trying to figure out what would be the cost of collapsing e.g. text() and label() to just one and avoid the issues you're pointing out.

And the solution what @ignatz proposed was to provide all widgets as static ones, and then have one single way to achieve reactivity. I think that works for simple widgets like label, svg, img etc, so widgets that don't have child widgets, but not so much for things like list, stack, because of the caching @jrmoulton mentioned.

Exactly! There's a fuzzy line somewhere that splits widgets where caching saves cost (e.g. reactive containers like list, tab, ... not sure stack falls into this category) from widgets where updating the input basically invalidates the entire widget state (like label, img, svg, ...).

Arguably, this will always be a widget-by-widget decision to be made and whatever this thread concludes third-party widgets can always choose for themselves how to receive their inputs. I was mostly interested in the guiding principles, how you folks decide on APIs for new widgets, and if there are costs that I'm missing.

I think it's always a good thing to push the boundaries on how to improve developer experience. How to solve this problem here remains an open question, and any thoughts would be welcomed.

The more I think about it, the more I feel that thinking about async updates could inform the trade-offs between sprawling flavors of similar widgets to improve devex and static widgets in reactive containers. Concretely, I'm thinking of the journey: show a loading indicator until a future resolves to its result or an error. Something that's addressed by, e.g.

• https://docs.solidjs.com/reference/components/suspense
• https://api.flutter.dev/flutter/widgets/FutureBuilder-class.html

I think that's an interesting case because it's very common, especially for images, and the cost of rebuilding is bound by the fact that the transition from (loading -> result or error) will happen only once (unlike streaming, though even when streaming images there's little work that can be cached).

I don't want to make it sound more dramatic than it is. As y'all pointed out, at the end of the day we're probably just talking a hand full of widgets. At best we can derive some principles for more consistent APIs in the future.
I see several paths, none are roadblocks and all can be switched between at any point:

1. Do nothing and keep the catalog of widgets as is, i.e. offer multiple flavors of widgets on a best effort basis
2. Consistently pass inputs as function objects and make that the only option
3. Identify the cases where little caching is possible and offer static versions only

Sounding like a broken record player: I encourage you to think about how these options would hold up if floem would want to offer an ~async_container.

FWIW, this thread was already super helpful and instructive to me. I've sort of converged to applying #3 to my wrapping effort, i.e. I would wrap label, img, ... as static versions only.

[dzhou121]

I have an idea that might work.

If you look at the internal implementation of the reactivity of widgets, the widgets themselves are static by nature, and the reactivity is a create_effect which takes the closure as the input, and updates the state of the widget if there's a value change.

So my proposal is, on the widget building function, they only takes the initial value, (static by default), and then they provide a chained method which takes the closure to provide reactivity. So the label and static_label can become:

label("text")

let text = create_rw_signal(String::new("initial"));
label("initial").update(|| text.get())

stack and dyn_stack can be unified as

stack((view1, view2))

let items = create_rw_signal(vec![1,2]);
stack(()).update(|| items.get(), |i| *i, |i| label(i.to_string()))

[dzhou121]

let text = create_rw_signal(String::new("initial"));
label(text.get())

There's an issue with this approach that if you "add" the reactivity to a parent scope, this widget will be updated whenever there's any change in the parent scope.

The ideal solution would be if you provide a value then it's a static, if you provide a closure, then it's a reactive one.

label("text")
label(|| text_signal.get())

But I don't know if this is possible in Rust without the help of macros. (You can do this in Leptos)

[ignatz]

There's an issue with this approach that if you "add" the reactivity to a parent scope, this widget will be updated whenever there's any change in the parent scope.

Yes but only to the extend that you're not willing to introduce a new parent scope:

let text = create_rw_signal(String::new("initial"));
dyn(|| label(text.get())

But I don't know if this is possible in Rust without the help of macros. (You can do this in Leptos)

rust itself doesn't like overloads. macros might certainly be able to address some of the multiplication, devex concerns by "auto-wrapping" values, futures, ... 🤷‍♀️

[dzhou121]

For label, I've come up with this:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=06b871a8bff97207c026301aa1c8f6f3

[ignatz]

That's very neat! I like that you can also just pass in the signal for the most straight forward reactivity. I'm not sure how expensive a noop-updater is but with this approach you could even push the updater creation into the trait implementation for only when it's needed 👍

[dzhou121]

I've now simplified the dyn_container in ECS branch, and this is how it looks like for the counter example:

https://github.com/lapce/floem/blob/ecs/examples/counter/src/main.rs#L13-L14

[aalhitennf]

For my own project i created MaybeSignal enum, basically same that Leptos has. I don't know how bad it is performance wise but it makes really easy to create components that can take static or dynamic (signal) as value.

https://gist.github.com/aalhitennf/d1a647065518f36cefeb9f659a270ab8

Not sure if this i correct, pasting it from old files but you should get the idea

fn typography(value: impl Into<MaybeSignal<String>>) -> Label {
    let sig: MaybeSignal<String> = value.into();
    match sig {
        MaybeSignal::Static(v) => text(v),
        MaybeSignal::Signal(s) => label(move || s.get()),
    }
}

Using signal

let text_value = RwSignal::new("Whatever".to_string());
let dynamic_label = typography(text_value);

or static

let static_label = typography("Whatever");

[xb284524239]

As far as I know, the Google team has designed two types of widgets in the Flutter framework: StatefulWidget and StatelessWidget. They correspond to stateful and stateless respectively.
As for fine-grained reactivity vs too fine grained reactivity, we may be able to find some inspiration from Flutter.