6f08bb84d2
# Objective Fixes #18726 Alternative to and closes #18797 ## Solution Create a method `Observer::system_name` to expose the name of the `Observer`'s system ## Showcase ```rust // Returns `my_crate::my_observer` let observer = Observer::new(my_observer); println!(observer.system_name()); // Returns `my_crate::method::{{closure}}` let observer = Observer::new(|_trigger: Trigger<...>|); println!(observer.system_name()); // Returns `custom_name` let observer = Observer::new(IntoSystem::into_system(my_observer).with_name("custom_name")); println!(observer.system_name()); ``` ## TODO - [ ] Achieve cart's approval --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
1.7 KiB
Rename Trigger to On
In past releases, the observer API looked like this:
app.add_observer(|trigger: Trigger<OnAdd, Player>| {
info!("Added player {}", trigger.target());
});
In this example, the Trigger type contains information about the OnAdd event that was triggered
for a Player.
Bevy 0.17 renames the Trigger type to On, and removes the On prefix from lifecycle events
such as OnAdd and OnRemove:
app.add_observer(|trigger: On<Add, Player>| {
info!("Added player {}", trigger.target());
});
This significantly improves readability and ergonomics, and is especially valuable in UI contexts where observers are very high-traffic APIs.
One concern that may come to mind is that Add can sometimes conflict with the core::ops::Add trait.
However, in practice these scenarios should be rare, and when you do get conflicts, it should be straightforward
to disambiguate by using ops::Add, for example.
Original targets
bevy_picking's Pointer events have always tracked the original target that an entity-event was targeting,
allowing you to bubble events up your hierarchy to see if any of the parents care,
then act on the entity that was actually picked in the first place.
This was handy! We've enabled this functionality for all entity-events: simply call On::original_target.
Expose name of the Observer's system
The name of the Observer's system is now accessible through Observer::system_name,
this opens up the possibility for the debug tools to show more meaningful names for observers.