Callbacks and Observers

[viridia]

One of the controversial decisions in the new standard widgets and Bevy Feathers is the use of one-shot systems as callbacks. The primary motivation behind this choice is to provide a model that would be familiar to web developers, where callbacks are the norm for frameworks like React, Solid, Vue and others.

However, others have asked "why not observers?". This is a reasonable question, and the current choice deserves some detailed analysis.

Concrete Use Case: Composite Widgets

It's hard to evaluate the merits of callbacks vs. observers in a vacuum, so I'm going to lay out a of realistic use case for discussion: a character customization screen that lets you select colors for your avatar. The page has three color pickers, one for the main color, one for the secondary detail color, and one for the accent color. (In most games there would only be a single picker, plus a switch to determine which color we were editing, but I'm deliberately making this complex for the sake of illustration).

There are three instances of the same color picker widget on the page, and each one has a number of widgets that can affect the color, such as RGB sliders, HSL sliders, a color palette / grid, possibly a 2D color plane. The picker is a composite widget whose input is the current color, and whose output is the new color. Each time the user drags a slider or clicks on the palette, a new color message is emitted. The various sliders and palettes are completely encapsulated: the external caller only sees new color events, it has no idea what kind of widgets produced those events. Making the picker a black box gives us the freedom to add new color spaces and new editing modes at any time without changing the picker interface.

Callback usage in JavaScript

Observers and one-shot callbacks in Bevy are very similar to their counterparts in JavaScript. Bevy's observers, especially with bubbling enabled, behave very much like DOM event listeners, while one-shot systems can be used like JavaScript callbacks.

Both event listeners and callbacks are used in web apps quite a lot. Event listeners tend to be more popular for low-level events like keyboard and mouse events, because this is what the native browser code generates at the lowest level.

Callbacks tend to be used more for high-level, application events like "user login" and "delete document". The reason for this is because the bubbling model - where events only flow upwards in the UI hierarchy - is often too limiting for high-level events. Bubbling works well when parent elements manage the events for their children; it doesn't work as well when messages need to be sent to other parts of the hierarchy, or outside of the hierarchy entirely (as in the case where events are being sent to an MVC model object or some external state management store such as Redux).

There are a handful of usage patterns for callbacks. The simplest is where you have a single sender and a single listener.

You also have cases of where there are multiple senders and a single listener. Take for example a listbox showing a list of clickable items, where a click on an item either takes some action or selects the item. If each of the list items has a different action, then it makes sense to have a separate callback for each row; with a single shared callback you'd need to have some switch or match statement inside the callback to take different actions based on which row was clicked. However, if the rows have all the same action, or action that is very similar (like setting the current selection to that row's id), then it doesn't make much sense to create a separate callback for every row, instead the rows can all share a single callback instance.

In the case of our color picker, each slider would have either an event listener or callback that listens for changes to the slider value. So for example, when the red slider is dragged, the on_change handler for the slider gets the current color, changes the red component to match the slider value, and then emits a new color event. To maintain encapsulation, external listeners don't know that the event is coming from the red slider specifically, as far as they are concerned the events are coming from the picker as a whole.

Note that for every slider drag update, there are two messages that are dispatched (these might be callbacks or bubbled events): there is the on_change message from the slider, whose payload type is f32, and theres the on_change message from the picker as a whole, whose payload type is Color. This is a common pattern in UI, where low-level events get intercepted and transformed into higher-level events as they propagate.

If we are using callbacks only, then each slider would have its own internal on_change<f32> callback, which in turn calls the higher-level on_change<Color> callback. So each of the red, green, and blue sliders would have its own callback closure which knows which color channel to change.

If OTOH we are using event listeners, we can take advantage of bubbling, and have a single listener on the picker root element; however this listener has to look at the event target's id or attributes to know what color channel is being edited. (And we also need other handlers on the root for other kinds of child widgets such as palettes).

Similarities and Differences between One-Shots and Observers

I have no idea how observers and one-shots are actually implemented in Bevy, but from a user standpoint they have a lot in common:

• Both are functions.
• Both support dependency injection with a variable number of arguments.
• Both have a special first parameter:
  • For an observer, this is the On parameter, which is required.
  • For a one-shot, this is the In parameter, which is optional depending on the system's input type.
• Both have a hidden entity that "owns" the closure via a special component.

They have some important differences as well:

• Only observers support bubbling and propagation.
• For observers, the first argument is not optional.
• They have different ways of managing lifetimes.

This last item is actually the most significant: observers and one-shots are different in how they are created and owned. Observers (except for universal observers, which wouldn't be useful here) always belong to some entity (the original_target), can't exist in an unattached state, and disappear when their owner is despawned. Lifetimes of one-shot systems, OTOH, are managed by the code that registered them, and can exist even if unattached.

Life without Callbacks

Let's say we wanted to implement our avatar customization page using only observers - callbacks don't exist. In order to use observers, we'd have to call .observe() on some entity. (A universal observer would get every color change from every picker, which would be confusing, so we won't do that.)

Within the avatar page, there's some display code that responds to a change in color from the picker, and updates the materials of the 3d model shown in the preview. This code can't call .observe() on the individual RGB sliders, since it doesn't know they exist, how many sliders there are, or how to find them in the hierarchy. Instead, the only option for the caller is to call .observe() on the picker's root element.

(Note that this assumes that the picker has a singular root element, and not multiple roots. More broadly, it exposes the fact that the source of the color changes is coming from an entity in the hierarchy, and not some other process like a script or memory store - because if it wasn't an entity, you wouldn't be able to call .observe() on it. A callback, on the other hand, effectively launders the origin of the message.)

Because the picker root is the only entity the external caller knows about, this kind of forces us to do all the event handling in context of the that root, discriminating events by target id. While we could have event listeners on the individual sliders too, this forces us to add an additional processing stage: now we have three levels of on_change handlers instead of two.

Let's make the problem even more complicated: suppose instead of having a picker, we have an "edit color" button that, when clicked, displays a floating popup with a picker inside of it. The picker is hidden inside the popup menu, so now the only entity that the external listener can "see" is the popup root. This means that we need to add yet another processing stage to forward the on_change event from the picker to the popup.

There's another approach which was suggested by @MalekiRe, which is to pre-register the observers on a blank entity and then pass in the entity as a parameter to the picker template which then fills it in as the root. (It has to be the root, because if we wanted to supply blank ids for the sliders, we wouldn't know how many to pass in.)

Let's ignore for the moment that BSN doesn't have this ability, as I assume that it eventually will. In order to pre-register the entity ids we need access to Commands or World or suchlike - unless we want to get really clever with bundle effects or something. It also means that, once again, we are having to pull a thread out of the weave of the picker and expose it to the outside world.

Note that none of the approaches I've described are absolute show-stoppers; I just think they are slightly worse from an architectural standpoint.

Current Behavior / Controlled vs. Uncontrolled

I'm assuming, BTW, that our color picker is a controlled widget (in the React sense) which means that the caller is responsible for maintaining and updating the current color. The picker does need to cache the current color input so that it can mutate one channel without affecting the others, but it never updates its own copy on input, it only accepts changes coming from outside. This gets even more interesting when you support multiple color spaces, to avoid "gimble-lock" you want to remember the previous hue and saturation as well as the previous RGB. However, this is a side issue and not central to the argument.

Callback Handles

The biggest problem with callbacks right now is that there's no way to automatically unregister them when we no longer need them.

The solution I currently like is to make one-shot system ids reference counted like asset handles. This falls under the category of "things we should be doing anyway".

Alternative Models

Callbacks and event listeners aren't the only possibilities here. One approach is regular systems, or stateful components with markers, but these are a challenge because you have to fiddle around with system run order in order to avoid 1-frame delays.

Frameworks like iced (and I guess, SwiftUI) use a functional approach where "state + input => action", but while I did read the iced documentation a long time ago, I never used it in a real project and so I don't know enough to assess its suitability.

@cart @alice-i-cecile

[alice-i-cecile]

Some quick ECS notes on the internals and future plans.

"Observers (except for universal observers, which wouldn't be useful here) always belong to some entity (the original_target)"

This is effectively accidental behavior, and is unlikely to be supported in 0.18. Instead, we're hoping to define these as distinct entities with relations, which allows for multiple observers per watched entity.

In order to pre-register the entity ids we need access to Commands or World or suchlike - unless we want to get really clever with bundle effects or something

The changes in #19451 should make this much more feasible.

The biggest problem with callbacks right now is that there's no way to automatically unregister them when we no longer need them.
The solution I currently like is to make one-shot system ids reference counted like asset handles. This falls under the category of "things we should be doing anyway".

Yep, on board with something shaped approximately like this. I think that the existing ergonomics of pre-registering one-shot systems and having to deal with manual cleanup is both unacceptable and not that hard to fix.

[cart]

Observers and one-shot callbacks in Bevy are very similar to their counterparts in JavaScript

I agree that there is overlap, but framing Bevy observers as "javascript events listeners" and the proposed Bevy callback as "javascript callbacks" in order to make the argument against observers feels "lossy". The difference between a Bevy observer and a Bevy callback is comparatively slim (as you have outlined).

The reason for this is because the bubbling model - where events only flow upwards in the UI hierarchy - is often too limiting for high-level events.

I'll note that Bevy Events / observers can bubble (or not bubble) in any way that they want. They do not bubble by default, and if a custom bubbling algorithm is needed, developers can provide their own.

[ bubbling ] doesn't work as well when messages need to be sent to other parts of the hierarchy, or outside of the hierarchy entirely (as in the case where events are being sent to an MVC model object or some external state management store such as Redux).

I agree. Bubbling shouldn't be used for those things, and doesn't need to be used for those things in the context of Bevy Events / Observers.

Life without Callbacks
Let's say we wanted to implement our avatar customization page using only observers

I've taken a stab at this scenario with bsn! and observers. It seems pretty much ideal from my perspective. I'm not seeing where this breaks down / becomes suboptimal. Feel free to make changes to it, or to port it to callbacks in order to make your case. In fact, please do port it to callbacks so we can compare and contrast in context!

#[derive(Component)]
struct ColorPicker {
    color: Srgba,
}

#[derive(EntityEvent)]
struct PickedColor {
    entity: Entity,
    color: Srgba,
}

fn color_picker() -> impl Scene {
    bsn! {
        ColorPicker
        Node
        [
            (
                :red_slider // assume this builds on the headless Slider widget
                on(|slider_value: On<SliderValue>, mut commands: Commands,
                    child_of: Com<ChildOf>, mut color_pickers: Query<&mut ColorPicker>| {
                    let mut color_picker = color_pickers.get(child_of.parent());
                    color_picker.color.r = slider_value.0;
                    commands.trigger(PickedColor {
                        entity: child_of.parent(),
                        color: color_picker.color,
                    ) 
                })
            ),
            // green and red sliders omitted for brevity
        ]
    }
}

fn player_main_color_picker() -> impl Scene {
    bsn! {
        :color_picker
        on(|picked_color: On<PickedColor>, mut player: Single<&mut Player>| {
            player.main_color = picked_color.color;
        })
    }
}

fn player_accent_color_picker() -> impl Scene {
    bsn! {
        :color_picker
        on(|picked_color: On<PickedColor>, mut player: Single<&mut Player>| {
            player.accent_color = picked_color.color;
        })
    }
}

fn player_color_editor_popup() -> impl Scene {
    bsn! {
        Node
        PositionType::Absolute
        Visibility::Hidden
        [
            :player_accent_color_picker
            :player_main_color_picker
        ]
    }
}

fn edit_color_popup_button(popup: EntityRef) -> impl Scene {
    bsn! {
        :button
        on(|press: On<Press>, mut query: Query<&mut Visibility>| {
           let visibility = query.get_mut(#popup).unwrap(); 
           *visibility = Visibility::Visible;
        })
        [
            Text("Edit Color")
        ]
    }
}

fn root_scene() -> impl Scene {
    bsn! {
        Node [
            :edit_color_popup_button(#Popup)
            (
                #Popup
                :player_color_editor_popup
            )
        ]
    }
}

Also please forgive me for using idealized bsn! syntax + functionality in a few places:

• Assumes that #Name can be used in argument position. This is not a particularly challenging problem to solve and its a part of the bare-minimum functionality I want to land with bsn!.
• Assumes that #entity_ref_variable_name can be used in arbitrary closure locations ... I'm not yet convinced this can be generalized, but I'm pretty sure it can be done with special cased patch implementations / syntax, as this just comes down to generating a template that feeds on the input entity path, resolves it to an entity, and outputs the observer. This is the biggest "leap", but it doesn't feel particularly large.
• Assumes that the Com<ChildOf> system parameter exists, which queries the component for the event's target entity. I have already prototyped this and it is likely to land in some form.

For the sake of comparison, feel free to make similar assumptions. We should not be making future facing decisions based on the arbitrary constraints of the current state of things.

This code can't call .observe() on the individual RGB sliders, since it doesn't know they exist,

Nor should it, as that is an implementation detail from the perspecive of the consumer of the color picker.

Only observers support bubbling and propagation.

This is "just" an additive feature. It is opt-in, and out of the user's face by default, especially after #20731, which makes "propagation" functionality statically only present on "propagating events".

For observers, the first argument is not optional.

Yes, but I'll note that this argument is filling the same role as some MyWidget::my_callback field: it is determining what event you are listening for. Observers don't pay for the MyWidget::my_callback syntax, so I consider this a wash.

They have different ways of managing lifetimes.

Observer lifetimes are a solveable problem from my perspective. They will support multiple targets in a more natural way once we port them to relationships, and we can adapt their lifetimes to meet our arbitrary needs.

Note that this assumes that the picker has a singular root element, and not multiple roots

This doesn't make sense to me. In Bevy "things" exist as a specific entity. If you have built a color picker, it has an entity and that is the root.

More broadly, it exposes the fact that the source of the color changes is coming from an entity in the hierarchy, and not some other process like a script or memory store

The source of a color change is the one calling commands.trigger for the event. Scripts or memory stores are free to call that, and they don't need to be entities. Only receivers need to be entities. We are discussing the API to use for Bevy entities to expose event receivers, so I see no problem with tying receivers to entities. Additionally, receivers for "non entity things" can always create a floating observer if they really want to. If I'm missing something, please provide an illustrative code example.

[viridia]

This response will be a bit scattered and out of order, as I have a lot of thoughts:

Additionally, receivers for "non entity things" can always create a floating observer if they really want to.

This is the "callback in all but name" approach. I rejected this because it seems redundant: we already have a concept in Bevy (one-shot systems) that is effectively this, and I don't see the benefit of replicating it, other than branding (putting everything under the "observers" name).

Unless you plan on replacing one-shots with observers entirely...

if a custom bubbling algorithm is needed, developers can provide their own.

Custom bubbling isn't the right answer. The point I was trying to make earlier is that the wiring between components tends to be more bespoke as you go higher up the stack (as opposed to commodified lower down), and most of the connections at that level are one-offs. There tend to be a lot of these one-offs, and making these connections should be frictionless. Wiring together two components should require only a few lines of code; it should not require a custom propagation type.

Only receivers need to be entities.

I realized last night that the language here is a bit confusing. Strictly speaking, entities aren't either receivers or senders. The "sender" is a function which calls commands.trigger(), the "receiver" is a function which handles the event. If we had to assign a role in this metaphor to the entity, I suppose it's the wire the connects them (but even that is an imperfect analogy).

Diving into this metaphor more deeply, let's talk about a light bulb and a wall switch. From a command-and-control perspective, there are three components to this circuit: the lightbulb, the wall switch, and the wire that connects them.

An important design point is the "need to know" principle: the lightbulb's design doesn't have any knowledge of what kind of switch is controlling it (whether it be a two-pole toggle or an electrical timer), the switch's design doesn't have any knowledge of what it is controlling (a lightbulb or a garbage disposal), and the wire doesn't have any knowledge of either. This lack of knowledge is what allows these parts to be commodified. (While I'm sure that GE and Phillips would love to be able to sell you wire and switches that only work with their branded lightbulbs, we haven't attained that degree of capitalist dystopia quite yet.)

There is a fourth participant here: the electrician who decided which switch connects to which bulb. This person also has a limited need to know - they just need to know enough to be able to plug the things together correctly. Projecting this analogy back to our UI components, the orchestrator who instantiates both the color picker and the model preview shouldn't have to know or care any details about these components.

My preference for callbacks is mainly philosophical in that it reduces the "need to know" for senders and receivers. The receiver of a callback doesn't care whether there is a single sender or multiple senders (since callbacks can be shared between senders). With observers, the receiver needs to call .observe() for each sender, which means that the observer now needs to know how many senders there are and what their ids are. We can get around this by routing all messages through a single entity, but this puts additional restrictions on how the developer structures their hierarchy.

I've taken a stab at this scenario

There's a number of things about this example that I don't like, but are unrelated to the question of callbacks and observers.

The first issue is the way that the observers locate the widget state using parent/child relations and queries. This is brittle: if I need to re-arrange the internal structure of the picker, such as adding an additional flexbox layer, now I have to fix all the event handlers and inject additional information to walk the ancestor chain.

What BSN desperately needs here is the equivalent of React' ref parameter. This is the ability to produce an entity id during construction, and have that id be accessible within closures further down the hierarchy. In React, you can create a reference using the useRef() hook, and then fill it in later with something like <div ref={myRef}>. Any closures which capture the ref can then get the id using myRef.current.

With something like ref the slider handlers could reference the picker state component directly, without knowing or caring where they were in the hierarchy relative to that state. (I kind of assumed that BSN would have something like this.)

In my reactive experiments, I worked around this by pre-spawning blank entities: I would call commands.spawn_empty() at the top of the function. I would then insert all of the components and children, but I would also have the id available for capturing by observers and effects. In some cases I would also pre-spawn the ids for certain special children that I wanted to dynamically update.

However, this workaround is not available in the typical BSN setup because in order to spawn an entity id you need access to Commands or World or something prior to running the template code. Note that unlike BSN, just about every third-party Bevy UI framework that I can think of (including sickle_ui, my stuff, and others) passes in a standard context parameter to the template* function which can be used to do housekeeping before the actual template bit begins. This also follows the structure of a typical React or Solid component, which has two sections: a setup part, where you call a bunch of hooks, which is followed by the actual JSX part.

This setup part is frequently used for:

• Declaring local state (signals, mutables, etc.)
• Creating callbacks
• Setting up reactive effects
• Subscribing to MVC models like Redux or Recoil

BSN's "no argument" style of scene functions effectively prevents all of this kind of housekeeping. Instead, we have to rely entirely on bundle effects or other post-construction or mid-construction hooks in order to get access to World, all of which are strictly local and are not a good fit for connections between entities.

(*I know that I'm using the word "template" in a way that conflicts with your usage, but I don't know what else to call it. In React this would be a "component" but using that word in an ECS context just leads to confusion.)

More comments as I think of them; for now I need to take a break from writing.

[cart]

Ah I forgot to respond to your "need to know" design principle. This is another case where a code example would be helpful. I believe the argument comes down to "callback inputs should be untyped to increase cross-compatibility of callbacks across contexts". For example: In<bool> vs In<Pressed> (where Pressed is a boolean). If this is the point, I see how this relates (as you can't write an On<bool> observer, as bool does not implement Event). But I still disagree. Callbacks are a response to a specific context / contract (much like a protobuf). By making them typed, we document and encode the contract being consumed. If we want to use the same contract at higher and lower levels of the implementation, nothing is stopping us from doing that (ex: I think a general purpose Pressed event could make sense). But I think it always makes sense to define the bounds of that contract. Feel free to come up with a counterexample so we can discuss this in context.

[viridia]

I'm still mulling over everything. However, there's one other issue that I need to solve if there's no callbacks. I don't want to make this an argument for or against callbacks since it only affects the standard widgets and not widgets in general. But it is a problem that will need to be addressed.

The standard widgets have both a controlled and uncontrolled mode of operation, which follows the same convention as React: if the widget has a callback, then it's controlled, otherwise it's uncontrolled.

The reason for supporting both modalities is:

• For a novice doing a very simple UI or demo, uncontrolled widgets are simpler to understand and work out of the box - they are more "self-contained".
• For complex UIs or advanced users, however, controlled widgets are preferred, because they avoid the need for complex synchronization between states ("two-way data binding").

I don't want to say too much more about the merits of controlled vs. uncontrolled, as I have written about this extensively elsewhere.

Without callbacks, there's no clear way to indicate which modality a widget should use. Even if a widget triggers an event on itself, it has no way to detect whether or not anyone is listening to that event; as a result, it cannot infer from this whether or not to self-update or to rely on external state management.

We could put a boolean flag into the widget instead, but I'm not fond of this for a couple of reasons. First, because we're paying the cost of an extra field, even though we're not getting the benefits of using a callback. And second, because I think that from a pedagogical standpoint, it's a little easier to explain the purpose of a callback (with the controlled vs. uncontrolled modality being a sidebar for users that care about such advanced details) than it is to explain a boolean controlled vs. uncontrolled flag directly. If that was the choice, I'd rather make all the standard widgets controlled and then explain to novices how to do external state management.

[viridia]

Also, and this is slightly OT: I realized that while Com as currently envisioned is useful for simple widgets where all events are being processed through a single entity - the same entity that is managing the widget's state - it's not as useful for composite widgets that have child widgets of their own.

Now, you might think that this isn't a problem, because there are many more leaf widgets than there are interior widgets - that's the nature of trees. However, from a developer perspective, a lot of time is spent building those interior widgets, especially if our leaf widgets are being imported from a library of ready-built controls. After all, while there may be many buttons, you only have to write the button implementation once.

My competing Subject/Inquiry proposal somewhat mitigates this objection, although it's not very well fleshed out at this point. The idea behind Subject is that the user can write a trait implementation that knows how to derive some entity id using only the observer's event as input, along with a World - so the subject could be the event target, the original target, the target's parent, basically any entity which is reachable using the On data as a starting point. The Inquiry type has the same generic parameters as Query, except that the subject is used in place of the query filter tuple. This is a generalization of Com.

It would not, unfortunately, interoperate easily with the #Name BSN feature, since that data is not part of the On payload.

[viridia]

I've had some time to sleep on this and marshal my arguments a bit better. That being said, I am also steeling myself to the fact that I'm probably going to lose this debate.

First, a nit: your example implementation of the popup doesn't match what I was thinking of. There would be three different MenuButtons, each having a single instance of the color picker as a child. This "Color Picker Button" would be a commodity component that was used elsewhere in the app, or in other apps. So it cannot be hard-wired to specifically update the player model, as that would make it non-reusable. From the outside world, the color picker button is completely atomic, encapsulated, and re-usable.

In a callback world, the menu button accepts the on_color callback as a parameter and forwards it to its children. In a world with Solid-like signals, we can also forward the current color value to the children as well, so the menu button doesn't need to have any closures or handlers at all (other than the inherited behavior for opening and closing the menu).

In a world of observers, we need to write code to take the output of the color picker and transfer it to the output of the menu button, since that is the only entity that external callers can "see". (We also need to write code to go the other way: update the picker in response to changes in the color coming from the outside. This can happen when, for example, the user reverts their settings changes - such a "revert" button would update the color choices but would not be part of the color picker. But that would be true regardless of whether we used callbacks or observers.)

Note that the menu button cannot depend on bubbling for the on_change event: first, because we probably aren't going to enable bubbling for most high-level events, and secondly, because the actual popup might not be a child: depending on how we implement popups, we might want to have the popup appear in front of all other UI content and be absolutely positioned.

I want to introduce another example: the "Are you sure you want to quit" dialog box. This has three buttons: "Cancel", "Quit without Saving", and "Save and Quit". Each of the buttons produces a different notification.

This is pretty easy to do as a bespoke widget: we use the standard BSN dialog box (I want to say template, but that's not right, but I hate calling it a scene, because it hasn't been instantiated yet), with three children for the three buttons. Each button has an observer or callback which takes the appropriate action.

OK so now we want to commodify this: we want to make this whole dialog a reusable widget so that it can be invoked in various ways (such as when you click the window close box or when you choose quit from the menu [yes, I realize that this is not how it would be done but it's an example]).

In a callback world, we could do this in two ways:

• Have the ConfirmQuit dialog accept three parameters: on_cancel, on_save_and_quit, and on_quit. The dialog box simply forwards these callbacks to each of the buttons respectively. Each of these callbacks is the same Rust type.
• Have the ConfirmQuit dialog accept a single action callback which returns an enum with three variants for the three actions. This means that the dialog contains handlers that multiplex the output of the buttons into a single notification.

In a world of observers, the first approach is problematic, and you are pretty much forced to use the second approach. The reason is because each of the button output events have the same Rust type. If you register multiple observers on the dialog, they all get every event, which is not what you want. Instead, you'd have to create separate entities, one for each different output, or you'd have to transform the button output events to be different event types (or an enum with a different variant for each action).

So my point here is that while you can solve these kinds of problems with observers, they are more intrusive on the developer and reduce choice - because the notifications are now coupled to the entity hierarchy, it means that the design constraints around the structure of notifications, and the design constraints around the visual structure, now impact each other instead of being independent.

[cart]

your example implementation of the popup doesn't match what I was thinking of.

Gotcha. I've adapted it, and I see your point about the additional boilerplate of wiring the event up:

fn button_color_picker() -> impl Scene {
    bsn! {
        #ButtonColorPicker
        Node
        [
            :edit_color_popup_button(#Popup)
            (
                :color_picker
                #Popup
                PositionType::Absolute
                Visibility::Hidden
                on(|picked_color: On<PickedColor>| {
                    let mut picked_color = picked_color.event().clone();
                    picked_color.entity = #ButtonColorPicker;
                    commands.trigger(picked_color);
                })
            )
        ]
    }
}

fn root_scene() -> impl Scene {
    bsn! {
        Node [
            (
                :button_color_picker
                on(|picked_color: On<PickedColor>, mut player: Single<&mut Player>| {
                    player.main_color = picked_color.color;
                })
            ),
            (
                :button_color_picker
                on(|picked_color: On<PickedColor>, mut player: Single<&mut Player>| {
                    player.accent_color = picked_color.color;
                })
            )
        ]
    }
}

Although that could be made "nice" with a helper:

bsn! {
    #ButtonColorPicker
    Node
    [
        :edit_color_popup_button(#Popup)
        (
            :color_picker
            #Popup
            PositionType::Absolute
            Visibility::Hidden
            forward_on::<PickedColor>(#ButtonColorPicker)
        )
    ]
}

[With callbacks you can] have the ConfirmQuit dialog accept three parameters: on_cancel, on_save_and_quit, and on_quit. The dialog box simply forwards these callbacks to each of the buttons respectively. Each of these callbacks is the same Rust type.

I agree that this case requires less boilerplate, as it doesn't require defining new Event types or forwarding handlers. Once again, I think providing actual code examples so we can compare and discuss in context is helpful. I'll throw it together for this case. If you want to discuss another example, I'd appreciate it if you provided a code snippet with it. Note that I'm using "idealized" callback syntax (ex: Callback<Click> instead of the current Callback<In<Click>>), in addition to "structs as scenes" to paint it in its best light.

struct ConfirmQuit {
    on_cancel: Callback<Click>,
    on_quit: Callback<Click>,
}

impl GetScene for ConfirmQuit {
    fn scene(self) -> impl Scene {
        bsn! {
            Node
            [
                (
                    :Button { on_click: self.on_quit } [
                        Text("Quit")
                    ]
                ),
                (
                    :Button { on_click: self.on_cancel } [
                        Text("Cancel")
                    ]
                ),
            ]
        }
    }
}

fn root() -> impl Scene {
    bsn! {
        :ConfirmQuit { 
            on_cancel: callback(|click: In<Click>| {
                info!("Cancelled {}", click.entity);
            })
        }
    }
}

This is certainly "clean". However it also reveals a downside: the click.entity is the internal button that has been clicked. Given that this is an implementation detail, and could correspond to arbitrary points in the hierarchy, that entity is pretty useless to the callback author. That means that consumers need to know that click.entity should be ignored, and they need to do additional work to pass in the entity they care about:

bsn! {
    #Foo
    :ConfirmQuit { 
        on_cancel: callback(|click: In<Click>| {
            info!("Cancelled {}", #Foo);
        })
    }
}

Or the ConfirmQuit author internally needs to redirect it:

impl GetScene for ConfirmQuit {
    fn scene(self) -> impl Scene {
        bsn! {
            #ConfirmQuit
            Node
            [
                (
                    :Button { 
                        on_click: callback(|mut commands: Commands, click: In<Click>| {
                            commands.notify_with(
                                &self.on_quit,
                                Click {
                                    entity: #ConfirmQuit
                                }
                            );
                        })
                    } [ 
                        Text("Quit")
                    ]
                ),
                (
                    :Button { 
                        on_click: callback(|mut commands: Commands, click: In<Click>| {
                            commands.notify_with(
                                &self.on_cancel,
                                Click {
                                    entity: #ConfirmQuit
                                }
                            );
                        })
                    } [
                        Text("Cancel")
                    ]
                ),
            ]
        }
    }
}

With Observers / Events, ensuring the context is "correct" is enforced by the system itself, as consumers are always writing handlers from the perspective of the entity they are interacting with:

struct ConfirmQuit;

#[derive(EntityEvent)]
struct Quit {
    entity: Entity,
}

#[derive(EntityEvent)]
struct Cancel {
    entity: Entity,
}

impl GetScene for ConfirmQuit {
    fn scene(self) -> impl Scene {
        bsn! {
            #ConfirmQuit
            Node
            [
                (
                    :Button
                    on(|mut commands: Commands, click: On<Click>| {
                       commands.trigger(Quit { 
                            entity: #ConfirmQuit
                        }); 
                    })
                    [ Text("Quit") ]
                ),
                (
                    :Button
                    on(|mut commands: Commands, click: On<Click>| {
                       commands.trigger(Cancel { 
                            entity: #ConfirmQuit
                        }); 
                    })
                    [ Text("Cancel") ]
                ),
            ]
        }
    }
}

fn root() -> impl Scene {
    bsn! {
        :ConfirmQuit
        on(|cancel: In<Cancel>| {
            info!("Cancelled {}", cancel.entity);
        })
    }
}

Yes, this requires slightly more typing than the first Callback example (observers: 49 lines, callbacks: 34 lines). But from a user-facing perspective I think the API + contract is clearer, the potential for accidental misuse and confusion goes down, and it makes interplay with other planned features (such as Com-like functionality) work, which imo is a critical piece of the UX story.

The "correct entity target" version of the Callback example (which would also play nicely with Com-like functionality) is 53 lines, reads worse (in my opinion), and notably treats a "ConfirmClick cancel click" as statically the same as an "internal button click", which I personally think is less clear.

Additionally, the simple "convert lower level event into higher level event" logic could be abstracted over if we so choose:

bsn! {
    #ConfirmQuit
    Node
    [
        (
            :Button
            trigger_on::<Click>(Quit { entity: #ConfirmQuit })
            [ Text("Quit") ]
        ),
        (
            :Button
            trigger_on::<Click>(Cancel { entity: #ConfirmQuit })
            [ Text("Cancel") ]
        ),
    ]
}

Which brings the total lines down to 41 for the observers example.

[With closures] we can also forward the current color value to the children as well, so the menu button doesn't need to have any closures or handlers at all

Yup I agree that not having to run "forwarder observers" (and just copying a SystemId down the hierarchy) is more efficient. In practice I don't think the overhead of running an extra observer or two in these cases is cause for concern, but I do definitely concede that not doing that work is preferable.

In a world of observers, the first approach is problematic, and you are pretty much forced to use the second approach

I think the argument for closures Callbacks comes down to:

1. Callbacks require no "event forwarding" logic at runtime to move events up the hierarchy, which cuts down on overhead.
2. Passing callbacks "down" as parameters is natural and intuitive
3. Plays better with autocomplete / is more self-documenting, as the supported closures are tied directly to the parameters of the widget.
4. Callbacks, especially "context-free" callbacks like In<()> can share the same type.

I think those are all strong, well-motivated arguments.

And we weigh that against the argument for observers:

1. One unified "Event handler API", used everywhere in the engine. No need for developers to choose between two similar parallel APIs based on what amounts to arbitrary context and requirements. Different developers will have different opinions on where the Callback vs Event line is. I expect the lines to be blurry / inconsistent / confusing here throughout the ecosystem, especially given the "UI code is just Scene code" architecture / narrative.
2. Consuming an entity's Event is always scoped to that entity, allowing it to play nicely with features like Com, which is a key part of the event handler ergonomics story in my mind.
3. Event authors can seamlessly change their events to include new behaviors (such as bubbling), without their consumers needing to switch to a different API (ex: porting a Callback to an Event to get the bubbling behavior).
4. Automatic / boilerplate-free support for multiple handlers of the same event (including retroactively / across scopes).
5. Because Event is a specific "thing" in the ECS context, it means we can build specialized tooling around it. For example, imagine you are inspecting your app using the Bevy Editor, and you would like to answer the question at runtime (while your app is already running), "when is PickedColor fired for this entity"?. With Events, we can add that functionality to the inspector. With callbacks, that is "baked in" at compile time and each context is "different". You could also build tooling like a "global event feed" that shows every event that fires in your app, or filter it down to specific entities.
6. We are very likely to have Component<->Event correlation hints, which would feed into the editor / inspector interface. If everything uses Event, we can display all of the "handle-able" events for a given Entity in the same place / using the same system + interface, based on its current component composition.

I'm personally still of the opinion that observers are the right move. It is also notably the more conservative move, as it doesn't require adding new features. Observers will be a key piece of the Bevy data model / scene system no matter what. If the sentiment that "observers are not enough" continues to grow, we can always add callbacks later.