Live data from Hacker News

Introducing Hooks

reactjs.org

221–230 of 310 posts

Re: Introducing Hooks

#221

My gut reaction is that Hooks isn't the greatest addition to React. One thing I've always pitched about React is the clean and extremely explicit API (with `dangerouslySetInnerHTML` being my favourite example). The hooks API is taking the dangerous road down to implicitness and magic which can only ever mean bad things in my book. It's really not clear to me how calling the setter for these individual pieces of state…

Agreed it’s implicit. I think it works by keeping track of start and end of Component rendering and counting the function calls to useState in between. You can imagine the following sequence of events.

- Enter Component A

- Use State A0 (does not exist, set default value)

- Exit Component A

Where calling setA0 sets the value at index 0 for Component instance A and queues render again.

- Enter Component A

- Use State A0 (has existing value)

- Exit Component A

Re: Introducing Hooks

#222

Earlier quoted context omitted.

I agree. Optimizing a developer library for developers who struggle to understand what a class is seems like a good way to build something very convoluted.

There are other ways to approach an issue beyond shoving everything into a class. I'm not sure I really like the new hooks over the state methods at that level since I tend to separate global state (redux) vs component state (class) vs component state rendering (functional component). In the end it depends on your style. I think this might be useful in a way that can be more pure than some other methods might be.

I don't know what you mean by pure. There is nothing reverentially transparent about the new API. (Nor can there be, really.)

Re: Introducing Hooks

#223

> In our observation, classes are the biggest barrier to learning React. As someone who struggled hard with some aspects of learning react, i felt this to be the absolute opposite. Watching people to combine and spread logic over dozens of functional components, and drag in other external libraries like recompose to do stuff like lifecycle hooks, and using HoC's, just to avoid classes makes my head hurt. > Only call…

React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction. A better bigger-picture innovation would be to have a React-alike that is actu…

> in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else.

I'm not an expert by any means, but I wrote a fairly substantial react app recently, and I found that redux not only made this straightforward, but made it hard to do anything else. I did have to learn redux and redux- saga on top of react, but it wasn't hard.

Re: Introducing Hooks

#224

> In our observation, classes are the biggest barrier to learning React. As someone who struggled hard with some aspects of learning react, i felt this to be the absolute opposite. Watching people to combine and spread logic over dozens of functional components, and drag in other external libraries like recompose to do stuff like lifecycle hooks, and using HoC's, just to avoid classes makes my head hurt. > Only call…

While I do agree that higher order components are not the most beginner friendly pattern, to state that they are being used just to avoid classes completely misses the points of why they are used. They are a functional pattern that help one create pure components.

Yup! they can be tested separately and introduce a separation of concerns that is much better than a "simple" class that "just has everything in it". (Which usually leads to mounds of copy-paste code)

Re: Introducing Hooks

#225
post #205
post #126

Earlier quoted context omitted.

I think people are getting too hung up on the "implicit ordering" thing. The only thing that really matters about the ordering of hooks is that the call pattern remains stable between render passes. This code: const [foo, setFoo] = useState("abc"); const [bar, setBar] = useState("123"); ...is functionally the same thing as const [bar, setBar] = useState("123"); const [foo, setFoo] = useState("abc"); The feature is _d…

Couldn't useState accept a name? How would React DevTools or another debugging tool know the name of a piece of state?

I'm at ReactConf right now and I've been asking everyone this exact question.

Re: Introducing Hooks

#226

Earlier quoted context omitted.

The 'this' in 'this.setState()' tells react which component queued the setState. With the new API that information is collected by react through.. ehm.. some kind of magic. I understand why the react developers chose not to make the component an explicit argument in the new API, as it would open doors to misuse. But magic never seems to work out in the long run, IME.

I'd agree it's "magic" in the sense that it's not entirely visible to the end user. But, the key is that React is _already_ tracking _which_ component it renders as it traverses through the component tree. It's just now also keeping track of some additional data as it goes through the process of rendering that component. So in that sense, it's not any more "magical" than any of the existing render algorithm.

The problem is that the hooks seem to be much more restricting than setState. You can `if (condition) this.setState({x: 1})` but you can not with hooks because React keeps track and doesn't allow you to break out of a very narrow usage.

Look at the rules from the docs:

> Only call Hooks at the top level. Don’t call Hooks inside loops, conditions, or nested functions.

> Only call Hooks from React function components. Don’t call Hooks from regular JavaScript functions.

I think this will lead to junior developers to not understand the React framework but to just accept "the way to do things" and do what the docs say, without ever questioning anything.

Re: Introducing Hooks

#227

Earlier quoted context omitted.

React is intended to be a view-only library but in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. Because of this, innovations in React are going in the wrong direction. This Hooks feature is meant to solve a portion of this, but it's going in the wrong direction. A better bigger-picture innovation would be to have a React-alike that is actu…

> in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. I'm not an expert by any means, but I wrote a fairly substantial react app recently, and I found that redux not only made this straightforward, but made it hard to do anything else. I did have to learn redux and redux- saga on top of react, but it wasn't hard.

Just a FUCK-TON of boilerplate :P

Re: Introducing Hooks

#228
post #227

Earlier quoted context omitted.

> in practice people shove all their business logic in there, mostly because React makes it incredibly hard to do anything else. I'm not an expert by any means, but I wrote a fairly substantial react app recently, and I found that redux not only made this straightforward, but made it hard to do anything else. I did have to learn redux and redux- saga on top of react, but it wasn't hard.

Just a FUCK-TON of boilerplate :P

You say boilerplate, I say simple declarative layout of the boundaries between UI, state and state transitions. :-)
Post reply on HN