I'm a Front-End Software engineer who will be responsible for the complete lifecycle of scalable, secure, and well-designed software products from research and design to implementation.
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.
I'm a Front-End Software engineer who will be responsible for the complete lifecycle of scalable, secure, and well-designed software products from research and design to implementation.
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!
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.
I'm a Front-End Software engineer who will be responsible for the complete lifecycle of scalable, secure, and well-designed software products from research and design to implementation.
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.