Event sourcing

learn how the engine uses actions to manage event sourcing overview event sourcing is a method for managing state changes by recording a series of discrete actions instead of directly modifying the application state this approach ensures that all peers in a networked environment maintain a consistent and synchronized state for an overview of state management and how event sourcing integrates with hyperflux, refer to the https //docs ir world/developers/state management actions definition actions are discrete units of change that represent user or system intentions and serve as the primary mechanism for handling state changes in event sourcing they allow developers to control how data flows within the system, ensuring that changes are processed in a structured and predictable manner they can be dispatched, processed, and synchronized across different parts of an application examples of actions include spawning an entity switching an avatar modifying a property actions are processed asynchronously and follow a structured lifecycle when to use actions use actions when a state change requires validation, synchronization, or tracking across peers action lifecycle actions follow a structured lifecycle to ensure consistency and correct ordering dispatching actions actions are dispatched to topics , which determine how they are routed if no topic is specified, the action is sent to the default topic if the action belongs to a networked topic , it will be sent to the appropriate peers for synchronization once dispatched, the action is added to the incoming queue for local processing if networked, it is also added to the outgoing queue processing actions action processing follows a structured pipeline outgoing actions are dispatched at the end of the animation frame if the peer is the host , the action is forwarded to all other peers if the peer is not the host , the action is sent only to the host incoming action queues are populated at the start of the next animation frame actions are processed in the order they were received each action is handled by its respective system based on the order in which systems were registered optional targeted action forwarding by default, networked actions are forwarded according to the topic rules the $to property can be specified to forward an action only to a particular user the following diagram illustrates the action flow best practices following best practices ensures efficient and reliable event sourcing ✅ use actions only when necessary define an action only if it needs to be networked or represents a significant state change avoid dispatching unnecessary actions that could overload the network ✅ optimize data transmission pass references or ids instead of large data payloads to reduce network traffic ✅ maintain consistent state synchronization ensure all receptors process actions in the same order handle out of order actions correctly to prevent state desynchronization for a deeper understanding of how actions integrate with state management, visit the https //docs ir world/developers/state management