I'm rather new to ReactJS and I'm trying to figure out when it's to my [webapp's] advantage to implement Redux store instead of just using props. Is it better to use useContext?
The general use case is an event list viewer that needs to maintain a connection session to a database api and display its connection status. Also need to effect a "mode" change (i.e., "real world" vs "test" vs "exercise") across the application.
I've seen this Stack Overflow question, and this one too, but neither of them give any indication on what the threshold is for when store is better than props or context.
CodePudding user response：
Its because the threshold can't be defined easily ahead of time. I would say its when:
- The performance of your app starts crumbling because you have so much state.
- The state management logic of your app becomes unmaintainable and horrible to the point where you are sufficiently annoyed to change it.
- You happen to know ahead of time you have really complex state.
Optimizing too early is a hugely common pitfall. If your state is simple, and not huge, you'd have the exact opposite effect by using redux from the off -- unnecessary complexity.
My recommendation, without further context about what your app is and your use case (provide if so), would be start with context and deal with your problems when they emerge, unless you are really sure right now that your app is going to be huge and complicated.
Just to add one datapoint, I work on a pretty big enterprise application that basically consists of 50 forms (which dont interrlate that much) and we've got by with context and local purpose-specific form stores just fine (and a network caching layer like URQL) with no real desire to change.
As another data point, I had a friend building some crypto dashboard that had many widgets all updating independently every few seconds. It was a complete nightmare. He moved everything to redux so he could buffer the state updates into one update across the whole screen every 5 seconds, and the issues went away. This is the kind of unique and complex case where you need to consider it. So...it depends.
Another type of app where I've found it necessary is anything that is hugely collaborative. Like an online real-time multiplayer game or live doc editing. The complexity goes through the roof with this sort of thing.
A running thread with those examples is the state is both complex and truly global in nature.
The experience to "know" can't be put into words or quantified. It comes with experience. But going with simple context, and changing it only if you have a gut instinct something is badly wrong architecturally, is a fair starting point imo.
I'll also add, redux has become synonymous with "all state at the top". Which depending on your app, may not be a good idea. State scoped to different subtrees is often what you want. If its the complexity of the updates and so much the scale of the size of the data, that can also be reduced with solutions like https://xstate.js.org/