When React Hooks have been announced I was thrilled about its possibilities and worried about the community's feedback simultaneously. Luckily, the feedback from the community was mostly positive. One of the things I thought would be a challenge are proper typings. Here, it seems I was wrong and the typings are actually straight forward and supportive as usual.
So am I converting all existing React (class) components to functional components using hooks? No! For once some of these components rely on older versions of React (and I don't want to force an update yet). Another reason is that hooks can be a cure for many constructs that made class components necessary, but not for all.
Am I writing all new React components in a functional way? Absolutely, there is no more reason to use a class. If I would really require a feature that is only available to class components I would potentially put it in a reusable HOC and plug my component into the HOC to provide the missing functionality.
Why do I love React Hooks? I think they make code much simpler. Yes, they provide some magic, but after all we have been used to magic with React. The runtime in React is very powerful and taking care of the reconciliation and rendering / instantiation was always something we did not worry about too much. We only tell React how the UI should look like and React does the rest. Now with hooks we can finally also just express that we want have something from the React internals (like state or lifecycle access) and that's it. When that happens and how that looks it left to React. In the end all we care about is the API and what it allows us to do.
There are two things that are certainly a little bit more challenging / problematic (at least at this point) with React Hooks. The first thing is a faulty bundle. Earlier, React gracefully handled multiple React instances in a single bundle. Even though this is an obvious mistake by the bundler (or made necessary through a non-peer dependency in some dependency), it mostly did not hurt much earlier on. Yes, only one React instance was responsible for rendering, while the other one just provided a definition of a sub-tree.
Now with hooks such a setup would not work as only the one responsible for rendering sets the current dispatcher. As a consequence, when the definition of the subtree is created calling the functional components with React Hooks will be terminated as no current dispatcher will be found in the auxiliary React instance.
The other problem is testing. Here we have two ways to test hooks. Either mock the core React hooks (e.g., useState, useEffect, ...) or place the hook in a stub component that is normally rendered by React. Personally, I faced a problem with enzyme, which is currently not capable of properly handling hooks. Therefore, I had to mock away the hooks in every component that was using hooks. For me, this is not a big deal as I tend to test the hooks separately.
What is your take on hooks? Do you also feel liberated by them? I hope you are as enthusiastic about them as I am!