Provide easy access to components of targeted entity in observers

[viridia]

What problem does this solve or what need does it fill?

When writing observers, it is frequently desirable to be able to access a component on the listener entity, that is, the entity in the trigger event.

Currently there are two ways to do this: either inject a query for all components of that type and pick the one you want; or inject a DeferredWorld, and then look up the component you need on the event's entity.

bevy_mod_picking had convenience methods for injecting components directly. I'd like to see something similar for Bevy.

What solution would you like?

I'm not sure about naming, but I was thinking of something like:

entity.observe(trigger: Trigger<Pointer<Down>>, component: ListenerRef<MyComponent>);

There would be a ListenerMut version as well. Alternate names might be TargetRef, TriggerRef, or ObserverEntityRef.

What alternative(s) have you considered?

For now, I'm using DeferredWorld, as I am unsure about the overhead of injecting a Query.

Additional context

bevy_mod_picking also provided a means to access the "target" entity and it's components, which was the entity upon which the event was triggered before bubbling, not the entity which handled the event. However, this feature was used rarely (at least by me anyway).

This is also somewhat related to a previous ticket filed by me a long time ago (#11048) - that was rejected (for good reason), but this ticket provides a much more narrowly-scoped variation of the same idea.

[ItsDoot]

Is this what you're looking for #15066?

[viridia]

Is this what you're looking for #15066?

Not as I understand it. That returns the hidden entity; what I'm looking for is components, not entities.

[NthTensor]

We are seeing a pattern emerge with global observers, which generally looks something like this

world.observe(|target: Trigger<Pointer<Click>>, buttons: Query<&mut Button>| {
    if let Some(button) = buttons.get(trigger.entity()) {
        /// add behavior common to all button components
    }
});

This is a bit verbose, and it means we end up invoking the observer system often when we don't need to. The ECS knows if the target has a button component, so ideally we could just not run this if it dosn't have one. I think the way to pave this cow-path might look something like the following

world.observe(|target: Trigger<Pointer<Click>>, button: Target<&mut Button>| {
    /// add behavior common to all button components
});

where Trigger<T> is a system-param specific to observers (much like Trigger<T>). Ideally the observer dispatch system would check the list of params against the archetype of the target, and only run matching observer systems.

Making this work may require a change to how system input works. Alternatively, we could perhaps add a generic parameter Trigger<T, QueryData> and make this change entirely within the observer dispatcher. This might look something like the following

world.observe(|target: Trigger<Pointer<Click>, &mut Button>| {
    let button = target.data();
    /// add behavior common to all button components
});

I would prefer the ergonomics of the former, but I'd settle for the latter and it's probably easier.

[viridia]

Another approach would be to have something like a fallible single-entity query:

world.observe(|target: Trigger<Pointer<Click>>, query: QueryListener<(&mut Button, &Hovered, Option<&Disabled>)>| {
    let (button, hovered, disabled) = query.get();
    /// add behavior common to all button components
});

This would only call the observer function if the query could be satisfied.

Alternatively, we could make it non-fallible if that's easier:

world.observe(|target: Trigger<Pointer<Click>>, query: QueryListener<(&mut Button, &Hovered, Option<&Disabled>)>| {
    let Some((button, hovered, disabled)) = query.try_get() else {
        return;
    }
    /// add behavior common to all button components
});

If we want to generalize this further, the second argument to the query could indicate which single entity we are querying: the listener, the trigger, etc. This allows the idea to be generalized to use cases other than observers:

world.observe(|target: Trigger<Pointer<Click>>, query: QuerySingle<(&mut Button, &Hovered, Option<&Disabled>), Listener>| {
    let (button, hovered, disabled) = query.get();
    /// add behavior common to all button components
});

The downside of this approach is that it's a bit more complex and introduces extra boilerplate in the handler.

[alice-i-cecile]

From @viridia on Discord.

I was thinking something different: something like Single but which targets the target:
entity.observe(
|trigger: On<Add, MyComponent>,
listener: Listener<Comp, Comp2, Option>|) { ... }

Where Listener is a Single query that implicitly matches the target entity.

Extra credit: Along with Listener: Emitter which binds to the original entity upon which the event was triggered.