As a newcomer to Redux, one of the hardest parts of learning Redux is deciding what goes in Redux and what stays as local state.
In my case, I ended up with putting all state into Redux, since I needed both time-travelling and the ability to preload the entire application state from configuration files.
I liked the idea proposed here: medium.com/@alexmngn/how-to-use-re... which relies heavily on reducer composition. The idea of nesting components and state where it is used, and also so the state reflects the folder structure of your application. This way, your project and state is so well structured, it's actually easier just to put the state in Redux than using local state.
It seems to work pretty well, however I must say I wonder why so few people seem to recommend doing it that way. What are your opinion about this kind of structure?
If you don't have time to read the article you basically end up with a state tree such as:
{
data: {
users: {
1: {
name: 'Jorem Sipsum'
}
}
},
scenes: {
books: {
loading: false,
drawerVisible: false,
data: {
books: {
1: {
user: 1,
title: 'JS gibberish',
description: 'Pure Function is an e-mail message to dynamically generate Web form JavaScript engines'
}
}
}
}
}
}
Right now I store all state for the given "scene" in redux, and the only downside I've noticed so far is that I have to clear the state per scene when navigating to another route/scene. To clear a given scenes state I was thinking about triggering an action RESET_BOOKS_STATE from the componentDidUnmount lifecycle hook of the Books view/scene/page resetting it to their default values. Is all of this some kind of anti pattern, or is this way of using redux for ALL state (no use of local state) a sane enough way of doing it? I mean, if you need that additional control as I mentioned earlier :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hello Dan,
As a newcomer to Redux, one of the hardest parts of learning Redux is deciding what goes in Redux and what stays as local state.
In my case, I ended up with putting all state into Redux, since I needed both time-travelling and the ability to preload the entire application state from configuration files.
I liked the idea proposed here: medium.com/@alexmngn/how-to-use-re... which relies heavily on reducer composition. The idea of nesting components and state where it is used, and also so the state reflects the folder structure of your application. This way, your project and state is so well structured, it's actually easier just to put the state in Redux than using local state.
It seems to work pretty well, however I must say I wonder why so few people seem to recommend doing it that way. What are your opinion about this kind of structure?
If you don't have time to read the article you basically end up with a state tree such as:
Right now I store all state for the given "scene" in redux, and the only downside I've noticed so far is that I have to clear the state per scene when navigating to another route/scene. To clear a given scenes state I was thinking about triggering an action RESET_BOOKS_STATE from the componentDidUnmount lifecycle hook of the Books view/scene/page resetting it to their default values. Is all of this some kind of anti pattern, or is this way of using redux for ALL state (no use of local state) a sane enough way of doing it? I mean, if you need that additional control as I mentioned earlier :)