DEV Community

Discussion on: A Context API Framework for React State Management

Collapse
 
benjaminsmiths profile image
Ben Smith

After using redux a few time I started to question why I was using react... I tried mobx also and still was not completely happy either. Then I took on a legacy react app that used no central state management at all... and actually it was small enough to not need it, it was fine and I got very used to the good old setState. My only grip was of course prop drilling but as I said it was small enough to not bother me too much.

When react 16 was released and introduced hooks the Context struck me straight away as the simple fix for my one issue and I’ve been using ever since, very happily.

I would also add that using react router and the url path can also negate the need for centralised state as it essentially takes on that role. That is for all of your public mutable state. And all private immutable state can be covered using the Context hook. I’m thinking of writing this up as a post very soon.

Thanks for sharing

Collapse
 
bytebodger profile image
Adam Nathaniel Davis

An example of the (IMHO) flawed "page" mentality that I've seen with React router is that I'll be on a site/app that's using it, then I'll open the inspector and see all the API calls that are being made to supply the necessary data. Then I'll click somewhere in the app - which invokes a new "route", which is treated too-often by the dev team as an old-fashioned "page" - and then I'll watch in the inspector as all the previous API calls are repeated. Again, you don't have to design your React router app as such. But whenever I see that, I just kinda sigh. Cuz it's so lazy when you consider what we can do today with tools like React to build Single Page Applications.

Collapse
 
bytebodger profile image
Adam Nathaniel Davis • Edited

Thanks for the feedback! I'd definitely be interested in seeing that post if you write it up. It's nice to hear that I'm not the only one with these thoughts. Sometimes, when working/talking with other "React types", I get the feeling that I'm on an island with these critiques.

I'm kinda neutral on hooks right now. I might "come around" to them later. But my main gripe with them is that, the way they were implemented (whereby there's no "easy" way to call them from within classes), they sorta become an all-or-nothing proposition. And I know... some people are thinking "That's why you should just abandon classes and use hooks exclusively!" But that's not really practical for any kinda legacy app. But this isn't a diatribe against hooks. Just a kinda critique about how I haven't been able to blindly embrace them as some devs have.

Re: React router, I see it as an 80%-90% "net good". My only problem with router is that I've seen too many React apps where they use the router as an excuse to build their apps in a very old-school, circa 2002, style. What I mean by this is they start to see their app in terms of "pages". And then they write logic that, like the server-side scripting apps of old, will recreate the entire state based on every new "page". Of course, you don't have to use React router in this way. But it's my only real "problem" with apps that are heavy on it.

Cheers!

Some comments have been hidden by the post's author - find out more