Introducing Hooks
61–70 of 310 posts
Re: Introducing Hooks
#62Making 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
#63This 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.
Re: Introducing Hooks
#64My 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"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.
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
#66There 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.
Re: Introducing Hooks
#67OTOH, 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
#68There 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.
Is that progress? I'm too old to think so.
Re: Introducing Hooks
#69Re: Introducing Hooks
#70> It’s hard to reuse stateful logic between components
Recompose kind of solves this. Why add this to the core API? What am I missing?