You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/// Propagation is useful for events that should be handled by multiple entities in a hierarchy, such as UI events.
278
+
/// In these cases, it is common for the event to be triggered on a "leaf" entity, and then propagate up to "root" entities.
279
+
/// In this pattern, it is generally recommended to trigger the event on the most specific entity possible (the leaf), and then use propagation to have it handled by more general entities (the roots).
280
+
///
281
+
/// Once an event is handled by a given entity, you should stop propagation.
282
+
/// This ensures that only a single "behavior" resolves per event sent,
283
+
/// avoiding unexpected behavior from entities higher up the hierarchy.
284
+
///
285
+
/// This advice has one notable wrinkle:
286
+
/// if an entity is "disabled" (e.g. if a UI node is grayed out),
287
+
/// the event should still be considered "handled" by that entity,
288
+
/// even though the observer logic should not be run.
289
+
/// This ensures consistent behavior regardless of the enabled/disabled state of entities.
290
+
///
275
291
/// ## Naming and Usage Conventions
276
292
///
277
293
/// In most cases, it is recommended to use a named struct field for the "event target" entity, and to use
0 commit comments