Everything that's stored in storage is called a state, but not all states are equally useful. Here's the classification introduced by the Redux documentation:
Since the store is the core of the application, the data inside it should be described in terms of domain data and app state, but not as a tree of UI components. For example, this way of generating a state state.leftPane.todoList.todos is a bad idea. It's extremely rare for a component tree to reflect directly on a state structure, and that's okay. The view depends on the data, not the data on the view.
A typical state structure looks like this:
{
domainData1 : {}, // todos
domainData2 : {}, // comments
appState1 : {},
appState2 : {},
uiState1 : {},
uiState2 : {},
}
More details about working with UI states will be described in the corresponding lesson.
As mentioned in the JS: React, course, the state structure should resemble a database. Everything should be as flat and normalized as possible.
{
todos: [
{ id: 1, name: 'why?' },
{ id: 3, name: 'who?' },
],
comments: [
{ id: 23, todoId: 3, text: 'great!' },
],
}
With this sort of structure, it's extremely easy to write a reaction to actions, update, add, and delete data. There's very little nesting, everything is nice and simple. But there is one other problem (which we'll always have to deal with). As the number of entities grows, the reducer starts to get quite hefty. It becomes a huge piece of code that does everything. To solve this problem, Redux has a built-in mechanism that allows you to create multiple reducers and combine them with each other. It works like this: each top-level property gets its own reducer, and then they're combined using the combineReducers()
function into a root reducer, which is then used to create the store.
import { combineReducers, createStore } from 'redux';
const todosReducer = (state = [], action) => {
// data from todos will go here
};
const commentsReducer = (state = [], action) => {
// data from comments will go here
};
const rootReducer = combineReducers({
todos: todosReducer,
comments: commentsReducer,
});
const store = createStore(rootReducer);
// If we call reducers as properties in the state, then the code can be shortened:
// const todos = (state = [], action) => { ... };
// const comments = (state = [], action) => { ... };
// const rootReducer = combineReducers({ todos, comments });
The state comes to each reducer, but not the store's entire state, only the part that's found in the corresponding property. Make sure to keep this in mind.
Reducers can even be nested, and no special tools are needed to do so, they're ordinary functions that take data as input and return new data. If you use this approach, one feature will appear that can seem frightening at first. Since each reducer has access only to its own part of the state, actions that cause changes in several places at once will be repeated in different reducers:
const todos = (state = {}, action) => {
switch (action.type) {
case 'TODO_REMOVE':
// ...
}
};
const comments = (state = {}, action) => {
switch (action.type) {
// When deleting a ToDo, make sure to remove all of its comments
case 'TODO_REMOVE':
// ...
}
};
In other words, the correct approach is to repeat the part of the case
in the necessary reducers, and not to try to get the missing parts of the state.
The Hexlet support team or other students will answer you.
A professional subscription will give you full access to all Hexlet courses, projects and lifetime access to the theory of lessons learned. You can cancel your subscription at any time.
Programming courses for beginners and experienced developers. Start training for free
Our graduates work in companies:
From a novice to a developer. Get a job or your money back!
Sign up or sign in
Ask questions if you want to discuss a theory or an exercise. Hexlet Support Team and experienced community members can help find answers and solve a problem.