3 ms·
1. It's not more stuff to learn, it's different stuff to learn, arguably less. Learning Components is not a prerequisite for learning Hooks. Or perhaps I missed
by pacala 6y ago
1. It's not more stuff to learn, it's different stuff to learn, arguably less. Learning Components is not a prerequisite for learning Hooks. Or perhaps I missed the memo, as I've built an app using Hooks, and still haven't need to learn what 'componentWillMount' is supposed to do.
2. Don't mix Components and Hooks.
3. Agreed, change is hard. It's also the only way to avoid stagnation. In the long term, change wins. Or else we'd be programming in JS1995.
4. Insufficient example. What is the business case for a memoized hook returning hooks? Perhaps there is a simpler design, can't comment.
5. There is no global control flow. There is only per function component control flow, which proceeds from top to bottom. Possibly preempted by a hook/hookfn execution, if my early learning curve is to be believed. Which shouldn't matter if one is thinking in terms of 'pure functions returning jsx', as preempted functions do not return, thus have no observable effect.
Tip: Only change hook state from event handlers, never from render function code.
- viklove 6y ago> In the long term, change wins. Or else we'd be programming in JS1995. Change for the sake of change is not a sound argument. The thing about hooks is they don't enable a single thing we couldn't already do with HOCs. They are also much harder to read, because stateful logic is now just sprinkled around your render method rather than being isolated to places you know to look for it. I won't be using hooks ever, as far as I'm concerned.
- pacala 6y agoOf course. * "A Critique of React Hooks" * "A Critique of the Change Costs Induced by React Hooks". Objections to React Hooks are stronger if they don't invoke change costs as the primary three concerns.
- runawaybottle 6y agoHe/she gave a very valid critique of state being jammed into your render method, vs state being handled in a predictable pattern in Class components. And lastly, let’s not minimize change-cost. In the real world, it’s a cost. We’re all willing to pay it if it’s necessary, or affordable, but not because someone showed up and said ‘change please’.
- Scarbutt 6y agoUnless you learnt react from non-official sources, you can't avoid learning components because they teach them first.
- pacala 6y agoYou'd be surprised. The only deeper dive into Components is https://reactjs.org/docs/state-and-lifecycle.html https://reactjs.org/docs/state-and-lifecycle.html of the "Main Concepts" section, which I skipped in favor of https://reactjs.org/docs/hooks-state.html https://reactjs.org/docs/hooks-state.html of the "Hooks" section. Haven't got to "Advanced" yet, hope to stay clear of that.
- acemarke 6y agoThe React team is working on rewriting the docs to focus on function components and hooks first, as of this quarter: https://www.reddit.com/r/reactjs/comments/g2pda4/functional_components_vs_class_components/fnmtl5r/?context=3 https://www.reddit.com/r/reactjs/comments/g2pda4/functional_...
- pier25 6y ago> In the long term, change wins Yes, but how long is long term? jQuery hasn't radically changed its methodology in almost 15 years.