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

21–30 of 115 posts

Re: Why Do React Hooks Rely on Call Order?

#21

Post by kmarc »

danabramov wrote: post #2

(I edited the post title to include “React” before the “Hooks” to disambiguate. Might be worth editing the submission too!) Hope you’ll enjoy reading it.

I just briefly looked at the examples (and of course followed the twitter boom about it), but what I am not getting is that to me it looks like since useState() is against the principles of pure functional programming.

I understand that it implements some kind of inversion-of-control, but just looking at the code it feels like using some global object's method which is a big no-no. Also this importance of ordering reminds me the unmaintainable magic hell of Angular.

Maybe I'm just missing the "explicit-over-implicit" concept here. What's your opinion on this?

Re: Why Do React Hooks Rely on Call Order?

#22

Post by ecnahc515 »

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…

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 to fall apart.

Re: Why Do React Hooks Rely on Call Order?

#23

Post by matsemann »

> 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 in these ways". That would make it easier to accept.

[0]: https://news.ycombinator.com/item?id=18640612 (and the blogpost in the answer didn't really answer it)

Re: Why Do React Hooks Rely on Call Order?

#24

Post by andy_ppp »

tomjakubowski wrote: post #9
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…

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.

I don’t agree that state update ordering has ever been an issue, it’s a straw man to justify redux with. The correct solution here is to not design UI updates that can fail because of ordering! Mobx removes all the boilerplate and is far simpler to reason about and test in complex systems. Also async actions/side effects are built in, not third party.

If you haven’t tried Mobx it is definitely worth saving yourself thousands of lines of boilerplate in your next project.

Re: Why Do React Hooks Rely on Call Order?

#25

Post by davnicwil »

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 actions and their effects doesn't seem to change much at all from small to very large apps. This may come down to a well designed state tree (data model), or designing simple actions that don't try to do too much. There are actually big parallels with API design. It might even be the same problem.

So does a badly designed REST API mean REST as a concept is the cause? Of course not. In most cases, REST isn't even a limiting factor. It's just been badly designed and badly implemented. I think it's the same with blaming redux for a poorly designed, poorly implemented web app.

Re: Why Do React Hooks Rely on Call Order?

#26

Post by chrisco255 »

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…

There's two layers to front end development. There is the visual layer and the arrangement of UI elements on the screen...and then there's application state management, routing, http request handling, data caching, inlining assets, etc that all come into play as well. UI builders might help you arrange elements on the screen but they do little to help with the latter except for minor cases like click through handlers.

Re: Why Do React Hooks Rely on Call Order?

#29

Post by joesb »

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.

Re: Why Do React Hooks Rely on Call Order?

#30

Post by joesb »

politician wrote: post #20
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 have to concede though that once someone sets up the call order, it's really unlikely to change unless there are bugs or someone's coming to do some yak-shaving. People just don't write productive programs where the instruction sequencing at the function level is non-deterministic or chaotic. The UI is already insane enough with CSS and browser differences fighting you every step of the way to make it worse with…

It doesn't even matter if the call order change. Your code will be restarted.

It's the same implicit call order you have when a language runtime allocate local variable on stack.

Post reply on HN