This is a follow up to my second post in this series:
https://dev.to/bytebodger/throw-out-your-react-state-management-tools-4cj0
In that post, I ...
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
I'm beginner, should I learn Redux or am l just focus on context API?
Good question, and I'll admit that I'm biased in this. But I'll give you my best possible assessment:
The first question is: Are you on a team that's already using React? If so, have they already implemented Redux? If they have, then you definitely need to get familiar with Redux - even if you won't be working directly in that part of the code.
But I assume you're asking because you're either not on a dev team, or you're not on a team that's currently using Redux. If that's the case, I will point out that Redux is a very common pattern in established React dev shops. So if you completely ignore Redux, you run the risk of handicapping your own prospects in the marketplace. Even if you hate Redux, or even if you believe that Redux is on the down-slope, you should still be familiar with the pattern.
Also, understand that Redux is heavily dependent upon reducers. And reducers are not a concept that is limited to Redux. You'll see reducers in many other places in JS. So if you haven't already, learn them and know them well. They could serve you well, even if you never touch Redux.
Finally, if you are blessed enough to be doing "green fields" work - where all of the key tech decisions were not already made months/years ago, then I would absolutely encourage you to focus heavily on the Context API and on shared Hooks (I have a later article on this site that illustrates how to use shared Hooks for shared state management).
Specifically, I've come to question the knee-jerk stance that many React devs take in favor of state-management tools/library. There was a time in React when it was almost unimaginable to consider building a large-scale app without some kind of bolt-on state management solution. Today, I firmly believe that this is no longer necessary.
If you find yourself blindly reaching for a state management solution in all your apps (whether that solution is Redux - or something else), I sincerely believe that you should reassess your development practices.
Dear Adams,
As a beginner, the statement you reply to me, I think it will be a guideline for my React Journey. It's more details with explanations then what I expect from you. It's mentorship from the community and privileges for me to get something from the community author.
Yes, I'm in the last part of React Bootcamps, and it's all about Redux and project. Could you give me resources to follow and best practices?
I wish you all the best and looking for your next articles!
Sincerely
I can't really give you a concise list of "resources and best practices" because there are sooooo many of them. Seriously. The internet is overflowing with great resources. (Yeah... I know, there are also a lot of not-so-great resources out there, but I can't possibly catalog all of them for you into great-or-not-so-great.)
But I can definitely give you one "best practice" that I sincerely hope you take to heart:
One of the themes that I try to highlight (over and over again) in my blogs is: never be a "fanboy" - of anything. In other words, don't ever latch onto a given technology and decide that it's your "favorite". And don't ever decide that you "hate" a given technology. Every technology is a tool in your tool belt. Craftsmen don't believe that the hammer is "good" or that the screwdriver is "bad". They understand that there's a time to use a hammer. And a time to use a screwdriver.
How does this apply to programming??
Well... let's look at Redux, for example. If you read enough of my articles, you'll soon realize that I pretty much "hate" Redux. Even in those areas where I feel Redux has benefits - I also believe it brings problems with it that negate those supposed benefits.
But you know what??? Those are my opinions. And you know what my opinions are worth?? Exactly what you paid for them!
You see... Redux is a tool. It may not be a tool that I prefer to use, but it's still a tool. And there are still some times when Redux might actually be the right tool for the job.
So... LEARN REDUX! And... learn other state management tools. And... learn how to build modern React apps without any state management tools. And... learn how to build apps without React at all!!
IMHO, the goal should be this:
Five years from now, when I've hired you onto my team, and we need to make a critical tech-stack decision, I'll want to hear your opinion. But I won't want to to know that you're making a recommendation based on some dogma that you learned 5 years ago in bootcamp. I'll want to know that you're making a balanced, reasoned recommendation based upon your own experience and based upon your own, honest assessment of the options in front of us.
If you can give a balanced, meaningful assessment of the tech options we're facing, then... you've "won". And you're an extremely valuable developer.
Too many devs, who've been doing this shit for years, can't say the same thing.
Roger that! Thanks a lot.
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
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.
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!
I will never understand how anyone can prefer class over function component.
Umm... OK.
dev.to/bytebodger/the-class-boogey...
React Core team members say hooks are the way to go, they saw the problems with classes and created hooks thats the reason behind the update.
I hope they also give dietary suggestions. So I can eat exactly what they eat. I might even stalk a few developer conferences where they're speaking, so I can be sure to dress exactly like them.
If writing THIS makes you feel smarter go ahead use it. There is no reason to write so much boilerplate not to mention lifecycle methods..