Suas architecture is composed of five core elements:
- Store: main component that contains a reducer (or set of reducers), the main application state, and the listeners subscribed for state changes. Store's state is changed by dispatching actions to it.
- State: defines the state of a component/screen or group of components/screens.
- Action: each action specifies a change we want to effect on the state.
- Reducer: contains the logic to alter the state based on a specific action received.
- Listener: callbacks that gets notified when the state changes.
The following animation describes the Suas runtime flow.
Suas runtime flow looks like this:
- When an event is generated from the UI (or network/lifecycle/etc...), an action is created and dispatched to the store.
- The store receives the action and sends it to each middleware in it's list of middlewares. This step is optional as the Store can have an empty list of middlewares.
- Next, the action is sent to the reducer (or list of reducers for more complicated apps). Each reducer receives the action along with the current state and decide whether it can handle the action or not. If it can it updates the state which updates the internal state in the store.
- The newly generated state is then broadcast to all the listeners attached to the store (that are listening to this particular state). The new state is used to populate UI components for example.
Let's start by checking how to define states in our applications.
List of example applications built with Suas
Updated about 4 years ago