1

The title should give you the general idea. I (my company) want to start a new project, which is a reboot for our current website writing in Angular v1, with React. I want to know if this is a good time to use React Hooks in production and what risks that I'll take if it is.

PS: There'll be no right answer, I just want to get some opinions to consider before implementing. Thanks in advance.

Pho Huynh
  • 1,497
  • 3
  • 13
  • 23
  • As react hooks get popularity in developers in a very short time. There's no risk if you want to use react hooks in production. – Error Yatish Apr 22 '19 at 04:51

2 Answers2

2

As of now, hooks have some problems with testability and debugging. The state of a hook can't be tracked with a debugger on component instance as it's done with class components, this is possible only with React dev tools. Enzyme doesn't fully support hooks yet. Hooks may be harder to mock or spy than component lifecycle methods because this can't be done on component instance.

Hooks have several inherent problems that sometimes need to be addressed in counterintuitive and overly complicated ways.

There are well-known problems with useEffect and useLayoutEffect function scopes that don't work well with setTimeout, events and other kinds of callback-based APIs (workarounds are described in this answer).

That there's no counterpart to shouldComponentUpdate may result in component nesting to prevent unnecessary updates. This especially applies to useContext. If there's a need to prevent updates, this isn't much better than context Consumer and requires to use nested component:

const WrapperWithConsumer = () => {
  return <FooContext.Consumer>
    {({ foo }) => <PureWrappedComponent foo={foo}/>}
  </FooContext.Consumer>;
}

const WrapperWithHook = () => {
  const { foo } = useContext(FooContext);
  return <PureWrappedComponent foo={foo}/>
}

As any other recent API, hooks restrict a project to be used with up-to-date React version, prevent its components from being reused in older projects and take away the opportunity to switch to alternative implementations - Preact, Inferno, etc.

Estus Flask
  • 206,104
  • 70
  • 425
  • 565
  • We're starting a new project and we don't intend to reuse its components in older project (we don't have one), vice versa so it won't be a problem. With a careful use of `useEffect` and `useMemo`, I think it's really that necessary to find an equivalent to `shouldComponentUpdate`. In the link about Enzyme issue, I thought it will be a matter of time before Enzyme supports hooks. Smart people on Github did find a workaround for that in the mean time: https://github.com/reactjs/rfcs/issues/71#issuecomment-464658241 What do you think? – Pho Huynh Apr 22 '19 at 07:47
  • Yes, change detection is achieved with useEffect/useMemo inputs but this may become messy. The problem with testability isn't just that hooks don't render. They are harder to test when you test the implementation. There's a bunch of closures that cannot be accessed outside the component for spying or mocking. This seriously limits ways a component can be tested. As of now, a state cannot be tested yet, https://github.com/airbnb/enzyme/pull/2008 . – Estus Flask Apr 22 '19 at 08:15
  • As for me, hooks are still a no-go. They seem to be a consequence of the obsession with FP that developed in React community. There may be 5 cases for them where hooks look really neat - and then there's 1 that makes you jump through hoops in such a weird way that makes class components look like state-of-the-art design. – Estus Flask Apr 22 '19 at 08:23
  • I find it odd that you wouldn't still use hooks for those 5/6 times where it works great, given they work interchangeably with class components. Not sure about the comment re FP - a large part of it had been to solve common pains React users have struggled with over the years (more details [here](https://reactjs.org/docs/hooks-intro.html#motivation)). – James Apr 22 '19 at 18:15
  • @James 5/6 sounds like a roulette. You don't always know if it's 1/6 when a component is created. Even if you did, every 6th class component would break the style. I'm aware of the motivation and I think that the team is biased in this regard. E.g. *you will likely find a “wrapper hell” of components* - my example with useContext shows that hooks don't help against that once a case is outside their comfort zone. As a comment above mentioned, shouldComponentUpdate is another weakness of hooks. 'struggled' is too strong word, there's not much to struggle with if you follow best practices. – Estus Flask Apr 22 '19 at 18:42
  • This probably isn't the correct place to debate this but this just all sounds a bit exception over rule to me, none of the issues you've mentioned here are things I'd class as a dealbreaker (e.g. I could count on one hand the number of times I've actually had to use `shouldComponentUpdate`). It sounds like you are suggesting the React team have an agenda for pushing hooks? – James Apr 22 '19 at 19:47
-2

You can always try, but i wouldn't recommend it as that technology is still in an early stage, try a class component first and then evaluate to use hooks.

also maybe this article helps you: https://blog.logrocket.com/react-hooks-lets-not-get-too-attached-11b0ac09b4b5

Aldemaro14
  • 23
  • 1
  • 7
  • 1
    I don't think the article is fit in the time frame. It was written in Nov 2018, the time that hooks is in alpha version, now hooks is officially released which is very very different. – Pho Huynh Apr 22 '19 at 04:58