I thought the quiz was really missing the point. The whole point of reactive programming is to not worry about execution order.
A Critique of React Hooks Addendum
31–40 of 56 posts
Re: A Critique of React Hooks Addendum
#32Earlier quoted context omitted.
I don't think that you'd be able to get a very clear answer from your average frontend developer on why their non-React framework of choice uses the state management pattern that it does. For that matter, most DBA's wouldn't be able to answer detailed questions about their chosen database's query optimizer, and most ML researchers wouldn't be able to answer questions about Numpy's choice of linear algebra algorithms.…
I feel going out of one's way to use a 3rd party library like Redux with React is a bit different than a database's internal query optimizer. Quite frankly the fact so many developers are replacing Redux with hooks is proof it was never the right choice for their project in the first place.
Or that Redux _was_ a reasonable choice at the time, and that with the ecosystem changing and other options available, it's worth re-evaluating use cases and updating the decision.
See https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet... .
Re: A Critique of React Hooks Addendum
#33I'm not quite sure what the point of this quiz is. I don't know the answer to those questions, and yet I seem to have no trouble building very large react applications (with hooks) anyway.
I would also struggle with similar quiz based on the callbacks for class components. And those I actually had to deal with on a frustratingly regular basis! At least with hooks I can remain blissfully ignorant of what happens under the covers of useEffect().
Maybe the answers don't matter and this is a pointless exercise.
Re: A Critique of React Hooks Addendum
#34This was a great follow up. I completely agreed with the first post, and I couldn't help but think those critiquing it didn't quite understand what they were critiquing. It's rare that you're able to actually definitively prove that out, but these results are about as conclusive as it gets.
[deleted]
Re: A Critique of React Hooks Addendum
#35Earlier quoted context omitted.
I feel going out of one's way to use a 3rd party library like Redux with React is a bit different than a database's internal query optimizer. Quite frankly the fact so many developers are replacing Redux with hooks is proof it was never the right choice for their project in the first place.
Or that Redux _was_ a reasonable choice at the time, and that with the ecosystem changing and other options available, it's worth re-evaluating use cases and updating the decision. See https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet... .
>Or that Redux _was_ a reasonable choice at the time,
Was it tho? The entire point of the post you linked is really about how "you might not need Redux" and for those who do, hooks can't replace it. If hooks can replace your usage of Redux than you never really needed Redux in the first place.
Re: A Critique of React Hooks Addendum
#36I'm not quite sure what the point of this quiz is. I don't know the answer to those questions, and yet I seem to have no trouble building very large react applications (with hooks) anyway. I would also struggle with similar quiz based on the callbacks for class components. And those I actually had to deal with on a frustratingly regular basis! At least with hooks I can remain blissfully ignorant of what happens under…
I'd definitely agree there's nuances about hook behavior that a lot of folks aren't familiar with. (Dan Abramov's mammoth post "A Complete Guide to `useEffect`" [0] ought to be required reading for all React devs, and a lot of the info in that post ought to be better integrated into the React docs directly.) That said:
- The "effect behavior runs bottom to top" has always been true about class lifecycle methods like `componentDidMount` / `componentDidUpdate`. So, nothing new there.
- Somewhat similarly, the aspect of new prop references causing some logic to run every time is not completely new, either - it's similar to how attempts to optimize rendering via use of `PureComponent`, `React.memo()`, and `shouldComponentUpdate` can "break" when the parent component passes down new callback or data object references every time.
- The complaint that "there's more stuff to learn" seems superfluous. If there was never anything new to learn, that would mean that the API was completely stagnant and that nothing new could ever be introduced. Yes, the ecosystem is in a somewhat uncomfortable transition state atm given that there's two different APIs that offer equivalent functionality, but "learning more stuff raises the barrier to entry" is not a particularly meaningful argument against hooks.
Re: A Critique of React Hooks Addendum
#37I'm not quite sure what the point of this quiz is. I don't know the answer to those questions, and yet I seem to have no trouble building very large react applications (with hooks) anyway. I would also struggle with similar quiz based on the callbacks for class components. And those I actually had to deal with on a frustratingly regular basis! At least with hooks I can remain blissfully ignorant of what happens under…
Agreed. At a certain point if experienced developers are struggling with the quiz it says a lot more about the quiz than the quiz-taker.
Re: A Critique of React Hooks Addendum
#38Earlier quoted context omitted.
One of the problems Redux is used to solve (as a global store) is peace of mind that you won't need to refactor large swathes of component trees to reparent state and callbacks that need to be shared or persisted across different subtrees as new business requirements arise. Hooks (especially custom hooks, which are just a composition of other hooks packaged together as a single function) make the reparenting/hoisting…
Replacing redux with hooks that return local state can be a road to hell, as calling the hook somewhere down the tree will duplicate the state and there is no good way to prevent developers doing that.
It sounds like you're talking about network resolved state. I like to share this sort of state using a subscription model, where components subscribe to a property of a state root (which anchors/owns the state and how to fetch it), resolving that property's state when mounted. Where that root is in the tree determines the lifecycle of the state (e.g. it's gone when unmounted), and multiple subscribers to the same property can mount, unmount, etc. at any point during that lifecycle without duplication.
I believe this model has similarities to both Apollo and Angular services, though I don't have direct experience with either.
Re: A Critique of React Hooks Addendum
#39Earlier quoted context omitted.
Replacing redux with hooks that return local state can be a road to hell, as calling the hook somewhere down the tree will duplicate the state and there is no good way to prevent developers doing that.
It sounds like you're talking about network resolved state. I like to share this sort of state using a subscription model, where components subscribe to a property of a state root (which anchors/owns the state and how to fetch it), resolving that property's state when mounted. Where that root is in the tree determines the lifecycle of the state (e.g. it's gone when unmounted), and multiple subscribers to the same pro…
No, plain useState. What you're describing can be done via Context, which gets you back to "need to refactor large swathes of component trees to reparent state and callbacks that need to be shared or persisted across different subtrees as new business requirements arise", but worse.
EDIT: quick example here https://codesandbox.io/s/unruffled-easley-ry6x2?file=/src/Ap...
This is a fairly innocuous example since the bug is immediately apparent from the button not working. Now imagine the failure mode is more subtle, and these components are about two dozen layers apart down the tree.
Re: A Critique of React Hooks Addendum
#40Earlier quoted context omitted.
Replacing redux with hooks that return local state can be a road to hell, as calling the hook somewhere down the tree will duplicate the state and there is no good way to prevent developers doing that.
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.
It 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...