How can I contribute?

[tysoncadenhead]

I actually had thought of starting a project like this when I saw the announcement that Recompose is being discontinued. We use Recompose heavily at my company and while I love the idea of the hooks proposal, we have a ton of Recompose in our apps that can not be easily converted to hooks, so I see something like this as a path forward. I'm curious if you have any ideas about what your biggest needs are for contributions, whether that's getting more parity with Recompose, needing more documentation, examples, tests, code, Flow and Typescript typings, etc...

Whatever you feel like your needs might be, I would love to jump in and start helping out because I see this project as exactly what we need going forward.

[Synvox]

Hey @tysoncadenhead!

I'd love to get more examples in here. The repo is a CRA app that uses microbundle for the published copy (which looks at /src/rehook/index.js for entry). We could set up an examples folder.

Another thing is getting feature parity for the HoCs in recompose. It would be awesome if when hooks are released, all we have to do is run a codemod that does 90% of the changes for us. Some HoCs are not good choices for hooks (like pure, shouldUpdate, etc).

[tysoncadenhead]

I really love the idea of a codemod!

Do you see the path forward using a combination of HOCs and hooks, like:

import { withState, pipe, withHandlers, pure } from '@synvox/rehook'

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

function Counter() {
  const { count, increment, decrement } = useCount()

  return (
    <div>
      <button onClick={decrement}>-1</button>
      {count}
      <button onClick={increment}>+1</button>
    </div>
  )
}

const PureCounter = pipe(
    pure
)(Counter);

or are you leaning more towards render props and composing components like:

import { withState, pipe, withHandlers, Pure } from '@synvox/rehook'

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

function Counter() {
  const { count, increment, decrement } = useCount()

  return (
    <Pure>{() => {
         <div>
      <button onClick={decrement}>-1</button>
      {count}
      <button onClick={increment}>+1</button>
    </div>
    }}</Pure>
  )
}

[Synvox]

Sorry for the late reply, I was out of town.

For the case of pure, we should be using React.memo(). I'd like to push the limits of hooks and see how many use cases for composable HOCs are now enabled with hooks. So far I've noticed the following problem with hooks:

• No way to properly do an if or a function guard. Hooks must be called in the same order every time. This is unfortunate because early exits are common in with react router's <Redirect/>.

function App({id}){
  if (!id) return <Redirect to="/select-id"/>
  const [..., ...] = useState()
  return <.../>
}

The only way I can see around this is to give a new key every time this components hook order will change. :(

Outside of that though, I'd like to see this project avoid HOCs and Render Props in favor of hooks.

[morewings]

Hi. I would also like to participate in development. I'm a front end developer with 6 years experience. Always wanted to contribute to open source. We are using recompose a lot at my company.

[gwn]

👏 Same here. Would love to & will try to contribute.

[jgretz]

Are you planning on maintaining this repo? It's been a while since the last response as well as the last commit, and there are a couple of unaddressed PRs. I fully appreciate the time and effort it takes to maintain open source libraries, so it's 100% cool if you aren't planning to take that on, but it would be nice to at least know your intentions so that we can plan accordingly ...

If this is going to be a living thing, I'd contribute as well.

Thanks,

[Synvox]

Recompose is deprecated and hooks are a much better interface to reusable logic between components. The goal of rehook is to provide a path to reuse legacy recompose based code as hooks. It is a migration strategy when a full rewrite is not on the roadmap.

We should be maintaining it by fixing bugs, but not adding new features. New enhancers should really be custom hooks anyway.

[jgretz]

I appreciate you taking the time to respond and share your plans for this repo.

While I agree that hooks should be the underlying basis going forward, I also think that some of the patterns recompose introduced (and are implemented here) actually allow for more readable, maintainable, and purer code than the hooks syntax does.

My point here isn't to debate that topic though (there is enough in the recompose issue to last a lifetime). One of the the beautiful aspects of open source is that we can build on others ideas and simply fork to continue on our different paths.

So thanks again for this initial step and the time you put into it.

[jgretz]

To close the loop on this conversation, I built a library in the direction I mentioned above:

If continuing in a recompose style while gaining the benefits of hooks is something that appeals to you, I'd invite you to check out @truefit/bach (https://bach.truefit.io & https://github.com/truefit/bach)

It combines all of your enhancer calls into a single HOC wrapper, and uses hooks for the underlying functionality where applicable.