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

A Critique of React Hooks

dillonshook.com

Post reply on HN
Print view View original

281–290 of 298 posts

Re: A Critique of React Hooks

#281

Post by greatwhitenorth »

untog wrote: post #272
greatwhitenorth wrote: post #269

Earlier quoted context omitted.

We're talking two different things. I'm talking about the developer perspective. You're talking about browser. If a JS developer doesn't work or understand JSX, they don't understand the fundamental concept of JavaScript which is what an expression is. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. There is nothing more to it.

> We're talking two different things. I'm talking about the developer perspective. You're talking about browser. I'm not. I'm talking about a programming language. It has a spec. "if you know JavaScript you know JSX" - JSX is just a JavaScript expression. This is nonsense. Where is JSX in the JavaScript spec?

You talk nonsense just for the sake of it. I never said JSX is in the spec. If you know JavaScript basics (what an expression is), it takes a minute to understand JSX.

Re: A Critique of React Hooks

#282

Post by e12e »

lioeters wrote: post #258
e12e wrote: post #144

Earlier quoted context omitted.

> It's interesting that the original appeal of React was that it was "just a view library", but now apparently it's more like a "language" Well, it was prototyped in standard ml first[1], wasn't it? - then ported/re-implemented (shoehorned ;) into plain js. So some things that sml has, and made sense in sml, had to become part of the library/language/framework that is react? Later came reasonml (a ocaml dialect) whic…

Thank you for this latter link where the original author of React describes its beginning. After reading it, I finally feel like I'm starting to understand where React came from, why it's designed the way it is. The paradigm shift that React brought to JavaScript was to "bend the language" to implement concepts and design patterns from ML, a functional language with roots in Lisp, with static typing, algebraic data t…

You're very welcome. I do believe looking at reasonml and reasonreact is a good way to gain insight into reactjs. It's on my (so very long) to-do-list.

Ed: as an example, I found this (oldish) post on hooks in reasonreact:

https://dev.to/iwilsonq/reasonml-with-react-hooks-tutorial-b...

Compare as you will with a comparable one for reactjs:

https://upmostly.com/tutorials/build-a-react-timer-component...

Note - I would advice looking at the reasonreact documentation for up to date tutorials and guides... It's a quickly changing landscape.

Eg:

https://reasonml.github.io/reason-react/docs/en/usereducer-h...

Finally I came across this - I thought maybe a sibling comment mentioned it - but a quick search didn't turn up anything - but imo it's a pretty strong argument for hooks (in js react) :

https://tylermcginnis.com/why-react-hooks/

Re: A Critique of React Hooks

#283

Post by kilburn »

acemarke wrote: post #164
vosper wrote: post #139

Earlier quoted context omitted.

> I look back on all our HOCs and function as children and shudder compared to how easy it is with hooks. If by "function as children" you're referring to render props, personally I was really happy to see that short-lived fad die out. I don't think render props made things simpler. Now if we can admit we never needed Sagas just to do some data fetching maybe we can burn that stalled-out old bandwagon, too :D (Sagas…

I'm a Redux maintainer, and yes, I keep trying to tell people that 95% of Redux apps don't need sagas. They're a great power tool for those cases when you have truly complex async workflows, but they're complete overkill for basic data fetching behavior. I wrote about why I chose thunks as the default in our Redux Toolkit package: https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh... and our Style Guide doc…

I've gone through your recommendations and adopted most of them. This one feels really strange though. In the recommendation you say:

> If you have truly complex async workflows that involve things like cancelation, debouncing, running logic after a given action was dispatched, or "background-thread"-type behavior, then consider adding more powerful async middleware like Redux-Saga or Redux-Observable.

Aren't these kind of things necessary for really robust applications? For instance, let's say my app fetches some "posts" list and shows it as a table. I have so many "posts" that I'll do server-side pagination. With a naive thunk, if the user clicks on "page 2" and then quickly on "page 3" it is perfectly possible that she ends in "page 2" (because that request happened to complete after the one for "page 3").

How are we supposed to deal with these things with thunks?

Re: A Critique of React Hooks

#284

Post by golergka »

karatestomp wrote: post #273
omniscient_oce wrote: post #235

Earlier quoted context omitted.

I honestly don't know how hooks work that well but I find them easier in general to make quick reusable stuff or just plug things in without having to worry about layers deep of Higher order components. There used to be class = logic , pure function = takes data and outputs jsx. But now functional components manage their own state and somehow trigger rerenders of themselves (how do they do this btw?). So they don't r…

How objects work: there's a lookup table for methods and properties associated with your instance to find them by name (or call signature, or whatever). How hooks work: there's a lookup array associated with your instance (yes, an instance of an object—read the code if you're skeptical, and besides functions are objects in JS anyway so even if I'm wrong, which I'm not, I'm technically right) to find properties and me…

So, closures are indeed poor man's objects.

Re: A Critique of React Hooks

#285

Post by acemarke »

kilburn wrote: post #283
acemarke wrote: post #164

Earlier quoted context omitted.

I'm a Redux maintainer, and yes, I keep trying to tell people that 95% of Redux apps don't need sagas. They're a great power tool for those cases when you have truly complex async workflows, but they're complete overkill for basic data fetching behavior. I wrote about why I chose thunks as the default in our Redux Toolkit package: https://blog.isquaredsoftware.com/2020/02/blogged-answers-wh... and our Style Guide doc…

I've gone through your recommendations and adopted most of them. This one feels really strange though. In the recommendation you say: > If you have truly complex async workflows that involve things like cancelation, debouncing, running logic after a given action was dispatched, or "background-thread"-type behavior, then consider adding more powerful async middleware like Redux-Saga or Redux-Observable. Aren't these k…

Cancellation is definitely something that is trickier with thunks. We recently added a new `createAsyncThunk` API [0] to our Redux Toolkit package, which has built-in support for signaling some kind of cancellation using an AbortController [1], but how that gets used in relation to your actual async call and how your reducer processes the responses is up to you.

Cancellation, debouncing, and other "thread-like" behaviors are where sagas are truly useful. But, in most cases folks are just trying to do simple AJAX requests for data fetching, and trying to learn how to configure and use sagas just for that is way too much overhead.

[0] https://redux-toolkit.js.org/api/createAsyncThunk

[1] https://redux-toolkit.js.org/api/createAsyncThunk#cancellati...

Re: A Critique of React Hooks

#286

Post by karatestomp »

golergka wrote: post #284
karatestomp wrote: post #273

Earlier quoted context omitted.

How objects work: there's a lookup table for methods and properties associated with your instance to find them by name (or call signature, or whatever). How hooks work: there's a lookup array associated with your instance (yes, an instance of an object—read the code if you're skeptical, and besides functions are objects in JS anyway so even if I'm wrong, which I'm not, I'm technically right) to find properties and me…

So, closures are indeed poor man's objects.

It's storing all the hooked-in functions (methods) and variables (properties) outside the function and associating them with the relevant React view object instance at run-time, which is effectively the hooks' "this". Unless the code's change substantially and in very fundamental ways since it was introduced. It doesn't bring to mind closures, at least as I read it. It very much brings to mind object/class-system implementations.

Re: A Critique of React Hooks

#287

Post by Gehinnn »

desc wrote: post #161
Gehinnn wrote: post #158

Earlier quoted context omitted.

Yes. Except mobx ;) I like to use function components together with class based observable view models. Only a single hook wires them up. Works like a charm and avoids all the IMHO confusing hook complexity.

Hmm, so the reusable bit is the straightforward inject-everything component, driven by an app-specific, app-aware hook-using part? I can see how that can work for simple cases. Nesting components is going to get tricky though if the classes don't operate exactly the way the hooks expect. Of course that's the problem: someone built hooks for their trivial cases and now they're the 'preferred' approach... Edit: To clar…

This is how we use it: https://imgur.com/a/I6BD4vF To be honest, we abstracted hooks away.

It works for arbitrary complex cases.

Re: A Critique of React Hooks

#288

Post by mx2323 »

desc wrote: post #156

I'm going to express something a lot of people are thinking and are being far too diplomatic about. React Hooks are a fucking stupid idea and always were. They're basically just adding dynamic scoping to a language and framework which doesn't need it, in one of the most 'magical' and confusing ways possible. You have to care about execution order to understand exactly how they'll all work and that will bite you event…

well, from my point of view i write 40% the amount of code with react hooks than i did with react classes, i probably reused about 40% more code, and can write components 50% faster than before. i also refer to React documentation about half as much as before.

not sure what's 'fucking stupid' about that.

it might be harder to grok at first - but that's the reality of tools - by nature, they get more complex but more elegant, i think it's fucking stupid to want to go back to componentDidMount()componentDidUpdate, componentWillReceiveProps, componentWillUnmount, getDerivedStateFromProps and UNSAFE_componentWillUpdate. like... really?

Re: A Critique of React Hooks

#289

Post by lioeters »

e12e wrote: post #282
lioeters wrote: post #258

Earlier quoted context omitted.

Thank you for this latter link where the original author of React describes its beginning. After reading it, I finally feel like I'm starting to understand where React came from, why it's designed the way it is. The paradigm shift that React brought to JavaScript was to "bend the language" to implement concepts and design patterns from ML, a functional language with roots in Lisp, with static typing, algebraic data t…

You're very welcome. I do believe looking at reasonml and reasonreact is a good way to gain insight into reactjs. It's on my (so very long) to-do-list. Ed: as an example, I found this (oldish) post on hooks in reasonreact: https://dev.to/iwilsonq/reasonml-with-react-hooks-tutorial-b... Compare as you will with a comparable one for reactjs: https://upmostly.com/tutorials/build-a-react-timer-component... Note - I would…

Nice resources! I've bookmarked them for later study.

That last one I like, especially where the author recommends to "forget everything about lifecycle methods" and think of hooks in the context of synchronization. It makes sense, as a declarative way to describe state and state transitions.

The aspect that's unsettling is that they're not idempotent pure functions, but rather deeply tied in with how React works internally. They can't be used outside of React, and require the programmer to understand the magic that makes them stateful.

The common issues that beginner users of hooks encounter, like the "captured scope" of variables, or that hooks must be run in the same order every time, never conditionally - I suppose these are some reasons that make me (and other hook skeptics) react to them as "code smell". If someone had designed a library totally unrelated to React this way, I wouldn't want to use it.

Looking at ReasonML, it's quite elegant and intuitive how React Hooks fit in. In fact, the code examples look very similar to how I structure my React projects, with state and actions (instead of a reducer or Redux, they use immer for immutable state changes).

I'm staying open-minded about hooks, and I think the more I learn of its roots, the more I'll come around to accepting them as part of idiomatic React.

Re: A Critique of React Hooks

#290

Post by stevebmark »

deckard1 wrote: post #42

Hooks elucidate everything I've felt wrong about React, but have not been able to put my finger on it until recently. Hooks reveal two major things with React: 1) React developers did not understand the component paradigm that they originally went with. If they did, then they would understand how silly it is that components cannot reuse logic. This was an entire debate many years ago. Composition vs. inheritance. You…

When saying that "functions do not have state" without mentioning monads and encoding effects in type systems, it doesn't sound like you have enough experience with functional programming to assert your second claim.
Post reply on HN