Why recommend Hooks API?

[brody4hire]

Considering that this library has already solved the problem of using state, without needing classes, and without the gotchas described in https://reactjs.org/docs/hooks-rules.html, I was wondering why you guys would recommend the new Hooks API. Any comments would be much appreciated.

---

UPDATE March 2021: some new updates are available in react-recompose.

[rjhilgefort]

After seeing the blurb at the top of the README I came to the issues to start a discussion on this as well.

The idea and architecture of creating an ecosystem of Higher Order Components (HoC) that "do one thing well" is still valid and, in my eyes, easier to reason about than hooks. Don't get me wrong, I love hooks and the encapsulation they promote. I also agree with the statement that react-hooks can solve all the same problems, but they rely on injecting the hooks inside of your component rather than wrapping a component that would otherwise have no references to the added functionality. I still see value in working with HoCs and glueing HoCs together on top of "dumb" components.

@acdlite I know working at Facebook on the React team and that probably has some influence, but please don't "deprecate" this package. Consider rewording your statement on the README that puts forth a world where both strategies can, and would be valid, to exist.

As always, thank you for all the work you did on recompose!

[michelalbers]

I just discovered this and am greatly pleased with recompose. It cleans up my code a lot. Im my case I'm just converting all the nested <Query /> components to a nice recompose flow with loading and error branches. Will the new react hooks really be a complete replacement?

[DWMiller]

For simple things like withState the answer seems almost obvious. Basically the same amount of code, but with no composition, no dependencies, no nesting in the component tree, just a bit of react and it works.

I certainly can't speak for all use cases of recompose, but if I can get the same functionality alongside those gains, I'm all for it.

[hk-ng]

I think we should leave example of the hook API with on each existing recompose API.
Like withhandlers, mapProp

[michelalbers]

Just watched Sophie's and Dan's talk and I can see why @acdlite thinks this way. It is too early to call this library deprecated or obsolete IMHO. I like @hk-ng's idea - lets do it!

[pinyotensor]

@DWMiller IMHO, losing the ability to compose functions, or components, is not a gain.

Components should be pure functions (idempotent && deterministic) in order to be properly tested. Imagine a big store with a deep structure like {a: {b: {c: {d: {e: true}}}}}. You can abstract the connecting logic like this:

const eReusableSelector = ({a}) => ({e: a.b.c.d.e})

compose(
     getContext(MyComplexStore),
     mapProps(eReusableSelector),
)(MyComponent)

And still be able to test MyComponent because it simply takes an e prop.
With Hooks, you have to couple the selector logic to the component or to the Hook, thus needing to mock the store in the tests:

const mockedStore = {a: {b: {c: {d: {e: true}}}}}
const myWrapper = render(<Provider value={mockedStore}><MyComponent></Provider>)
// Instead of
const myWrapper = render(<MyComponent e={true}/>)

Or you can do a HOC that only contains the Hook. That is composable. Wonder if anyone would do a library for that... Oh wait, that's what Recompose is!

Another example would be composability in general: Recompose gives us some amazing HOCs that allow things like renderNothing, renameProps, or branch, that I don't see React's Hooks have any way to approach at all.

So, the conclusion for me is that Recompose solves all the problems they attempted to address with Hooks, and more on top of that, not the other way around.

[rjhilgefort]

@DWMiller Well said! My thoughts exactly!

[Synvox]

I had the same thought, but I do love the fact that hooks don't require wrapping components. Why not implement a recompose-like api on top of hooks?

https://github.com/Synvox/rehook

This project is still a little new. There are probably a few bugs. I'd love to get feedback and some contributions.

[rjhilgefort]

@Synvox Love the idea and the effort on rehook! For me, the rub is still on how the dumb/presentation component has to "know" about the hook and call it in its implementation. Doing so couples the code and removes the dependencies from the interface (the props). With recompose, the dumb/presentation components don't care how the props get to them and that allows for the implementation of the props being passed down to change as needed without affecting the component that's consuming them.

[Synvox]

@rjhilgefort I agree, and that decoupling is why I use recompose too. The nice thing about rehook is you can use it to map props to a dumb component.

https://codesandbox.io/s/0vx6nn39n0?module=%2Fsrc%2FCounter.js

import React from "react";
import { pipe, withState, withHandlers } from "@synvox/rehook";

const enhance = pipe(
  withState("count", "setCount", 0),
  withHandlers({
    increment: ({ setCount, count }) => () => setCount(count + 1),
    decrement: ({ setCount, count }) => () => setCount(count - 1)
  })
);

const Counter = ({ increment, decrement, count }) => (
  <>
    <button onClick={increment}>+1</button>
    {count}
    <button onClick={decrement}>-1</button>
  </>
);

export default pipe(
  enhance,
  Counter
);

The last line there is the important one:

export default pipe(
  enhance,
  Counter
);

Like recompose, all rehook enhancers accept and return a props object. They can be composed together as a smart component fairly easily.

[hitmands]

similar topic here #759

[rjhilgefort]

@hitmands Would you mind moving your comment over to this thread and closing your issue so the conversation is collected in one place?

[hitmands]

I am all in favour with what @rjhilgefort said.

While react hooks solves most of the issues that recompose attempts to solve, the approach taken is very different between them.

• react hooks allows enhancement by embedding business logic
• recompose allows enhancement by function composition

recompose's approach lets you build sophisticated components by composing small building blocks together (HOCs) which can be tested separately. The final dumb component has to take care of the rendering only, which can be done in a pure and deterministic way. With recompose, a dumb component can entirely work with its arguments passed as props, making it easy to test and maintain.

---

Hi! I created Recompose about three years ago. About a year after that, I joined the React team. Today, we announced a proposal for Hooks. Hooks solves all the problems I attempted to address with Recompose three years ago, and more on top of that. I will be discontinuing active maintenance of this package (excluding perhaps bugfixes or patches for compatibility with future React releases), and recommending that people use Hooks instead. [...]

I don't really think that saying "Hooks solve all the problems..." is entirely correct, react hooks gives a (kind of) life cycle, as well as state and side effect management (etc...) to functional components but recompose is still very useful from the architectural standpoint.

So, please, let's all rethink over dismiss recompose.

[gaearon]

To clarify:

Andrew hasn’t been working on new features in Recompose for two years. So declaring that he doesn’t plan to add new features to it doesn’t change anything in practice for existing users.

Andrew feels uneasy about recommending Recompose for new projects when Hooks solve a large subset of the same problems without introducing excessive tree nesting and similar issues. I agree the wording was perhaps too strong but he’s the maintainer and he has the right to point out its flaws. He plans to write a longer article to explain what he meant because it seems like there’s a lot of FUD going on.

If you’re happy with Recompose and don’t experience its downsides, you can keep on using it without any issues. New versions of Recompose will continue to be released together with React updates etc.