Why we've moved to React Hooks

For an introduction to React Hooks and how to use them, check out this JDLT video - An Introduction to React Hooks

Get Hooked

Knowing when to change can be a tricky thing to get right in the world of coding. On the one hand, finding better, easier ways of doing things on a regular basis is part of what makes the job fun. On the other, you’ve got things setup the way you like them, you know what practices work best and which libraries and frameworks you can bend to your will, and you’ll be damned if you’re going to swap up everything for the latest fad.

Besides, even if you did want to try something new, there’s a lot of code in your hulking monolith that would need refactoring and/or an endless line of people with an opinion that would need to be convinced.

And there are good arguments for both sides. Stick to what you know, and how are you ever going to take advantage of the things that could make a real difference to both your code and productivity? Leap on every new thing like a hyperactive kitten and pretty soon you’ll have little coherence in your structures and you’ll be spending all your time updating everything and going nowhere.

At JDLT, we lean more towards playing with the shiny things, partly because we can. We have the luxury of being small, agile, and able to rapidly incorporate the kind of new technology that we can see will clearly make a positive difference. That’s why we love the serverless Lambda life and embraced GraphQL like a long-lost friend.

When the stable version of React Hooks was released, our initial thought was: “Sounds interesting.” Then, “That makes sense”, followed by “That’s really cool!”, and for a while, “Wait, how does useEffect work?” before settling on: “Hooks are life".

You can find out some more about how Hooks work, some important ways they differ from React classes, and some examples of how we’ve used them in this Lunch and Learn video . In this blog, we’ll look at some reasons why changing to Hooks was such an easy decision for us at JDLT.

This is React

React has been around for more than five years, it’s everywhere, and it’s not about to disappear any time soon. But we are now in the twilight of the classical component age. Of course classes will be supported for a long time yet, and there’s no urgency to changing over to Hooks; React themselves have been pretty clear about not engaging in any major refactors or worrying about having to shift to Hooks. Classes aren’t going anywhere, but they’re also going nowhere.

Hooks are what React is now. Or what it’s always been, really. Because Hooks just give us a more direct way of accessing those React properties we’re familiar with. They offer a chance to strip a layer of complexity inherent in classes away from React and - once you’ve got your head around a slightly different way of thinking - build components that are cleaner, more modular, and are more explicit in their data flow.

Functions > classes

No one likes classes in JavaScript, it turns out. I’m not sure how long people have been holding on to this resentment, letting it fester inside, but the backlash is coming and classes seem to be rapidly becoming about as popular as David Benioff and D.B. Weiss at a Games of Thrones fan convention.

OK, that may be going a bit far, but when it comes to React, choosing between a classical and functional component is now, thanks to Hooks, a no-brainer. Working with this is fine once you’re used to it, but it takes a while for people to learn, and that’s before you’ve taken on concepts like constructors and binding. All important things to know, but ultimately unnecessary baggage in a component if you can read and write state with minimal effort and fewer bugs using nothing more complicated than:

const [myVar, setMyVar] = useState('')

At a conceptual level, having a state variable and a function that updates it in one declaration available to the whole component is just simpler. Yes, things get more complicated once you start bringing in useEffect and other Hooks such as useReducer, but most of the hard work is just a question of unlearning the structures imposed by classes and instead thinking about components in a cleaner, more logical fashion.

Most importantly, functions behave in a more predictable fashion and aren’t subject to the same kinds of… oddities as classes.

State sharing

This is the big one. Being able to easily share reusable behaviour between functional components makes things so much simpler than some convoluted options available to classical components. For instance, we found ourselves writing out the same code again and again in all our components that communicated with our back-end services. Thanks to custom hooks, we’ve been able to package all that repetitive code into a single custom hook and now in our components, one line of code gets our data, loading state and a function to update the data.

And that’s just one of many instances that have enabled us to move all the necessary pieces of filler code that populate a component into their own concerns. Doing so declutters the component, which, and you might be noticing a common theme by now, makes everything less complex, more readable and better structured.

Modular mania

Carrying on that theme, Hooks emphasise one of the things that made React great in the first place, namely that it allows code to be broken up and modularised into manageable chunks, each of which does what it needs to do and no more. There are fewer tricks and a lot less smoke and mirrors required for the code to do what you want it to do, and look how you want it to look.

Future now

Should you switch to Hooks right now? If by that you mean, should I rewrite my entire codebase, then emphatically, no. But we’ve been using Hooks for a few months now, introducing them in bits and pieces alongside classes, and the benefits are clear. There is a certain cost involved with learning new ways of doing things in React, and it’s been frustrating at times having to rethink solutions to common problems, but we’ve yet to find a scenario where we thought that a classical component would ultimately offer a simpler or better solution. Instead, our code has become cleaner, more comprehensible and more reusable. All good stuff.

As a starting point, just try building out any simple, new components using Hooks. Pretty soon you’ll be writing custom hooks, mastering useEffect, and wondering why you ever needed classes in the first place.