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

141–150 of 298 posts

Re: A Critique of React Hooks

#141

Post by spaceribs »

ng12 wrote: post #85
psmyrdek wrote: post #52

Earlier quoted context omitted.

RE: 1) "it is that components cannot reuse logic" - +1 to this - recently I re-watched original hooks talk by Dan Abramov and was not able to finish it with conclusion different than "you guys really fix issues you invented before". Class-based components and reusability of logic is something that existed years before React, and probably will exist years after React. Even this concept of Dependency Injection and Serv…

Angular does not have a solution for this as far as I know. It's not about re-using logic. It's about re-using reactive logic that ties in to your component's lifecycle.

I'd argue Angular does, in the form of RxJS.

Re: A Critique of React Hooks

#142

Post by orange8 »

stevebmark wrote: post #136

Hooks have unlocked so much power in React but still deserve critiquing. However I think the author only hinted at the major complaint I have about hooks, which is that it's no longer Javascript. It's not a function, it's sort of like type system magic. Hooks can't be nested, order matters, can't be conditionally called, and you have to understand trickier memoization to avoid bugs. It also isn't portable knowledge t…

> the major complaint I have about hooks, which is that it's no longer Javascript

Are you saying that hooks are implemented in a way that needs a compiler (e.g. like CoffeeScript or TypeScript) for them to work? I've always assumed they were implemented using closures or a similar pattern.

Re: A Critique of React Hooks

#143

Post by lucasmullens »

orange8 wrote: post #142
stevebmark wrote: post #136

Hooks have unlocked so much power in React but still deserve critiquing. However I think the author only hinted at the major complaint I have about hooks, which is that it's no longer Javascript. It's not a function, it's sort of like type system magic. Hooks can't be nested, order matters, can't be conditionally called, and you have to understand trickier memoization to avoid bugs. It also isn't portable knowledge t…

> the major complaint I have about hooks, which is that it's no longer Javascript Are you saying that hooks are implemented in a way that needs a compiler (e.g. like CoffeeScript or TypeScript) for them to work? I've always assumed they were implemented using closures or a similar pattern.

It is JavaScript, but it doesn't feel like JavaScript. What looks like a pure function isn't actually, and can do a different thing depending on where and when you run it, all hidden in some magic within the React library.

Re: A Critique of React Hooks

#144

Post by e12e »

lhorie wrote: post #48
dcre wrote: post #28

An important point I don't see being made in the article or the comments is that hooks are meant as a more faithful (or at least less misleading) representation of what was going on under the hood in React already. The problem with the JS class representation is that people already understand what classes and instances are, and that leads to incorrect inferences about how React is working. In addition to better-organ…

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". It really shows the biases of the maintainers (the "just a library" thing being a philosophy I liked from vjeux, and the "language-likeness" being very obviously a heavy influence from sebmarkbage). The thing w/ "language-ness" (as opposed to "library-ness") is that additions and c…

> 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) which is a lot closer to sml than js - and I think the state handling reflects that, like the readme for reasonml variant of redux:

https://github.com/reasonml-community/reductive/blob/master/...

"The code behind Reductive is incredibly simple. The first 40 lines include the entire re-implementation of redux. The next ~40 lines are a re-implementation of the react-redux library (without the higher-order component connect style implementation)."

In a sense, react has always been a design pattern - and a library to support/enable that pattern in Javascript.

[1] https://www.reactiflux.com/transcripts/jordan-walke#come-ide...

Re: A Critique of React Hooks

#145

Post by lucasmullens »

untog wrote: post #137
stevebmark wrote: post #136

Hooks have unlocked so much power in React but still deserve critiquing. However I think the author only hinted at the major complaint I have about hooks, which is that it's no longer Javascript. It's not a function, it's sort of like type system magic. Hooks can't be nested, order matters, can't be conditionally called, and you have to understand trickier memoization to avoid bugs. It also isn't portable knowledge t…

> React is great because it's vanilla Javascript What about JSX? It’s very useful but it’s also an absolutely huge departure from vanilla JavaScript and hides a fair amount of complexity behind what your code is actually doing.

> an absolutely huge departure from vanilla JavaScript

Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.

Re: A Critique of React Hooks

#146

Post by frank_nitti »

lucasmullens wrote: post #145
untog wrote: post #137

Earlier quoted context omitted.

> React is great because it's vanilla Javascript What about JSX? It’s very useful but it’s also an absolutely huge departure from vanilla JavaScript and hides a fair amount of complexity behind what your code is actually doing.

> an absolutely huge departure from vanilla JavaScript Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.

By this logic, what could ever be considered "huge" departure? Any new language construct "converts" to something lower level unless that language is a set of assembly instructions. I mean, Elm converts to vanilla JS but few would say it's a small departure from it.

Re: A Critique of React Hooks

#147

Post by TomMarius »

untog wrote: post #137
stevebmark wrote: post #136

Hooks have unlocked so much power in React but still deserve critiquing. However I think the author only hinted at the major complaint I have about hooks, which is that it's no longer Javascript. It's not a function, it's sort of like type system magic. Hooks can't be nested, order matters, can't be conditionally called, and you have to understand trickier memoization to avoid bugs. It also isn't portable knowledge t…

> React is great because it's vanilla Javascript What about JSX? It’s very useful but it’s also an absolutely huge departure from vanilla JavaScript and hides a fair amount of complexity behind what your code is actually doing.

The JSX is just a bunch of function calls, all the complexity is in React the library - you can do a very light JSX to DOM library with zero of that complexity.

Re: A Critique of React Hooks

#148

Post by TomMarius »

frank_nitti wrote: post #146
lucasmullens wrote: post #145

Earlier quoted context omitted.

> an absolutely huge departure from vanilla JavaScript Doesn't it just convert to React.createElement? I wouldn't call it absolutely huge.

By this logic, what could ever be considered "huge" departure? Any new language construct "converts" to something lower level unless that language is a set of assembly instructions. I mean, Elm converts to vanilla JS but few would say it's a small departure from it.

For example Angular templates, stuff like Razor in .NET, etc?

Re: A Critique of React Hooks

#149

Post by stevebmark »

vosper wrote: post #139
stevebmark wrote: post #136

Hooks have unlocked so much power in React but still deserve critiquing. However I think the author only hinted at the major complaint I have about hooks, which is that it's no longer Javascript. It's not a function, it's sort of like type system magic. Hooks can't be nested, order matters, can't be conditionally called, and you have to understand trickier memoization to avoid bugs. It also isn't portable knowledge t…

> 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 have never fundamentally understood sagas and I've tried a few times. I'm able to wrap my head around redux-loop though https://github.com/redux-loop/redux-loop

Re: A Critique of React Hooks

#150

Post by iLemming »

onion2k wrote: post #68
jwr wrote: post #57

ClojureScript user here, with a big SaaS app using React, developed over the last 4 years or so, using the excellent Rum library, https://github.com/tonsky/rum . It seems to me that React Hooks, like so many things in the JavaScript world, solve a problem I do not have. To this day, despite being a heavy user of React, I don't even fully know what they do. I've read the "Motivation" section of the React Hooks Intro,…

You've solved the problem that hooks solve by using Rum mixins instead, and you're confused why you don't need hooks?

Have you actually used Clojurescript with React? Just any cljs library - Reagent, Rum, Re-frame, Fulcro? Maybe try it, perhaps then you'd understand why Clojure developers often get confused what problems every new hype cycle in JS/TS world is trying to solve. Because Clojure idioms often nicely turn them into something you don't have to worry about at all.
Post reply on HN