6 ms·
This is the kind of post that suffers from lack of specific examples. I would love to see an interesting discussion of how hooks are not in line with most devel
by ritchiea 6y ago
This is the kind of post that suffers from lack of specific examples. I would love to see an interesting discussion of how hooks are not in line with most developers mental model of React and what problems it's causing (if that is indeed true, or at least true in the eyes of the author). But this post is far too generic to illuminate what the real problems are or convince me that there are any.
- neolefty 6y agoAgreed. In fact, it smells like the author doesn't know what he's talking about; in my experience "That will break for the following incredibly subtle reasons:" is usually about React fundamentals such as being deliberate with state mutations. Custom hooks are some of the most useful and fun code to write, in my experience.
- madeofpalk 6y agoI was going to say - the main reason why I like Hooks is because it's a lot simpler to reason with compared to classes, and it makes it easier to avoid whole classes (heh) of bugs. If anything, React is becoming less of a black box, with a 'simpler' API. It's just that in the process to moving to or learning the new API, people are understanding they didn't actually understand React before. They're now being made to confront that.
- hn_throwaway_99 6y ago> He is the founder of Formik and co-host of The Undefined Podcast. You can disagree with him fine, but I'm quite sure the founder of Formula knows what he's talking about when it comes to React.
- j-krieger 6y agoFormik started as a class-based library and most likely still uses some under the hood. Maybe he's just not a fan of the hook API and prefers the other way?
- dota_fanatic 6y agoFwiw, we have a stable admin client that uses Formik. One month, I went to update dependencies. Since the admin client was stable, I only updated its deps for minor versions. Four weeks or so later I get a bug report for that client. Nothing obvious or non-obvious jumped out at me in the component of concern and its blame. After git bisecting, it turns out the minor version bump to Formik had a breaking change. I've only touched that package a few times since but it never fails to make me wish the original lead hadn't used Formik. I dunno, forms in react have never given me tears, but contrary to Formik's slogan it has been painful, even aside from this versioning fiasco, so I'm not sure this endorsement is as strong as you think it may be.
- hn_throwaway_99 6y agoI'm not endorsing Formik in any way, but I don't think making an accidental breaking change in a minor version is exactly a cardinal sin. What I'm saying is silly is to say the author is somehow "uninformed" when it comes to React like he's some sort of newbie, as opposed to the guy who wrote the library that a sizable percentage of React apps use for their form components.
- nkohari 6y ago> author doesn't know what he's talking about The author is Jared Palmer. He's a well-known engineer who has worked with React for years, and the author of a very popular OSS React library (Formik).
- wulfricin 6y agoI think he is a bias against hooks since his library(Formik) doesn't work well with Hooks with react-hook-form coming up to take its throne
- j-krieger 6y agoI think you hit the hammer on the head with this one.
- KuhlMensch 6y agoOh, that seems conveivable. I used Formik long before hooks, then later, after hooks. I remember hesitating a few times because some of the exceedingly neat pattern/syntaxes were impacted negatively by hooks. I still "happy" with both, but my team is all quite senior and I feel for jnr teams trying to grapple with React AND hooks at the same time.
- krnsk0 6y agoCan confirm that Formik's hooks API is really not very good. Any change to any form component results in the entire form rerendering when hooks are used to connect to Formik context. Lost months of time in last gig to the choice to use Formik.
- Exinferis 6y agoAlthough the article is too generic, or not detailed enough regarding examples of what he states, I have to agree with what he is trying to say. React hooks are a mess, or at least code based around it tends to be. We have had our share of hooks based applications and they've become unmaintainable when reaching a certain size and I am glad that we are back to class based components wherever we can. In may opinion this comes down to the fact - as he states - that the mental model (what will happen, when I do this) is not simple to grasp, thus not predictable for many people.
- alfonsodev 6y ago> React hooks are a mess, or at least code based around it tends to be. I've read a lot warnings about the pitfalls, and about hooks not doing what you think they are doing, but honestly, I haven't experience any of that, maybe because my use cases are so close to the documented ones, that I don't need to stretch the concept, and it just works as intended for me. Could it be, that as with many other programming patterns, some developers are using it as a silver bullet, and trying to solve everything with hooks? Otherwise I'm failing to understand, it would be useful to see examples as the mentioned above.
- emerongi 6y agoHooks are a bit of a double-edged sword in my opinion. On the one hand, they are nicely composable. You can make one hook call depend on another and you can easily build a lot of cool functionality thanks to this. On the other hand, you are no longer able to directly follow the flow of the code. Making a change to a series of hook calls can sometimes be scary to me as it can be hard to fully understand the cause-and-effect of that change. On the one hand, you can hide a lot of complexity behind a simple `useSomething()` call, on the other hand the code inside `useSomething()` can be absolute horror, because all the stateful logic is handled through hooks. Any non-obvious use-case ends up being a mess of hook calls. If you only write the code once and never need to touch it again, `useSomething()` can be an amazing hook though. There are some hooks that I have written that I hope I (or anyone else) don't ever have to touch. I might just be a bad programmer though, or missing some obvious patterns. TLDR: hooks work well, but they have downsides in terms of maintenance burden
- deleted 6y ago[deleted]
- ricardobeat 6y agoOk, quick test: can you explain in a paragraph why you cannot call a hook inside a for loop?
- cnity 6y agoSo easy I can explain it in a sentence: React hooks must always be called in the same order, and the same amount. If you push me by asking "why?", I can expand that sentence by including "because each hook call is associated with an index under the hood". This is probably the only React hook nuance you really have to understand, and it's not particularly difficult.
- ricardobeat 6y agoWhich means you can call it inside a for loop if you have guarantees that the order will always be the same. These are the caveats that don't fit in one paragraph. Also, repeating the rule 'it has to be called in the same order' is not explaining how it works.
- cnity 6y agoWhat makes the fact that each hook call needs to be associated with an index so unacceptable?
- ricardobeat 6y agoYou could say each call corresponds to a timestamp and they need to be ordered, and the person receiving that information would be none the wiser. It just doesn't lead you to understand what's happening underneath. Some may be fine with stopping at that level of understanding, but the stack-based approach of hooks is quite unnatural for JS and I don't think it is good in the long-term for developers to just 'accept' that as supernatural.
- cnity 6y agoSo in order to understand not only the basics of the rule, but also the underlying implementation and exactly in what way it would crash, it may require more than a paragraph. I'll concede that. But this is common in programming. As an example, you'd probably spend some time understanding exactly why it is you can't free a pointer twice in C. There's nothing stopping someone from reading the explanation in the React docs[0] if they want to understand. [0] https://reactjs.org/docs/hooks-rules.html#explanation https://reactjs.org/docs/hooks-rules.html#explanation
- duxup 6y agoWay too many articles like this that don't provide examples. They'll say something and I'm wondering "what do you mean exactly..." but we don't know. I get how folks might not want to get into the weeds on minutia or etc. But without examples it's hard not to think someone just doesn't 'get it' too.
- varrock 6y agoA trend I've been seeing on HN and Reddit alike are articles that are not in depth, but allow the users of the medium in which they are shared to have a reason to talk about something. This post probably got more attention because it was a dedicated link versus somebody asking HN if they think React is becoming a black box. I'd much prefer the latter, but it seems that links are the way of websites such as these.
- ritchiea 6y agoThe quality of posts at the top of HN has really tanked over the last 2-3 years. Falling from high quality to “programmer clickbait” like the OP here. It’s a little better if you use /classic as a path, which I understand is only calculated by upvotes from users from the first couple years of HN, before the startup boom. Occasionally /news and /classic are virtually identical making me wonder if there are a lack of active OG users and the algo falls back to default during a lack of classic participation.
- daliusd 6y agoI can give example. Svelte has actions (here details https://svelte.dev/tutorial/actions https://svelte.dev/tutorial/actions). You can take pannable action as a starting point from that page. Now try to write React hook that does the same as pannable Svelte action. You can do it. There are "problems" however: 1) React solution will need a little bit more lines; 2) There are multiple ways to write that and some ways are less efficient than others; 3) React solution is harder to write if you only started with hooks. I'm going to use React because: 1) I don't need to learn anything new (only hooks) to do what I need; 2) I have richer environment: typescript, testing libraries and all React libraries/solutions I might need. Svelte is getting better and potentially it already covers things I need but that was not the case one year ago.