4 ms·
IMO that's not much different than introducing a new variable in your global state to represent the same thing because you didn't realize there was already one
by nightski 7y ago
IMO that's not much different than introducing a new variable in your global state to represent the same thing because you didn't realize there was already one there.
If you have a team you need discipline, code reviews, and leadership. No state solution is going to solve this for you.
- diob 7y agoI always try to tell folks that frameworks won't save them from themselves.
- ricardobeat 7y agoIt is not a matter of discipline. Avoiding this gotcha requires you to manually inspect your entire parent component hierarchy looking for uses of that hook - sometimes that is a plain grep away, but it is a very much invisible error. You also have to be familiar with the inner workings of the hook itself, and any other nested hooks, to verify if they use any local state or not. If it does, and you need to share that state, well, that's a big rewrite which kind of defeats the initial argument. Maybe extra tooling could be built to avoid this, if we weren't already drowning in linter plugins...
- nightski 7y agoAgain this isn't a problem with hooks. You could easily connect a redux store and reducer to some component low in the hierarchy with it's own state. Or use a class based component with some state. A developer can introduce random state anywhere and it has nothing to do with hooks themselves. If you can't trust your team to make the right decisions about where to place state, then you need to provide more guidance. I also disagree about the big re-write. Converting a hook's data/state to come from a prop instead is a very simple change.
- schwartzworld 7y agoI love how every criticism of hooks is like "if you don't take care to use them well, you get bad code".
- deleted 7y ago[deleted]