This question is not related to Redux vs Context, but would be glad if someone takes the time to answer.
It seems to be a "me" issue, but when and how to decide if I even need a global state management tool at all? I'm currently working on a pretty big project, that will progress in scale as time goes by, but so far, I haven't really felt the need of a global state management..?
We're using react-query for API-related data, and I'm using Context API for simple use cases such as having the sidebar menu of the dashboard opening/closing when clicked from an outside component which triggers update to the whole dashboard, and also using the Context API for i18n language changes.
Besides that, I haven't really felt the need for anything else. Or am I looking incorrectly at the things, and missing something? Haven't really thought of a scenario so far where I'll need something like Redux at all. What are some examples of such scenarios?
Redux may be handy when you want collaborative UI (app like google docs), and want to update actions live for all users because of that event sourcing pattern that Redux use. You just need to pass that actions you're using over websocket and apply to the store.
Because Redux have strong convention it may be plus whey you switch between projects or your project have high devs rotation. Evebody are familiar with this solution so it's easier to work with it. React context can be used diferently depending what developers do.
Also, Redux is easy to debug with dedicated devtools. You can see what happened as the new condition is calculated and you can "rewind time". So during development, developement team with QA team, QA can actually send you serialzied store (or just post it for example in Jira ticket as part of issue/bug) and you can reproduce exact same state of the app. It can be really handy.
In React Contexts, we have standard react devtools and we can only view components.
React Contexts should be modular, but devs often are afraid of having too many Contexts, so they stuff extra responsibilities into existing Contexts, which make them grow very much.
And if we already have a lot of them, there may be chaos in the organization of data flow, and in particular what from whom it depends, because there is no one source of truth.
And finally chaos in tests, because different components can depend on different contexts and it is not visible from the outside.
All of that solutions are just tools and you need pick the best, that fits you need.
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.
This question is not related to Redux vs Context, but would be glad if someone takes the time to answer.
It seems to be a "me" issue, but when and how to decide if I even need a global state management tool at all? I'm currently working on a pretty big project, that will progress in scale as time goes by, but so far, I haven't really felt the need of a global state management..?
We're using react-query for API-related data, and I'm using Context API for simple use cases such as having the sidebar menu of the dashboard opening/closing when clicked from an outside component which triggers update to the whole dashboard, and also using the Context API for i18n language changes.
Besides that, I haven't really felt the need for anything else. Or am I looking incorrectly at the things, and missing something? Haven't really thought of a scenario so far where I'll need something like Redux at all. What are some examples of such scenarios?
Redux may be handy when you want collaborative UI (app like google docs), and want to update actions live for all users because of that event sourcing pattern that Redux use. You just need to pass that actions you're using over websocket and apply to the store.
Because Redux have strong convention it may be plus whey you switch between projects or your project have high devs rotation. Evebody are familiar with this solution so it's easier to work with it. React context can be used diferently depending what developers do.
Also, Redux is easy to debug with dedicated devtools. You can see what happened as the new condition is calculated and you can "rewind time". So during development, developement team with QA team, QA can actually send you serialzied store (or just post it for example in Jira ticket as part of issue/bug) and you can reproduce exact same state of the app. It can be really handy.
In React Contexts, we have standard react devtools and we can only view components.
React Contexts should be modular, but devs often are afraid of having too many Contexts, so they stuff extra responsibilities into existing Contexts, which make them grow very much.
And if we already have a lot of them, there may be chaos in the organization of data flow, and in particular what from whom it depends, because there is no one source of truth.
And finally chaos in tests, because different components can depend on different contexts and it is not visible from the outside.
All of that solutions are just tools and you need pick the best, that fits you need.