Live data from Hacker News

Introducing Hooks

reactjs.org

61–70 of 310 posts

Re: Introducing Hooks

#62
This looks like unnecessary magic. Classes are a core programming concept and this seems to be trying to get JS devs who didn't deal with them before to try and learn something else, while being completely non-transferable to any other language.

Making the built-in state management functions simpler would be better, as well as using newer JS constructs like decorators (aka attributes) to wire things up declaratively. MobX has been leading the way here for awhile with a very smooth dev UX that's even better than this Hooks proposal.

Re: Introducing Hooks

#63
post #10
post #5

This is interesting. I'll have to spend some time mulling over this before the benefits sink in. It seems like a much more confusing and less composable API than recompose, which is how I add state, lifecycle, and other React class features to functional components. I've been completely avoiding React classes for a while now and using stateless components with recompose for over a year now, and I find it to be a wond…

Right but with recompose you get extra wrapping components in your tree which is what they were trying to avoid.

What 'tree' are you referring to? Higher order components are just functional components that accept a component as a argument and return a new component. There aren't any additional nodes added to your VDOM unless you specifically make a HOC that does that.

Re: Introducing Hooks

#64
I like how it makes it possible to re-use behaviour among components, but I also really liked how classes encouraged structure and readability.

My hunch is it's only a matter of time before someone creates a helper that would enable `useState` to take complex objects rather than calling it multiple times.

Also, custom hooks seem almost too powerful - easy to build multiple abstraction layers and make the API feel magical at the point of use.

Re: Introducing Hooks

#65
post #15

"You might be curious how React knows which component useState corresponds to since we’re not passing anything like this back to React. We’ll answer this question and many others in the FAQ section." While I appreciate the functional usage of state, this type of magical behavior worries me a bit. Wasn't more straightforward semantics possible (even if the syntax wasn't similarly straightforward)?

> React assumes that if you call useState many times, you do it in the same order during every render. Note they also say: > We provide a linter plugin to enforce these rules automatically. Makes me feel a little better.

Why couldn't one just pass in `this` to useState, a key, or something similar?

Like, if I have two state variables, pass in a name for both, instead of relying on the order being the same.

Re: Introducing Hooks

#66
post #41

There are a lot of gotchas with these. Don't call in conditionals, branches, loops. Can only be called from function components. Order of invocation matters (yeck!) If the goal is helping developers "fall in to the pit of success" I think classes are a much better option than this.

Inl don't understand why they don't use a second parameter to mark the calls.

Re: Introducing Hooks

#67
Am I getting this right: it’s an implicit global stack for the render loop? Sounds like a combination of the worst design features of OpenGL and Forth, to be honest...

OTOH, React has been pretty good about taking discredited design ideas — like Adobe Flex’s style of mixing XML declarations into ECMAScript code — and injecting them with new vigor. So maybe this one too is better than the initial impression.

Re: Introducing Hooks

#68
post #51
post #41

There are a lot of gotchas with these. Don't call in conditionals, branches, loops. Can only be called from function components. Order of invocation matters (yeck!) If the goal is helping developers "fall in to the pit of success" I think classes are a much better option than this.

There are a lot of gotchas with the object-oriented way of doing these things too. Don't set `this.state` directly, don't forget to keep your side effect logic in `componentWillMount` parallel to your cleanup logic in `componentWillUnmount`, et cetera.

Yep, no doubt. The problem is they aren't getting rid of old foot guns, just adding new ones. And the new way with hooks isn't obviously superior to the old way (debatable to be sure, but with all the constraints hooks are not a broadly applicable solution to many problems). So now you've got two separate but equally powerful guns pointed at your feet.

Is that progress? I'm too old to think so.

Post reply on HN