[nwienert]

I’ve now converted a good chunk of a large stack over to them and the best way to describe them is this: they are as big an improvement to React as React was to its predecessors.

This example is meant to be a pathological case. The fact that you can build complex interface logic and bundle it into a function that can then be extended and composed is a huge leap forward.

I do think Hooks will take time for some of the best ones to become standard. While I see some early “lodash for hooks” like libararies appearing, I could also see a really nice PWA that let you search gists for popular hooks or similar.

Hooks are a very nice solution to a very hard problem. But unless you’ve done large scale frontend work and especially more complex interactive components it may be hard to see. Although just getting rid of all the decorators/HOCs is already a big win.

[dbetteridge]

Agreed, we're using hooks over redux on a largish codebase and once you wrap your head around the model the only real frustration is not being able to use them in class components.

[jypepin]

By "over redux" do you mean "with redux" or "instead of redux"? I haven't used hooks yet but if you are using hooks instead of redux, it confuses me on how hooks work. To me they seems to be replacing the need for a class with local state, not replacing a redux architecture?

I'm interested to hear more please :)

[dbetteridge]

Sorry should have been clearer. It's more of a combination of react hooks and react context, hooks to deal with local state and context to provide reducer functionality for global state.

Just means you can have functional components that respond purely to effects from state changes locally or at global level

[bestest]

From my experience I found this kind of separation to be somewhat redundant and am simply using redux to manage all state — both global and local context.

This also means that components are simply components, and setTimeouts and everything else is moved out to redux thunk actions. Which makes hooks totally unneeded in my case.

[acemarke]

I'll point out that we absolutely plan to ship hooks as part of the React-Redux library, but we need to do some internal reworking first to make that feasible. See this roadmap issue I just posted for details:

https://github.com/reduxjs/react-redux/issues/1177

[lj3]

> am simply using redux to manage all state

This only works in small apps. I work on a medium sized app at work and we started that way too. It becomes a huge, sloppy mess in short order. Putting everything in Redux is akin to a desktop application that uses nothing but global state. Hooks are great because it keeps the state local, but it can be re-used across components if we need to.

[jypepin]

I would disagree with you and say that from my own experience (not saying your experience is wrong obviously) it's quite the opposite; in small applications, using local states is fine, but as soon as your application grows, having everything inside a central store makes everything cleaner and much simpler, as multiple independent components might want to share state or listen to shared events, etc.

[danlugo92]

You're unnecessarily coupling your components to redux..

[bestest]

The only things that are "coupled" to redux are actions dispatched from components. They themselves are very abstract, and when needed are connected using { connect }.

[kaoD]

> The fact that you can build complex interface logic and bundle it into a function that can then be extended and composed is a huge leap forward.

Unless you already used HOCs (in the Recompose sense).

Every single blog post is obsessed with comparing hooks with classes (I guess because it's the only thing they improve upon). What about HOCs? I'm not sure hooks are really that much of a leap forward compared to them.

HOCs only wart is their pollution of props which admittedly hooks solve (by virtue of using local variables), but hooks have their own warts too as evidenced in this article.

[mlsarecmg]

Hocs had several problems, they couldn't access context, re-using one result in another is hard, they create a new component for every thing you want to do, etc.

Take this example for instance: https://codesandbox.io/embed/26mjowzpr

It measures out the view, reads out media queries, uses the results to construct a grid, uses a hook to turn it into an animatable, and just spits out the view as if nothing happened. All of this in the same component, with small, re-usable utility functions tapping into the host-components lifecycles. Just by looking at it you know what it's doing.

This is how a component should behave from now on, an entity that hooks into the host, instead of a class the host calls into. In my experience this is the first time you can express logic linearly: x > y > z > view, without wraps, inversion of control and DI.

Now imagine doing this with hocs ... even stacking two is already destroying any hope of guessing what's going on.

[Retsam]

As someone who uses Typescript, HOCs are a nightmare, and hooks are a world of difference.