Live data from Hacker News

Why Do React Hooks Rely on Call Order?

overreacted.io

81–90 of 115 posts

Re: Why Do React Hooks Rely on Call Order?

#81
post #72

Earlier quoted context omitted.

>The posters here wondering why you can't name them are on to something Imprecise phrasing on my part, the discussion here has been around naming hooks with Symbols. > We had from 5 to 8 people on the team at different times. Maybe maintaining one of the most popular open source projects isn’t “hard work” for you but we find it challenging. I meant React Hooks specifically, not Redux, which I assume is what you mean…

I’d love to hear about your solutions but maybe don’t be so quick to dismiss other people’s hard work as something to “help bloggers”. If we were chatting face to face would you also behave like this? We’re very open to good technical arguments but this isn’t one.

> If we were chatting face to face would you also behave like this?

Maybe? I usually very much would not, of course, but JS "culture" creates significant irritation and wasted time for me daily, and has for years, especially in React-land, since that's where the money is lately so it's hard to avoid. The only other software that gets me this exasperated is anything Poettering thinks up, but at least I don't personally have to work closely with any of that daily (any more, and for now).

I'm sure I'll have to deal with hooks when people around me start using them. It's less that I'm upset that they exist than I feel like I'm being gaslighted. I've read the docs, and the source, because, again, I have to know this stuff. After the initial disbelief wore off I had a good laugh, like, actual LOL. This thread is the first of many I at that moment predicted I'd see as people who really, really in their hearts and in their actual technical needs and in the language they're using, just needed OOP, but are on the JS-must-be-functional-at-all-costs hype train, expressing frustration and confusion over this feature and burning lots of time trying to sort out how OOP works when you're trying so hard to not type "this" and pretending it's something else. It's a less-useful and confusing replacement for OO that re-implements just enough of it that people will 100% for sure hang themselves with it, and omits enough that people will complain about it. It's a perfect device for generating confusion. It's going to be used for no benefit, or misused harmfully, a ton, and meanwhile everyone's gonna be very confused about it.

Ditto Redux—which is at least not funny in itself the way React Hooks are, though the flailing and consternation around it are—which is dead simple if you don't use the wrong words to describe things, yet how many person-hours have been lost trying to decipher what's going on there? So, so many. On the one hand it's funny, and I do legitimately enjoy all the accidental humor in React land. On the other I have to console, counsel, and train the folks who run into difficulty with this stuff, and live with or fix software in which it's been misunderstood and misused.

Re: Why Do React Hooks Rely on Call Order?

#82

Earlier quoted context omitted.

I'd love to debate the part about persistent call order but the rest of your comment has nothing to do with the content of my article and appears to be a generic rant. Could you help me see how it would result in "huge clusterfucks" with an example? Note React doesn't rely on particular call order. You can move your calls around any way you like. Just that it's persistent between re-renders.

Dan, I've seen this a few times already. I believe people are misunderstanding "persistent call order" to mean that they cannot change call order between versions of their app. I wonder if another name would help people understand this, maybe: "Non-conditional call order."? That does better highlight that you are worried about conditionals. (It doesn't address the loop issuie though.) Hmm, here is another one. "Stati…

Static is pretty good.

Re: Why Do React Hooks Rely on Call Order?

#83

Earlier quoted context omitted.

Sebastian’s comment (which I linked to throughout the post quite a few times) mentions we will probably do some DEV time validation with similar techniques. I really suggest to read it all — my post wasn’t intended to answer all questions. https://github.com/reactjs/rfcs/pull/68#issuecomment-4393148...

My apologies! I was on mobile when I read it last night and the RFC links don't seem to go directly to the comment on my android device for some reason! (it loads the full list of comments, but never takes me to the correct one, and searching for sebastian didn't show any results, i guess because his username is the only thing that shows up) Thanks!

Oh GitHub mobile can be pretty annoying. Glad you found it!

Re: Why Do React Hooks Rely on Call Order?

#84
post #81

Earlier quoted context omitted.

I’d love to hear about your solutions but maybe don’t be so quick to dismiss other people’s hard work as something to “help bloggers”. If we were chatting face to face would you also behave like this? We’re very open to good technical arguments but this isn’t one.

> If we were chatting face to face would you also behave like this? Maybe? I usually very much would not, of course, but JS "culture" creates significant irritation and wasted time for me daily, and has for years, especially in React-land, since that's where the money is lately so it's hard to avoid. The only other software that gets me this exasperated is anything Poettering thinks up, but at least I don't personall…

I empathize with your frustration of having to work with something you don’t like (or feel is unnecessary). I would much prefer that people who don’t like React aren’t forced to use it but that’s not how job market works. Sorry about this.

I’d love to see what OOP solution you envision for these problems. It’s not like we’re unfamiliar with OOP. In fact the OOP version of Hooks is what we had before. It’s called mixins. Mixins, like other forms of multiple inheritance, suffer from the “diamond problem” described in the post, and many others:

https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamo...

https://reactjs.org/blog/2016/07/13/mixins-considered-harmfu...

If you have an OOP solution that solves the same problems Hooks solve, but without the downsides of mixins, I’d love to hear it. You’re being vague in your proposed fix which makes it difficult to discuss.

I also want to emphasize we’re not “FP purists”. (In my opinion some codebases take FP way too far making the code very difficult to follow.) In many ways, Hooks help replace those heavy-handed patterns. So I think you might actually like them if you spend some time using them.

Re: Why Do React Hooks Rely on Call Order?

#85

Sticking to attributes on classes doesn't have this ordering issue, because construction only happens once. class Form extends ReactishComponent { name = this.useState('Mary') surname = this.useState('Poppins'); width = this.useState(window.innerWidth); constructor () { this.useEffect(() => { const handleResize = () => this.width.set(window.innerWidth); window.addEventListener('resize', handleResize); return () => wi…

How do custom Hooks look in this world?

Dan, thanks for your work on React and all the new features from you and the team. I love your stewardship of this project. React is fantastic and I’ve loved your choices of features to add. If you could just make docs less verbose...

Re: Why Do React Hooks Rely on Call Order?

#86

Earlier quoted context omitted.

How do custom Hooks look in this world?

Dan, thanks for your work on React and all the new features from you and the team. I love your stewardship of this project. React is fantastic and I’ve loved your choices of features to add. If you could just make docs less verbose...

Then other people will ask to make them more detailed :-)

Thanks for feedback though, we’re listening.

Re: Why Do React Hooks Rely on Call Order?

#87

Earlier quoted context omitted.

Can you convert the `useSubscription` example from the "diamond problem" section so we can compare "before" and "after"? A key design goal is that creating a custom Hook is easy. You should be able to literally copy paste part of your component (e.g. a bunch of useState calls and some event handlers) and call it a day. I'm struggling to see how what you're suggesting could be easy for the end user but maybe I'm missi…

Here’s what I mean: https://gist.github.com/thomasfoster96/c4a20053c747196f027fc... > A key design goal is that creating a custom Hook is easy. You should be able to literally copy paste part of your component (e.g. a bunch of useState calls and some event handlers) and call it a day. I'd totally understand that reasoning, because the keyed Hooks are more verbose and would generally require two or three parts of a co…

It is definitely possible but there’s so many more places you could make a mistake if each custom Hook has to do bookkeeping like this. I don't know if I could write or extend the code you wrote without making quite a few mistakes in the process. By comparison, I find following a rule like "calls should be static" much simpler.

My post does mention that we care about copy paste experience:

>Code passing non-unique or badly composed keys would accidentally work until a Hook is called multiple times or clashes with another Hook. Worse, if it’s meant to be conditional (we’re trying to “fix” the unconditional call requirement, right?), we might not even encounter the clashes until later.

>Remembering to pass keys through all layers of custom Hooks seems fragile enough that we’d want to lint for that. They would add extra work at runtime (don’t forget they’d need to serve as keys), and each of them is a paper cut for bundle size. But if we have to lint anyway, what problem did we solve?

I later go into why allowing conditional declarations of state or effects isn’t even particularly useful or desirable because the semantics are too confusing. So I do think I kind of addressed that.

Re: Why Do React Hooks Rely on Call Order?

#88
post #79

Earlier quoted context omitted.

Yeah you could do this but this “breaks copy paste” (one of the flaws). We want creating a custom Hook to feel exactly like extracting a function. It should feel easy and you shouldn’t need to mess with maps and symbols.

Okay, DX is an important selling factor, so your approach seems reasonable to me.

Runtime performance is another one. Map lookups aren’t free, especially if there’s a whole bunch of them happening in every component on every render.

Re: Why Do React Hooks Rely on Call Order?

#89
post #4

I’m surprised Reagent’s ratoms weren’t an inspiration. They give you a lot of Hooks functionality largely through Clojure’s native atom.

Yep. We've been using what is akin to an apollo-client hook at work for the past ~9 months or so: (defn my-component [] (let [user-data (data/pull! :user "{ user { firstName } }")] (fn [] (if (:loading @user-data) [:div "Loading..."] [:div "Hello, " (get-in @user-data [:data :user firstName]) "!"]))) I'm a bit surprised this pattern isn't more popular; having side-effectful functions return ratoms in a form-2 compone…

> That being said, I intend to replace reagent soon with just raw React + a few helpers

Do you intend to keep using ClojureScript or use JavaScript/TypeScript? I read pure React with ClojureScript is rather painful (mostly due to the props conversion but maybe that's what your helpers are for?)

I am asking since I am still considering between React (JS/TS) and Reagent/Rum (CLJS) for a side project of mine.

Re: Why Do React Hooks Rely on Call Order?

#90

Sticking to attributes on classes doesn't have this ordering issue, because construction only happens once. class Form extends ReactishComponent { name = this.useState('Mary') surname = this.useState('Poppins'); width = this.useState(window.innerWidth); constructor () { this.useEffect(() => { const handleResize = () => this.width.set(window.innerWidth); window.addEventListener('resize', handleResize); return () => wi…

How do custom Hooks look in this world?

Maybe something like this?

https://gist.github.com/sebastiaanvisser/72e6bc54baa14abc08e...

It all seems to boil down to packing and silently composing lifecycle methods. Either with classes, records of functions, or effectful functions, dictionaries.

I can see how the ergonomics of current react hooks are actually great, but I still think they’re weird :) I’ll probably get over it some day.

edit: note how hooks are now parametrized datatypes, probably allowing you to do all kinds of first class composition. Read only hooks are probably a functor and a monad...

Post reply on HN