Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Do React Hooks Rely on Call Order?

overreacted.io

Post reply on HN
Print view View original

31–40 of 115 posts

Re: Why Do React Hooks Rely on Call Order?

#31

Post by AstralStorm »

ecnahc515 wrote: post #22
woah wrote: post #14

Earlier quoted context omitted.

It's always strange when people act indignant about the fact that engineering a large frontend is difficult, like the world owes it to them for it to be easy. Frontend code is by nature highly repetitive, but each different unit has its own arbitrary tweaks because of the fact that people have to use it. This makes it very hard to abstract. There are a million visual frontend builders out there, and they are all terr…

While I agree with you, I think it's important to maybe specify that visual frontend builders generally suck -- for web frontends. In general, the visual UI builders for mobile apps tend to be very good. The reason I think it's important to mention this is because I believe that the amount of variability you have to deal with in the web is far greater, which is why I believe these visual frontend builder systems tend…

Visual UI builders for mobile cannot even handle reusable components directly. (Similar dialogs via mixin or inheritance, style extraction etc.)

Custom widgets? Amount of work to get them running in one of these is a nightmare.

Compare that to game engines such as Unity or UDK and their editors, it's so bad it's laughable.

Re: Why Do React Hooks Rely on Call Order?

#32

Post by pxndx »

joesb wrote: post #29
fogetti wrote: post #7

Beg to differ, yes, implicit call order will result in huge clusterfucks. React+Redux is already causing Frankenstein apps (which is not implicitly caused by those frameworks (ok, maybe except redux) but when you throw in react-redux, react-router, redux-thunk, etc. in the mix it just deteriorates quickly). Well the NPM report showed us the trends. Every major fad peaks around 5 years in the making in JS land and the…

When you declare a variable in your code, the variable is actually allocated a slot on the stack, which means there are implicit call orders when you declare a variable. There's nothing wrong with implicit call order when you only call it once.

But that's not exposed to the developers in a bug-prone way.

Re: Why Do React Hooks Rely on Call Order?

#33

Post by bryanrasmussen »

ng12 wrote: post #17
tomjakubowski wrote: post #9

Earlier quoted context omitted.

On the contrary: Redux's insistence on serializable events and side effect-free reducers makes debugging these pernicious "state update" ordering issues, which exist with or without Redux, a far easier job.

Agreed. I like to tell people that I like Redux's devtools more than I like Redux. There's a payoff for all the boilerplate.

if someone doesn't want to they don't need to write most of the Redux boilerplate, my last project a colleague wrote out all the boilerplate you normally see in a reducer - 100s of lines, and then I had to go write a new reducer of the same level of complexity and managed to write it with maybe 20 lines of Object.Assign and some values lookup.

For him he found my code harder to reason about because it was not explicit everywhere, but for me his was harder to reason about because I had to read the same thing over and over again with just different names.

But I wonder which one devtools would have handled easier, probably his.

Re: Why Do React Hooks Rely on Call Order?

#35

Post by k__ »

matsemann wrote: post #23

> Flaw 2: One common suggestion is to let useState() accept a key argument (e.g. a string) that uniquely identifies a particular state variable within a component. I tried asking about that earlier here on HN[0], nice to finally at least get an explanation. The tldr is name clashes when reusing hooks. A valid concern, I think they should be more upfront about the reasoning instead of "hooks are magic, don't use them…

Wouldn't symbols solve this issue?

Re: Why Do React Hooks Rely on Call Order?

#36

Post by cageface »

davnicwil wrote: post #25
fogetti wrote: post #7

Beg to differ, yes, implicit call order will result in huge clusterfucks. React+Redux is already causing Frankenstein apps (which is not implicitly caused by those frameworks (ok, maybe except redux) but when you throw in react-redux, react-router, redux-thunk, etc. in the mix it just deteriorates quickly). Well the NPM report showed us the trends. Every major fad peaks around 5 years in the making in JS land and the…

You can write really messy confusing apps with lots of magic and indirection with anything, redux included, but redux by design enforces a single, mono directional and easily traceable chain of events whenever you fire an action. Whether you have 1 action or 100, this doesn't change. It's not, in my view, a pattern which works in the simple case but doesn't scale up. Actually the complexity of understanding redux act…

In actual use I've seen that Redux apps often wind up with a lot of accidental data dependencies that probably wouldn't have happened without a centralized store. For example devs will lazily use a "currentUser" key in the store for all kinds of unrelated stuff and subtle bugs creep in. Another common problem with Redux is memory issues because various components don't clear their data out of the store when they're unmounted.

Redux has some nice features but at this point I recommend people avoid it until they start to suffer from some of the problems it was designed to solve. You can get pretty far with a lot less complexity by use using local component state in vanilla React.

Re: Why Do React Hooks Rely on Call Order?

#37

Post by thomasfoster96 »

I think this post has actually pushed me back towards Symbol keys perhaps being a good idea. The useFormInput() example under Flaw 3 seems rather contrived – wouldn’t you just pass a Symbol key to useFormInput and it would then pass the key to useState, solving the supposed flaw? If you had to use useState several times in useFormInput, just use a WeakMap (they’re not that scary) with the keys being the Symbols passed to useFormInput. Or am I missing something in the explanation?

Re: Why Do React Hooks Rely on Call Order?

#38

Post by genezeta »

k__ wrote: post #35
matsemann wrote: post #23

> Flaw 2: One common suggestion is to let useState() accept a key argument (e.g. a string) that uniquely identifies a particular state variable within a component. I tried asking about that earlier here on HN[0], nice to finally at least get an explanation. The tldr is name clashes when reusing hooks. A valid concern, I think they should be more upfront about the reasoning instead of "hooks are magic, don't use them…

Wouldn't symbols solve this issue?

Yes, and to some extent it is addressed in the link too (though not really well explained).

Symbols do not clash, but they need to be managed/stored by client code. i.e. you need to keep the original Symbol to use it in different calls, while you can use "different equal strings".

This is the argument in the article. Whether this is indeed more or less desirable than having order restrictions on calls, that's a different thing. I personally think it is indeed a better solution, but the React team seems to think it's not.

Re: Why Do React Hooks Rely on Call Order?

#39

Post by davnicwil »

cageface wrote: post #36
davnicwil wrote: post #25

Earlier quoted context omitted.

You can write really messy confusing apps with lots of magic and indirection with anything, redux included, but redux by design enforces a single, mono directional and easily traceable chain of events whenever you fire an action. Whether you have 1 action or 100, this doesn't change. It's not, in my view, a pattern which works in the simple case but doesn't scale up. Actually the complexity of understanding redux act…

In actual use I've seen that Redux apps often wind up with a lot of accidental data dependencies that probably wouldn't have happened without a centralized store. For example devs will lazily use a "currentUser" key in the store for all kinds of unrelated stuff and subtle bugs creep in. Another common problem with Redux is memory issues because various components don't clear their data out of the store when they're u…

I absolutely agree with you and that's been my experience too, I've seen exactly those problems in both my own code and others' code. It took me personally many iterations over various projects to learn the boundaries of where redux makes more sense and where component state makes more sense.

That's perhaps the biggest actual inherent problem with redux, that it may implicitly encourage everything to be in the one single centralised store, for newcomers. That's a hard problem to solve, though I'm fairly certain Dan Abramov and the other maintainers have tried to make it clear that this, and using redux at all in simple apps, is usually a mistake.

Re: Why Do React Hooks Rely on Call Order?

#40

Post by murukesh_s »

woah wrote: post #14
murukesh_s wrote: post #13

Earlier quoted context omitted.

Dont think anything was superior but that doesnt mean its perfect. It still amaze me how much time we have to spent(engineer) to get a frontend working. It really should be a completely or semi completely visual process.

It's always strange when people act indignant about the fact that engineering a large frontend is difficult, like the world owes it to them for it to be easy. Frontend code is by nature highly repetitive, but each different unit has its own arbitrary tweaks because of the fact that people have to use it. This makes it very hard to abstract. There are a million visual frontend builders out there, and they are all terr…

>There are a million visual frontend builders out there, and they are all terrible, because you can never get them to do what you want.

I disagree. I had worked with Visual Basic and it had a great balance of ease of use and flexibility. If you are not obsessed with the feeling that you need to see the underlying code of the UI, you can have a great visual builder. Of course you need to code the event handlers, that's pretty much should be the coding required. I am talking about something like webflow + code for event handling.

>require a huge amount of hacking around which results in code that is worse than what it would have been otherwise.

that is because you haven't seen a great implementation yet. and as another commenter mentioned below, mobile UI builders are better because there is a uniformity in mobile design, while desktop (web) design lacks uniformity. It's possible.

Post reply on HN