560429ebd9
# Objective - The usage of ComponentId is quite confusing: events are not components. By newtyping this, we can prevent stupid mistakes, avoid leaking internal details and make the code clearer for users and engine devs reading it. - Adopts https://github.com/bevyengine/bevy/pull/19755 --------- Co-authored-by: oscar-benderstone <oscarbenderstone@gmail.com> Co-authored-by: Oscar Bender-Stone <88625129+oscar-benderstone@users.noreply.github.com>
2.0 KiB
| title | authors | pull_requests | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Observer Overhaul |
|
|
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.
Use EventKey instead of ComponentId
Internally, each Event type would generate a Component type, allowing us to use the corresponding ComponentId to track the event.
We have newtyped this to EventKey to help separate these concerns.