Flux and Redux - alexanderteplov/computer-science GitHub Wiki
Flux/Redux design pattern
Flux
Components
A Single Dispatcher. The dispatcher is the central hub that manages all data flow in a Flux application. It is essentially a registry of callbacks into the stores and has no real intelligence of its own — it is a simple mechanism for distributing the actions to the stores. Each store registers itself and provides a callback. When an action creator provides the dispatcher with a new action, all stores in the application receive the action via the callbacks in the registry.
Stores. Stores contain the application state and logic. Their role is somewhat similar to a model in a traditional MVC, but they manage the state of many objects. As mentioned above, a store registers itself with the dispatcher and provides it with a callback. This callback receives the action as a parameter. Within the store's registered callback, a switch statement based on the action's type is used to interpret the action and to provide the proper hooks into the store's internal methods. This allows an action to result in an update to the state of the store, via the dispatcher. After the stores are updated, they broadcast an event declaring that their state has changed, so the views may query the new state and update themselves.
Views and Controller-Views. React (or your favorite lib/framework) provides the kind of composable and freely re-renderable views we need for the view layer. Close to the top of the nested view hierarchy, a special kind of view listens for events that are broadcast by the stores that it depends on. We call this a controller-view, as it provides the glue code to get the data from the stores and to pass this data down the chain of its descendants. We might have one of these controller-views governing any significant section of the page.
Actions. The dispatcher exposes a method that allows us to trigger a dispatch to the stores, and to include a payload of data, which we call an action. The action's creation may be wrapped into a semantic helper method which sends the action to the dispatcher.
Redux
Components
Actions. An action is a plain JavaScript object that has a type field. You can think of an action as an event that describes something that happened in the application. Actions may or may not carry a payload (a piece of data).
Reducers. Reducers are pure functions that take the previous state and an action and return the next state. You can think of a reducer as an event listener which handles events based on the received action (event) type.
They should only calculate the new state value based on the state and action arguments
They are not allowed to modify the existing state. Instead, they must make immutable updates, by copying the existing state and making changes to the copied values.
They must not do any asynchronous logic, calculate random values, or cause other "side effects".
Store. The current Redux application state lives in an object called the store. The store is created by passing in a reducer and has a method called getState that returns the current state value. The Redux store has a method called Dispatch. The only way to update the state is to call store.dispatch() and pass in an action object. The store will run its reducer function and save the new state value inside, and we can call getState() to retrieve the updated value
Selectors. Selectors are functions that know how to extract specific pieces of information from a store state value. As an application grows bigger, this can help avoid repeating logic as different parts of the app need to read the same data.
Key principles against a bare Flux
Single Source of Truth. The only way to change the state is to dispatch an action, an object that describes what happened. This way, the UI won't accidentally overwrite data, and it's easier to trace why a state update happened. Since actions are plain JS objects, they can be logged, serialized, stored, and later replayed for debugging or testing purposes.
State is Read-Only. This makes it easier to debug and inspect your app's state as things change, as well as centralizing logic that needs to interact with the entire application.
Changes are Made with Pure Reducer Functions.
Redux drawbacks
It's, in a nutshell, a global variable, which follows the Singleton pattern and the God Object anti-pattern.
It scales badly.
It requires normalization to preserve performance at an appropriate level.
