Dan Abramov created Redux honestly by accident when he was writing code for a React Europe demo. He wanted to see a talk on "hot reloading and time travel" which then led him into coding a demo using other aspects of code. It's based of Flux and has unique aspects of Elm incorporated into it as well. After the demo Dan said people really liked the architecture and so he turned it into a library.
Its only 2kB in size. So a very small library.
- Whether your app is really simple or a complex one with a lot of UI and data state you're going to represent the whole state of your app as a single JS object.
- All changes of the state in redux are exlpicit
- Pure functions are the functions whose returned value depends solely on the values of their arguements.
- they do not have any observable side effects
- they are predictable
- may call the database or the network but they may have side effects.
- they may operate on the DOM
- they may override the values passed to them
- The state tree is redundant. You can not modify or add to it. Instead everytime you want to change the state you need to dispatch an action.
- An action is a plain JS object describing the change.
- To describe state mutations you have to write a function that takes the previous state of the app, the action being dispatched, and returns the next state of the app and this function has to be pure. This function is called the Reducer.
Actions are payloads of information that send data from your application to your store. They are the only source of information for the store. You send them to the store using store.dispatch().
Here's sample code for creating an action:
const ADD_TODO = 'ADD_TODO'{
type: ADD_TODO,
text: 'Build my first Redux app'
}Actions are plain JavaScript objects. Actions must have a type property that indicates the type of action being performed. Types should typically be defined as string constants. It is suggested that anytime something new is created to it is better to assign it a unique ID.
Actions describe the fact that something happened, but don’t specify how the application’s state changes in response. This is the job of a reducer. Since the application state is stored in a single object it is better to think of its shape prior to any coding. You’ll often find that you need to store some data, as well as some UI state, in the state tree. This is fine, but try to keep the data separate from the UI state.
Now that you have the state shaped you can write a reducer which starts like the exampl below:
(previousState, action) => newStateThings you should never do inside a reducer:
- Mutate its arguments;
- Perform side effects like API calls and routing transitions;
- Call non-pure functions, e.g. Date.now() or Math.random().
Remember the reducer must be pure. No API calls or no mutations.
The Store is the object that brings them together. The store has the following responsibilities:
- Holds application state;
- Allows access to state via getState();
- Allows state to be updated via dispatch(action);
- Registers listeners via subscribe(listener);
- Handles unregistering of listeners via the function returned by subscribe(listener).
Redux architecture revolves around a strict unidirectional data flow.
This means that all data in an application follows the same lifecycle pattern, making the logic of your app more predictable and easier to understand. It also encourages data normalization, so that you don't end up with multiple, independent copies of the same data that are unaware of one another.