In this article we will talk about the most common architecture in react applications. First let’s define event driven architecture as an architectural pattern which promotes the production detection reaction and consumption of events. We define an event as a change in the application state.
From a more strict perspective, what is produced, published, propagated, detected or consumed is a message called the event notification, and not the event, which is the state change that triggered the message emission.
Also we will compare this architecture with a FSM and enumerate some of it’s advantages.
In React Applications, when something happens in UI, for instance you change the value of an input field, it may dispatch an event and it will be handled by the dispatcher. It will eventually update indirectly the application state (stores). If there is a part of the UI, that is being shown and depends on the state changed, React will update it automatically.
Basically these are the main application parts:
- Actions – Methods that facilitate passing data to the Dispatcher
- Dispatcher – Handle actions and send payloads to registered callbacks
- Stores – Contain application state & logic that have callbacks registered to the dispatcher
- Views Container – Components that access state from Stores and pass it down via props to child components.
Lets see how does this components communicate.
- Views dispatch an action based on a given event
- The action in response to the event will(most likely, if it is asynchronous) trigger a call to the API
- The API can respond in many ways. Normally will return an ok response. If it fails, also can be handled by the react application
- The dispatcher will handle properly the response and if it applies will change the store properly
- Once the store has changed it’s internal status, the views depending on this aspect of the application state will update automatically (react do the trick)
Take a graphic look at what this architecture schema looks like:
Let’s go a little deeper:
Now we will analyze one by one the above mentioned architectural pieces:
The Dispatcher is the core of the process, the main hub. It receives actions and dispatches the actions and data to registered callbacks. There is always only one dispatcher, and it acts as the central hub within your application. Compared to the FSM analogy, the dispatcher says when you will change from a state to another given the input.
Storage, represented by stores manage the application state for a particular aspect in your application. Again, in the FSM analogy, storage is the internal state of the state machine. Stores manage the data, data retrieval methods and dispatcher callbacks. It is convenient to have compartmentalized stores, one for each different facet of your application (users, posts, comments)
Action Creators & Actions
The action type constants are, in our FSM analogy, the input that changes the state machine from a state to another. They are the ones that define what action should run, and are sent with necessary data. Inside of proper callbacks, these actions can be handled according to their action type, and methods can be called with action data as the arguments.
Action Creators is the set of methods that are called inside the views (or anyother part of the code that matter) to send actions to the Dispatcher.
Views are really React components that listen to change events and retrieve Application state from Stores. Then they pass that data down to their child components via props. In the FSM analogy they don’t have place. But you can think of them as a way to see FSM partial state.
After reading this article, I hope that if you didn’t understand a react application basic architecture before, now you do better. It wasn’t until building our own applications with it that I understood how complimentary to React.js are redux, and other frameworks (even middleware libraries).
We valuate a lot the similitude with a FSM because it allows us to have a good control about application state and helps us to debug. This may get complicated when debugging internals to follow the information flow, but if you pay enough attention you can avoid this extra complexity.
Again, I believe that to truly understand a complete react application, you actually have to create at least a small one, so stay tuned for the following articles since we are going to create a “Learning React” article where we are going to build an application, maybe a small blog with React.js and Redux Architecture!