Reactive ergonomics: a comparison of approaches

[viridia]

I've been fortunate over the last several weeks to play with the BSN prototype extensively, and I am starting to get a sense of both its strengths and weaknesses. It should come as no surprise that while BSN does a lot to ease the pain of initially spawning a complex hierarchy, it currently does little or nothing to deal with the complexity of keeping that hierarchy up to date in response to changes in app state. However, the point is not to complain about BSN, but rather to assess the "state of bevy ui" as a whole now that BSN has been added into the picture.

My goal here is not to advocate for a particular approach, but rather to analyze the strengths and weaknesses of various approaches, and gather feedback from readers which will help in ranking them. Also, if this inspires additional experimentation that would be nice too.

I'm going to look at the following code (almost all of which was written by me) and talk about the developer experience of each:

• The standard_widgets example
• The standard_widgets_observers example
• The feathers widgets
• My recent bevy_reactor_3 experiments

Within these examples, I am going to focus specifically on the task of widget states: hover, pressed, checked, disabled, and so on.

standard_widgets

The standard_widgets example relies heavily on ordinary ECS systems to manage widget states. Sadly, this involves a daunting amount of boilerplate: more than 100 lines of code dedicated to buttons alone, with similar amounts of code for each widget type. The pain points here are:

• Marker components like Pressed require component removal detection. Since query filters don't support this, we have to rely on the awkward RemovedComponents API. This in turn means separate code paths for adding states as for removing them - we can't have just a single "update style" system.
• The need to register these systems. Basically, widgets in Bevy come with infrastructure: you can't just plop them into your UI and expect them to work, there's a complex web of plugins and systems that need to be installed.
• Lack of colocation: The template for creating a widget has to be separated from the code for updating its style. While this is not a huge burden for commodity widgets like button and checkbox (which presumably only get written once), it starts to become a major hassle for bespoke application-specific widgets, which a complex app will have a lot of.

standard_widgets_observers

The standard_widgets_observers uses observers rather than systems to update the widget styles. The first version had an even worse boilerplate situation than the standard widgets example. @cart 's refactoring of this reduced the amount of boilerplate, but at the cost of some fairly advanced generalizations that are hard to explain to the average user. The pain points are:

• (Early version) - lots of boilerplate and duplicative observer code.
• (Later version) - less boilerplate, but harder to understand as an example.
• Redundant processing: unlike a system where multiple changes are aggregated into a single update, each component change triggers a separate observer callback. This means, for example, if "Hovered" and "Checked" both change at the same time, the widget style will still get recalculated twice.
• Need for observer registration. See previous section.
• Lack of co-location. See previous section.

One point of tension between the "systems" vs. "observers" approach is that each bias the design of components in opposite ways: systems favor mutable components (since change detection is easy, and removal detection is hard), whereas observers favor immutable components (since removal detection is easy and detecting mutations is impossible). This means that people designing their component architecture need to pick one or the other approach based on how they intend to react to changes.

feathers widgets

The feathers widgets use essentially the same methods as standard_widgets with the addition of theming. The main difference is that the problems are mostly swept under the rug by putting all the system registration in a plugin. However, this too comes at a cost: the full set of feathers widgets currently entails installation of 14 plugins (5 for feathers, 5 for standard widgets, and 4 for common functions like focus management). This isn't so much of a problem for people who want to install the jumbo economy plugin, but creates complexity for people who want to include individual widgets a la carte.

bevy_reactor effects

Presumably the reader already knows how systems and observers work, so there's no need to go into too much detail. With reactor effects, however, some additional explanation is needed. I'm not trying to "sell" bevy_reactor as a solution, so much as raising the bar for what we should be trying to achieve.

Bevy reactor 3 allows for dynamic effects to be inserted as part of the BSN template, similar to BSN's on feature. For example, insert_dyn allows for a component, such as BackgroundColor, to be calculated dynamically:

    commands.spawn_scene(bsn!(
        Node {
            left: ui::Val::Px(0.),
            top: ui::Val::Px(0.),
            right: ui::Val::Px(0.),
            position_type: ui::PositionType::Absolute,
            display: ui::Display::Flex,
            flex_direction: ui::FlexDirection::Row,
            border: ui::UiRect::all(ui::Val::Px(3.)),
        }
        BorderColor::all(css::ALICE_BLUE)
        insert_dyn(|cx: &Cx| {
            let entity = cx.owner();
            match (
                entity.contains::<InteractionDisabled>(),
                entity.contains::<Pressed>(),
                entity.get::<Hovered>().map(|hovered| hovered.0).unwrap_or(false),
            ) {
                (true, _, _) => NORMAL_BUTTON,
                (false, true, _) => PRESSED_BUTTON,
                (false, false, true) => HOVERED_BUTTON,
                _ => NORMAL_BUTTON
            }
        }, BackgroundColor)

This has some advantages and disadvantages:

Advantages:

• Colocation: the code to update the background color is included in the same template.
• No preregistration: There's only a single plugin for the effects system, which supports any number of different effects.
• Updates are batched: the effects framework is driven by a regular ECS system, so if multiple dependencies change together, the calculation is only performed once.
• Both component mutations and component removal detection are supported.
• No over-reactions. "Over-reaction" is the case where a reaction triggers conservatively, that is, it redoes the calculation unnecessarily because some unrelated piece of state changed. An example is reacting to a change in a query, even though the specific entity within that query didn't change. This isn't an advantage compared to ECS systems (which also don't suffer from over-reaction), but it is an advantage compared to some other reactivity approaches.

Disadvantages:

The effects system causes some additional overhead:

• Each effect requires a hidden entity (much like an entity observer) attached to the owner entity. This hidden entity holds the reaction component. The number of extra components is equal to the number of reactions, where each different dynamic component (background, border, text color, and so on) requires a separate reaction. A button widget would typically require 2-3 reactions, so the number of extra entities is (number of buttons * 3).
• All reactions are processed in a single system, which is world-exclusive.
• All reactions require polling their dependencies every frame, regardless of whether they react or not. In the above example, the Hovered, Pressed, and InteractionDisabled component tick values are compared each frame. (Each reaction contains a HashMap of component/entity tuples, and another of resource ids - these are checked to see if anything changed).

The net cost in terms of execution is an exclusive system which runs a small amount of code for every reaction every frame, and a somewhat larger amount of code for reactions whose dependencies changed. This runs in a loop which is not parallelizable.

The other disadvantage of this approach is that the reactive context Cx is not Bevy-idiomatic. It somewhat resembles the code patterns for writing exclusive systems (where you access everything via a World reference). It doesn't look anything like the typical system, there's no queries or dependency injection supported.

One other neutral point is that bevy_reactor relies heavily on the "poor woman's trait queries" pattern: that is, it needs something like trait queries, but since that's not a feature supported by Bevy, it works around the issue by using component hooks to update a per-entity cache of dyn trait objects.

So the bottom line here is that the ergonomics are pretty nice, but there are some costs involved in getting this.

@cart
@alice-i-cecile

[alice-i-cecile]

Thoughts on standard_widgets

Marker components like Pressed require component removal detection. Since query filters don't support this, we have to rely on the awkward RemovedComponents API. This in turn means separate code paths for adding states as for removing them - we can't have just a single "update style" system.

RemovedComponents is generally an API that I'm very unhappy with. It doesn't integrate well, and it's prone to missing events. Designing a better replacement like Removed<C> filter shouldn't be impossible, and would be worth doing anyways. Getting a performant and robust solution would be a major engineering effort though.

The need to register these systems. Basically, widgets in Bevy come with infrastructure: you can't just plop them into your UI and expect them to work, there's a complex web of plugins and systems that need to be installed.

I still don't think that this is a problem. This is how all logic in Bevy works: violating user expectations and bypassing control mechanisms here simply because it's UI is something I don't think we should do.

Lack of colocation: The template for creating a widget has to be separated from the code for updating its style. While this is not a huge burden for commodity widgets like button and checkbox (which presumably only get written once), it starts to become a major hassle for bespoke application-specific widgets, which a complex app will have a lot of.

Agreed, this sucks a lot! I fundamentally don't think that this is fixable using this design.

[alice-i-cecile]

Standard widget observers

One point of tension between the "systems" vs. "observers" approach is that each bias the design of components in opposite ways: systems favor mutable components (since change detection is easy, and removal detection is hard), whereas observers favor immutable components (since removal detection is easy and detecting mutations is impossible). This means that people designing their component architecture need to pick one or the other approach based on how they intend to react to changes.

I agree, this is something that we should come to a single cohesive design choice on and promote exactly one pattern for.

[alice-i-cecile]

Feathers widgets

However, this too comes at a cost: the full set of feathers widgets currently entails installation of 14 plugins (5 for feathers, 5 for standard widgets, and 4 for common functions like focus management). This isn't so much of a problem for people who want to install the jumbo economy plugin, but creates complexity for people who want to include individual widgets a la carte.

I'm still not convinced this is a problem. What challenges are these extra plugins actually causing these users? Why would they bother to onerously configure these plugins?

If there's serious performance overhead to these plugins even in the absence of matching widgets that's a distinct problem, which should be resolved separately.