Hacker News Reader

Comment by rmccue | Hacker News Reader

I agree. Up until Hooks, you could make your own toy React pretty easily if you wanted to - creating a basic, unoptimised version took a few hours. That made the whole system pretty understandable, especially for junior developers - obviously, you'd always pick the battle-hardened, optimised real React for anything serious.

Hooks fundamentally altered the contract about the API that React provided, and suddenly magic was popping up everywhere. Thankfully suspense never really caught on, because that was even more magical.

I do quite like the developer ergonomics of hooks, but it does make me wonder about whether there was a world in which we could have had both the ergonomics _and_ something less magical.

(Aside: that Medium article is available to members only.)

View on HN

But all the lifecycle methods were magic that needed to be understood... hooks just let you co-locate related logic in one place instead of scattered across 3 or 4 lifecycle methods.

I disagree that they were magic - you could build a test renderer for yourself and see pretty easily how they'd work. The system as a whole was understandable, and it fit into an existing mental model: you implement this interface, and React will call your methods. The specifics of how and when it did were part of the system on the other side of the interface.

Hooks on the other hand are functions that you call, which implicitly rely on a magic global state and context, and you cannot use them like other JS functions. You can't conditionally call them or change the order of them, because they contain a unique ID based on call order, which is Spooky (and is why React has to build its own ESLint rules to make sure you don't mess it up!).

Don't get me wrong - I do think the ergonomics of hooks are a lot better, but I think at least part of that is due to it being a newer iteration of the API.

Hooks are not like functions. They are like imports. They provide your component with piece of functionality.

You don't put imports in if-s or for-s. It's as simple as that.

From a user’s perspective, they’re not, they’re functions. That’s my point: they introduce a new concept, foreign to the language you’re writing in.

There’s not necessarily bad reasons for this, but the cognitive overhead of this is relatively high compared to existing language functionality.

They are no more just functions than require() was a function.

They use subset of function syntax to provide unique functionality. That's all.

JS was full of such things already. Functions that are hooks (in traditional sense of the word) into some platform provided functionality. setTimeout(), fetch api, promise chains, jquery. You could say that all of those are just functions but you still need to learn what each does separately to get behavior you want. JS is not Lisp where a function means just one thing used always the same way with same restrictions. JS uses functions to construct idioms that introduce functionalities foreign to the core language. React hooks are just one such idiom. You may still argue that introducing yet another idiom is unnecessary burden. I personally like them very much. Component classes were imho very bad conceptual fit for react with a lot of intricate lifecycle methods and special fields. Hooks allow to simplify the core of it to just render that just runs every time it's necessary into which you are bringing in additional functionalities as needed.

> JS is not Lisp where a function means just one thing used

Lisp uses dynamic binding for that.

  (defun do-something ()
    (funcall *something-to-call*))

  (let ((*something-to-call* 'turn-the-light-on))
    (do-something))

The behavior depends on the dynamic binding, which provides the context...

Reply on news.ycombinator.com