I am not sure why getting props via something like 'mapStateToProps' is inferior to getting them via N levels for ...props (or ...props[Foo]).
The component getting the props exposes the same interface. Tracing the origin of a given prop is probably easier when it comes from the global state.
Simply using mapStateToProps is not, by itself inferior. Tacking on all the additional boilerplate that comes standard with Redux, IMHO, is. But the point wasn't so much to rail against Redux. The point was that many people (myself included) have believed that it's simply impractical to pass values/states through props. The point is that passing values through props isn't necessarily as inferior as many React devs assume it to be.
There are certainly times to reach for a state management tool. But I believe firmly that, as JS/React devs, we shouldn't be so quick to reach for additional tools/libraries when the core language already does that function.
If you want to loop through an array in a for/each manner, you can load up jQuery, or Lodash, or Underscore. They all have loop-through-array functions. And there was a time when those functions were more practical. But now, with the Array.prototype functions, it would be really silly to load up those tools just to loop through an array.
I have other... "issues" with Redux. It's not just a state management tool (like MobX). It's an entire framework tacked onto the top of another framework (React). And it has the effect of scattering your application/business logic far away from the place where it's needed/used. But those points are best reserved for a future post. My original point wasn't to dissect Redux's features/challenges, but rather to illustrate that prop drilling doesn't have to be a headache.
Although I don't expect this point to cause any Redux fans to throw it out, I also wanna reiterate the point made in the post regarding information flow. Any global state manager messes with that flow. Redux tries to make up for that problem by dragging all of the update logic into separate files/folders, treating reducers and actions as Gatekeepers of the Variables. But this provides a lot of cognitive overhead, literal (LoC) overhead, and it still doesn't change the fact that a global variable can be set from anywhere that has access to the global scope.
But by at least considering the idea that global state management is always an absolute necessity, it can make logic/data flow easier to trace. It's too much for me to illustrate that here in a reply, though.
I get your points about state managers in general, not adding tools and libraries that aren't needed etc.
It just reads like you are saying: "prop drilling is a problem, that's why we have all of those other solutions like state managers" and then you say "well, actually it is not a problem".
From my experience, it is a problem no matter how you structure your props.
imho, the design decision that props are the only way for components to communicate and that they can only flow down the tree and only one level at a time is very arbitrary and doesn't suit real world applications very well. In other words, I pretty much agree with the first half of your argument as I understand it (that props drilling is indeed a problem).
Well, then I suppose I didn't make my argument persuasively enough. :-)
But to be honest, I don't expect to be able to persuade too many people. Especially not in a single post. And especially not those people who already use state management tools, are deeply ingrained in them, and, most likely, probably love them. Hell... I've been that guy (even if my go-to state management tool-of-choice is MobX).
This is only a realization that I've come to over several years. And I freely admit that many other React devs might never come to the same realization.
If my team were starting a new "green fields" project, I wouldn't really argue much at all with someone who says, "And we totally have to use MobX." I might suggest that we consider the Context API. Depending on the scope of the project, I might even oh-so-gently suggest that maybe we don't need a state management tool at all. But that's not a hill I'm gonna die on.
The only recommendation I'd actively argue against is Redux. But quite frankly, I have far bigger reasons for disliking Redux (which I assume I'll outline in some future post). And even then, my argument certainly would not be, "Let's ditch Redux and just use prop drilling!" My argument would me more like, "If we're adamant on using a state management tool, why wouldn't we at least consider MobX??" But more importantly, if shared state management is that important, why wouldn't we first consider React's native solution to the problem: the Context API???
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.
I am not sure why getting props via something like 'mapStateToProps' is inferior to getting them via N levels for ...props (or ...props[Foo]).
The component getting the props exposes the same interface. Tracing the origin of a given prop is probably easier when it comes from the global state.
Simply using
mapStateToPropsis not, by itself inferior. Tacking on all the additional boilerplate that comes standard with Redux, IMHO, is. But the point wasn't so much to rail against Redux. The point was that many people (myself included) have believed that it's simply impractical to pass values/states through props. The point is that passing values through props isn't necessarily as inferior as many React devs assume it to be.There are certainly times to reach for a state management tool. But I believe firmly that, as JS/React devs, we shouldn't be so quick to reach for additional tools/libraries when the core language already does that function.
If you want to loop through an array in a for/each manner, you can load up jQuery, or Lodash, or Underscore. They all have loop-through-array functions. And there was a time when those functions were more practical. But now, with the Array.prototype functions, it would be really silly to load up those tools just to loop through an array.
I have other... "issues" with Redux. It's not just a state management tool (like MobX). It's an entire framework tacked onto the top of another framework (React). And it has the effect of scattering your application/business logic far away from the place where it's needed/used. But those points are best reserved for a future post. My original point wasn't to dissect Redux's features/challenges, but rather to illustrate that prop drilling doesn't have to be a headache.
Although I don't expect this point to cause any Redux fans to throw it out, I also wanna reiterate the point made in the post regarding information flow. Any global state manager messes with that flow. Redux tries to make up for that problem by dragging all of the update logic into separate files/folders, treating reducers and actions as Gatekeepers of the Variables. But this provides a lot of cognitive overhead, literal (LoC) overhead, and it still doesn't change the fact that a global variable can be set from anywhere that has access to the global scope.
But by at least considering the idea that global state management is always an absolute necessity, it can make logic/data flow easier to trace. It's too much for me to illustrate that here in a reply, though.
I get your points about state managers in general, not adding tools and libraries that aren't needed etc.
It just reads like you are saying: "prop drilling is a problem, that's why we have all of those other solutions like state managers" and then you say "well, actually it is not a problem".
From my experience, it is a problem no matter how you structure your props.
imho, the design decision that props are the only way for components to communicate and that they can only flow down the tree and only one level at a time is very arbitrary and doesn't suit real world applications very well. In other words, I pretty much agree with the first half of your argument as I understand it (that props drilling is indeed a problem).
Well, then I suppose I didn't make my argument persuasively enough. :-)
But to be honest, I don't expect to be able to persuade too many people. Especially not in a single post. And especially not those people who already use state management tools, are deeply ingrained in them, and, most likely, probably love them. Hell... I've been that guy (even if my go-to state management tool-of-choice is MobX).
This is only a realization that I've come to over several years. And I freely admit that many other React devs might never come to the same realization.
If my team were starting a new "green fields" project, I wouldn't really argue much at all with someone who says, "And we totally have to use MobX." I might suggest that we consider the Context API. Depending on the scope of the project, I might even oh-so-gently suggest that maybe we don't need a state management tool at all. But that's not a hill I'm gonna die on.
The only recommendation I'd actively argue against is Redux. But quite frankly, I have far bigger reasons for disliking Redux (which I assume I'll outline in some future post). And even then, my argument certainly would not be, "Let's ditch Redux and just use prop drilling!" My argument would me more like, "If we're adamant on using a state management tool, why wouldn't we at least consider MobX??" But more importantly, if shared state management is that important, why wouldn't we first consider React's native solution to the problem: the Context API???