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.
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.