Module bevy_defer::signals

Signals for bevy_defer.

Signals are the cornerstone of reactive programming in bevy_defer that bridges the sync and async world. The Signals component can be added to an entity, and the NamedSignals resource can be used to provide matching signals when needed.

The implementation is similar to tokio’s Watch channel and here are the guarantees:

• A Signal can hold only one value.
• A Signal is read at most once per write for every reader.
• Values are not guaranteed to be read if updated in rapid succession.
• Value prior to reader creation will not be read by a new reader.

Signals erases the underlying types and utilizes the SignalId trait to disambiguate signals, this ensures no archetype fragmentation.

In systems, you can use SignalSender and SignalReceiver just like you would in async, you can build “reactors” this way by sending message to the async world through signals. A common pattern is react_to_component_change, where you build a state machine like bevy_ui::Interaction in bevy code, add react_to_component_change as a system, then listen to the signal Change<T> as a Stream in async.

SignalSender and SignalReceiver do not filter archetypes, if you only care about sending signals, make sure to add With<Signals> for better performance.

Macros

• signal_ids
  Quickly construct multiple marker SignalIds at once.

Structs

• Fac
  Standard SignalId for every type.
• Receiver
  AsyncEntityParam for receiving a signal.
• Sender
  AsyncEntityParam for sending a signal.
• SignalMap
  A type map of signals.
• SignalReceiver
  WorldQuery for receiving a signal synchronously.
• SignalSender
  WorldQuery for sending a signal synchronously.
• Signals
  A composable component that contains type-erased signals on an Entity.
• Value
• ValueStream
  A Stream that polls values continuously from a signal.
• WriteValue
  Value asserted to be writable.

Traits

• SignalId
  A marker type that indicates the type and purpose of a signal.

Type Aliases

• SignalDeprecated