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

Hooks: React’s Do-Notation

devanshj.me

Post reply on HN
Print view View original

1–10 of 80 posts

Re: Hooks: React’s Do-Notation

#2

Post by bigyikes »

The author discusses the sequential leaps towards functional programming: from mixins, to HOCs, to render props, and finally to hooks.

I’m very comfortable with hooks, but I’m not much of a functional programmer beyond that. So my question is: what is the next step in this progression? What is after hooks?

Re: Hooks: React’s Do-Notation

#3

Post by blindseer »

I'm not well versed in React so only clicked into this article out of mild curiosity. If anyone is interested in discussing the non-technical aspects of this submission, please continue reading this comment :)

What do people think of the foray of these blog posts with embedded javascript components? It appears that this a nice way to provide interactive explanation on subjects. I think this post does a nice job. That said, the website experience is always a little off when someone uses components like this. For example, if you open the page and quickly scroll down, you get lots of flashes of the page layout changing. Also, the back history button seems to be broken after visiting this page. I think the website pushes itself to the browser history or something?

Re: Hooks: React’s Do-Notation

#4

Post by xixixao »

Interesting take, but I find it much more insightful to think about how you’d simply implement a hook (not any of the React specific ones). MobX uses similar mechanism.

user declares foo with a call to “useState”

  function useState(…) {
    useStateCalls.push(…)
  }

  useStateCalls = []
  foo()
  // do something with useStateCalls
It’s a neat syntax sugar, it explains why they can’t be called conditionally, it allows for a clean api. If every component received a “hooks” argument, like this:

  function BazComponent(props, hooks) {
    hooks.useState(…)
It would be less magic, more boilerplate (especially with custom hooks). That’s it really.

Re: Hooks: React’s Do-Notation

#5

Post by hombre_fatal »

blindseer wrote: post #3

I'm not well versed in React so only clicked into this article out of mild curiosity. If anyone is interested in discussing the non-technical aspects of this submission, please continue reading this comment :) What do people think of the foray of these blog posts with embedded javascript components? It appears that this a nice way to provide interactive explanation on subjects. I think this post does a nice job. That…

I couldn't reproduce issues with the back button.

But I barely notice the flashing / layout changes on this 2009 iMac I'm using at the moment. It's surely worth the ability to show live code that I can see and play with. It's a lot less disruptive than having to open up a React-ready playground myself and copying in the code, that's for sure.

I'll take this over static code any day when the point is to show the implication of live code as it's done in this sort of blog post.

Re: Hooks: React’s Do-Notation

#6

Post by hombre_fatal »

bigyikes wrote: post #2

The author discusses the sequential leaps towards functional programming: from mixins, to HOCs, to render props, and finally to hooks. I’m very comfortable with hooks, but I’m not much of a functional programmer beyond that. So my question is: what is the next step in this progression? What is after hooks?

I don't think anyone knows, hence all the experimentation going on in the space.

There are already pretty good ways to manage state to choose from, from mobx/reagent-style of mutating a store and things just re-render automatically, to observables/swiftui's compose reactivity, to other flavors of reactivity like Elm.

They all are better to work with than what I was doing not long ago with uikit/backbonejs/whatever. It's never obvious when you're taking on the right trade-off between boilerplate and reactive magic, though. But times are pretty good these days for building a rich UI.

Re: Hooks: React’s Do-Notation

#7

Post by acemarke »

xixixao wrote: post #4

Interesting take, but I find it much more insightful to think about how you’d simply implement a hook (not any of the React specific ones). MobX uses similar mechanism. user declares foo with a call to “useState” function useState(…) { useStateCalls.push(…) } useStateCalls = [] foo() // do something with useStateCalls It’s a neat syntax sugar, it explains why they can’t be called conditionally, it allows for a clean…

Agreed that the actual implementation of hooks is _relatively_ "simple" internally. I strongly recommend Shawn Wang's talk/post "Getting Closure on Hooks" [0] as a good dive into the implementation approach.

That said, `hooks` as an argument wasn't chosen for a couple reasons:

- It doesn't work for custom hooks, which need to be written as separate functions

- Function components still receive the legacy `context` object as their second parameter. (The long-term migration plan is that someday they will instead receive a potential `ref` object instead, and that will allow removing the `forwardRef` API.)

Dan Abramov wrote an extensive post on why various alternative hook API designs were rejected [1], including the design criteria and constraints that they were looking for.

[0] https://www.swyx.io/hooks/

[1] https://overreacted.io/why-do-hooks-rely-on-call-order/

Re: Hooks: React’s Do-Notation

#9

Post by mdoms »

Sometimes I look at what's going on in React land and just want to ask these developers, do you really need all this to make a UI? Really? Are you sure? Are you making things better?

Re: Hooks: React’s Do-Notation

#10

Post by eru »

> Well actually this is not an aphormism, it's not even a propositional statement, because “X is a monad” is just math-speak for “X is composable”, just like “Y is a functor” is math-speak for “Y is mappable”.

Nah. Monads are one relatively special way to compose stuff. And monads don't even compose very well.

To give example: the weaker applicative functors (to use Haskell's terminology) compose much better.

https://en.wikipedia.org/wiki/Applicative_functor

Post reply on HN