React Best Practices: How to Write Better React Apps

Rafael Quintanilha — Wed, 07 Sep 2022 19:58:00 GMT

What is React and why use it?

While web development isn’t new, some aspects of it are. In particular, frontend engineering is somewhat of a new term. Back in the day, you would see “web designers” and “webmasters”, but rarely frontend developers.

There’s a good reason for it - there was no need! Websites were simple, mostly static, and the bigger complexity was around designs, not functionality.

Needless to say, we are way past that now. Websites evolved into web apps, browsers became more powerful and the era of desktop applications is over, disrupted by the eruption of mobile devices. While it took some time for the consensus to establish in web apps and not in mobile apps, it seems to be fairly understandable now that web apps provide better availability, portability, and ease of use than native applications. And as mobile devices become more powerful, and optimizing for the web becomes a sexy engineering problem, the end result is an outburst of well-engineered, optimized, and resourceful applications right here, on the web.

But as we have learned from the history books, there’s no power vacuum. The web was set to reign, but who shall be the king? Enter React – a JavaScript library for building user interfaces.

This library maintained by the fine folks at Facebook took the market share and ended once and for all the JavaScript fatigue: that feeling everyone around in 2015 had. Every day a new frontend framework is competing for the top spot. Then eventually React appeared, people liked it, and the problem was settled.

This (not so) short introductory story is the answer to what React is and why you need it. Because React is a JavaScript library for the ever-growing frontend environment, you need it because it is popular, way maintained, liked, and used throughout the globe, in FAANGs and local shops. You can’t go wrong choosing React.

What makes React hard to learn for beginners?

React doesn’t have a particularly hard abstraction or technical conception. On the contrary, its single source of truth mantra has been a breeze for seasoned web developers.

However, this change in paradigm (for the better) can hit harder if you are used to using vanilla JavaScript or the last king, jQuery. Communication is rarely event-based, as opposed to what JavaScript typically enforces by design or with its backend counterpart, NodeJS.

Componentization is a concept that is easy to grasp but demands time to master. Hooks brought the functional flavor that seems to be the current trend, despite component lifecycles that may be more familiar to Java developers.

In short, what makes React hard for beginners is that it is React, not an adaption, a fork of a known framework, or an abuse of the JavaScript language. It’s a new paradigm, focused on User Interfaces, simplicity, and opinionated state management.

React best practices

Every language and framework has the so-called “best practices”, i.e., a community-accepted set of practices when using the tool. The following isn’t an exhaustive list of them, but an attempt to list the ones that typically concern the average developer.

Security

Every software engineer that had code shipped to production had to go over this drill. Is the code secure? Are there flaws? Are they exploitable? Given the architecture of the web, this matter is even more flagrant.

However, I’d argue that React doesn’t pose any special security threat that any web application doesn’t have. Be aware of XSS attacks; store authentication tokens safely; sanitize HTML, and so forth.

Sanitize HTML

By having its own templating engine that allows dynamic variables to be inserted into HTML, React exposes a security issue that every web developer should be aware of: injecting malicious code in HTML.

As the classical example goes, we don’t want users to pass any kind of script that can be rendered on an HTML page. Because of that, there’s a process called sanitization, where we allow only specific tags to be rendered on a page.

Imagine you have a CMS like ButterCMS and render the content generated by the content creator without any kind of filter. Well, React exposes the property dangerouslySetInnerHTML that serves this very purpose: get a raw HTML for an API, and render it in an element.

But the API isn’t named like that for nothing. Suppose this content contains a valid script that collects user information and posts it back to the attacker database: you’re essentially adding a trojan horse to your website!

In order to prevent such cases, you can use libraries like sanitize-html to allow only specific tags to be rendered. For example, if your goal is to render a blog post, you can allow only the traditional

, , , , etc tags, and block suspicious ones like

One of the core contributors to React, Dan Abramov, wrote in his blog a piece on the differences between function and class components. Go check it out if you are curious about the internals.

Now that we understand that Hooks do not operate based on lifecycles (like classes do), let’s examine how the most common Hooks work.

useState

The first and simplest Hook is useState. Basically, it does exactly what you would expect: you declare a variable and a setter. Here’s how it looks:

import React, { useState } from 'react'; const Counter = () => { const [count, setCount] = useState(0); return ( Current count: {count} ); }

As you can see, the hook returns an array with two elements and takes one parameter.

The first element of the array is the current value for this state;

The second element of the array is a setter that changes the value of this state;

The parameter used in the hook (in our example, 0) is the initial value of this state.

Naturally, you can add multiple states by adding multiple hooks:

const Counter = () => { const [count, setCount] = useState(0); const [step, setStep] = useState(1); return ( Current count: {count} ); }

Now recall that with Hooks every re-render is nothing else than the function being called again (in our example, Counter). But for every re-render, the state will be updated with its current value. This is the main difference between a state variable and a regular variable. Regular variables will always be re-defined. State variables will be derived from the previous state.

How do we trigger a re-render? Every time a prop or state variable changes we trigger a re-render. This is done by invoking the setter, in our example through the click of the button. This is important to know so we can better understand the next Hook.

useRef

Sometimes we want to store a value in our component for future reference, but we don’t want to trigger a re-render (as this value isn’t expected to change often or has little or no UI impact). This would be the equivalent of having a class property:

this.myValue = value;

To address this case, useRef was introduced. Refs give us a way to store a variable in the scope of the function and preserve its value across renders. One typical case is to set a reference into an HTML component:

import React, { useRef } from 'react'; const FocusInput = () => { const inputRef = useRef(null); const onClick = () => inputRef.current.focus(); return ( ); }

Notice that useRef receives an initial value (in our example, null) and returns the ref variable. Whatever is stored in this ref can be accessed via myRef.current, so when we assign the ref of the input element to inputRef, inputRef.current holds the actual DOM element, allowing us to programmatically trigger focus.

In fact, useRef is a special case of useState, but one that we set its value directly instead of using a setter, which persists the value across renders without triggering a re-render.

useRef vs useState

What's the difference between the two Hooks?

useRef is a special case of useState: https://t.co/Y2tCnuBeQZ

- useRef persists values across re-renders
- changing useRef does not trigger a re-render

More about #hooks: https://t.co/7MRBkpAHXL
— Rafael Quintanilha (@webquintanilha) June 12, 2019

If you want to learn refs in depth, The Complete Guide to React Refs has a comprehensive coverage of how refs work.

So far we have learned how to manipulate variables inside a component using Hooks. We are still missing how to respond to some events. For example, how can I fetch data from an API when the component mounts, or how can I perform an operation if a particular state changed?

useEffect

The useEffect hook can be tricky to grasp, particularly if you think too much in terms of old React class lifecycles. It has some subtleties that are not immediate but definitely make sense. Let us start from the beginning: what exactly is an effect?

An effect, or side effect, is an operation that you run after a render.

A practical example: suppose you have a component that fetches a list of products for a given category. Once your component renders (“mounts”) you want to trigger the API call. And if later the category changes (for example if the user navigates from the sports section to the fashion section of an e-commerce site), you want to call the API again.

Notice that with what we learned about useState and useRef we are unable to do so. We currently haven’t learned a way to only perform operations given that certain things happened to our state or props.

In the old-style class component, our example would look like this:

class ProductsList extends React.Component { componentDidMount() { this.getProducts() } componentDidUpdate(prevProps) { if ( prevProps.categoryId !== this.props.categoryId ) { this.getProducts(); } } getProducts() { // perform API call with this.props.categoryId } ... }

Now, what is the Hooks equivalent?

const ProductsList = props => { const getProducts = () => { // perform API call with props.categoryId } useEffect(() => { getProducts(); }); ... }

This looks way cleaner. We define an effect which accepts a function that will be called after render and then will perform some operation (here, call getProducts). However, this isn’t quite right yet. The above code runs the effect after every render. How can we fix that?

Luckily, useEffect accepts a dependency array. It means that you can declare upon which state or props change you want to trigger the effect. For us, it would look like this:

useEffect(() => { getProducts(); }, [props.categoryId]);

The above code will run after the first render and in all renders caused by a change in props.categoryId. It is a combination of componentDidMount and componentDidUpdate.

What if you want to call the effect only on “mount” (or in Hooks jargon, after the first render)?

useEffect(() => { getProducts(); }, []);

The answer is to make the dependency array an empty one. Remember that when we add a dependency array, the effect gets called after the first render and whenever any of the values in the array change. Logically, if there is no element in the array, it will only be called after the first render.

If you want to run your effect after every render, simply remove the dependency array at all (like in our first example). However, make sure you know what you are doing because this can cause performance issues (imagine calling an API whenever a component with plenty of states and props re-renders).

There is one last thing that I want to mention about useEffect. Sometimes you might want to do a cleanup, the equivalent of the componentWillUnmount lifecycle. For example, you might have added a DOM listener that you want to remove upon unmount. Recall our useMouseMove hook? Here is how we can implement it with Hooks using what we have learned so far:

import React, { useState, useEffect } from 'react'; const useMouseMove = () => { const [coords, setCoords] = useState([0, 0]); useEffect(() => { const handler = ({ clientX, clientY }) => { setCoords([clientX, clientY]); }; window.addEventListener('mousemove', handler); return () => { window.removeEventListener('mousemove', handler); }; }, []); return coords; };

The above is outlined in the terrific use-event-listener library. After the first render, you add a listener to the window object and call a cleanup function when the component is removed from the DOM. Whatever function you return from inside your effect will be called upon unmount. The official docs provide more details if you want to dive deeper.

Finally, in the Overreact blog by Dan Abramov, there is a comprehensive guide of useEffect. The post is very long but I encourage you to find some time and read it if you want to master useEffect.

Other Hooks

There are several other built-in Hooks in the new API. All of them are described in the API reference, but I will highlight some:

useContext

Equivalent to the Context API. Allows your component to read from a Context:

const value = useContext(MyContext);

useReducer

For some time, state management libraries such as Redux were a controversial point in the React community. They evolved over the years but the hype has been diminishing. Hooks, however, provide a very neat way to add a reducer to your component.

A reducer is basically a function that accepts a state and an action. Based on the action, it updates the state. This leads the developer to a better encapsulation of the state, while increasing the maintainability of the state as it grows. More about useReducer in the docs.

useCallback

The last built-in Hook that I want to mention is useCallback. Basically, useCallback receives a function and a dependency array and memoizes that function until any of its dependencies change. It is useful for optimizations and borrows the shouldComponentUpdate mindset.

Suppose you render a Button component:

const Component = () => { const onClick = () => console.log(“Clicked”); return ; }

Whenever Component re-renders, onClick will be redefined (recall that we call the function scope every render). Once onClick essentially changed, Button will re-render too. But notice that onClick is in practice the same function, so we re-rendered Button unnecessarily!

const Component = () => { const onClick = useCallback(() => console.log(“Clicked”), []); return ; }

The above code fixes our problem. By wrapping our function in useCallback we now have it memoized and only recreated if any value in the dependency array changes (in our case, because useCallback has no dependencies, it will never change).

useCallback is very related to useMemo, which does basically the same thing, but memoizing the result of a function, not the function itself. There is a nice piece about their differences in this Stack Overflow comment.

Next

We have covered everything we needed (much more, in fact) to write our first hook. So the next section will stop the theory and explain how we can create a custom hook for ourselves.

Writing your first hook

So far we learned how to use Hooks to achieve the same things we would achieve with a class component. But recall that the greater goal of Hooks is to make logic shareable, so this is our next objective.

We saw a sneak peek of this process in the useMouseMove hook provided in the last section. Basically, we wrote a function that used some hooks (useState and useEffect) and returned a value.

For this section, we will write a useButter hook. This hook will make our life easier when injecting ButterCMS data in any component. ButterCMS is a headless Content Management System that you can learn more about here. Let’s get started writing our useButter hook.

Modeling the API

Butter docs cover all you need to know about using Butter in a React application. In short, once you have your Butter client set with the correct API key, listing the first 10 posts of your blog is as easy as:

butter.post.list({page: 1, page_size: 10}).then(function(response) { console.log(response); });

Notice that the butter client exposes us to some entities (in this example, page) and a few methods (in this example, list). Finally, we can also pass some options (in this example, the number of pages and the page size) and after the API resolves, access the response. Check the API reference for a complete list of entities and methods.

Ideally, our hook would receive the entity, method, and options, and return the API response. To give us more control over the network request, we will also need to know if the API is still loading or if it failed.

Creating the Hook

Let us now start creating our hook. All code in this article is present in this GitHub repo. Afterward, we will build a simple app that fetches posts from the ButterCMS API. Here’s a live preview.

Setting up Butter

First, we will set up Butter and create the hook. When it’s done we then “hook” it into our component.

Go ahead and create your app. For the sake of this example, I’ll use create-react-app:

npx create-react-app butter-hooks-example

Then, navigate to the newly created butter-hooks-example directory and add the butter library:

yarn add buttercms

Once it’s done, create a file in the src folder called butter-client.js and add the following:

import Butter from 'buttercms'; const butter = Butter(); export default butter;

Make sure to insert your own API key. That’s all you need to start communicating with the Butter API.

useButter

In the same src directory create a file called useButter.js, where our hook will live. Go ahead and add this basic skeleton:

import butter from './butter-client'; const useButter = () => { } export default useButter;

We now need to add the functionality of our hook. Recall that we decided to return the API response and control variables that determine if the API is loading or if it failed. It makes sense to create them as state variables, so add the following:

import { useState } from 'react'; import butter from './butter-client'; const useButter = () => { const [response, setResponse] = useState(null); const [loading, setLoading] = useState(false); const [error, setError] = useState(""); // do something with them return { response, loading, error }; } export default useButter;

We declared three different state variables, each with different initial values. In the end, we return them in the form of an object.

Now, I want to give the user the ability to control when to call the API. Therefore, we need to expose the API call. Let us create the callAPI function:

... const callAPI = async (entity, method, ...options) => { if ( butter[entity] === undefined || butter[entity][method] === undefined ) { setError(`Unable to call method ${method} from entity ${entity}`); return; } setError(null); setLoading(true); try { const response = await butter[entity][method](...options); setResponse(response); } catch (e) { setError(`${e.status}: ${e.statusText}`); } setLoading(false); } ...

Recall that the butter client needs an entity and a method (e.g. post and list). The above code checks if, for a given entity and method, the function exists (setting an error if not true). After, we change the state to inform that the API is loading and await the response from the API, we make sure we pass the correct options to the butter client. If it fails, we set the error message and if it works, we set the response. Pretty neat.

The complete code for the hook is:

import { useState } from 'react'; import butter from './butter-client'; const useButter = () => { const [response, setResponse] = useState(null); const [loading, setLoading] = useState(false); const [error, setError] = useState(""); const callAPI = async (entity, method, ...options) => { if ( butter[entity] === undefined || butter[entity][method] === undefined ) { setError(`Unable to call method ${method} from entity ${entity}`); return; } setError(null); setLoading(true); try { const response = await butter[entity][method](...options); setResponse(response); } catch (e) { setError(`${e.status}: ${e.statusText}`); } setLoading(false); } return [{ response, loading, error }, callAPI]; } export default useButter;

Notice that we need to make callAPI available in the component, so we pass it alongside with the state object in the form of an array.

This should be enough for us to start hooking things around.

Hooking up

With our hook ready it is time to finally see it in action. Go to App.js and add the following:

import React, { useEffect } from 'react'; import useButter from './useButter'; import './App.css'; function App() { const [{ response, loading, error }, callAPI] = useButter(); useEffect(() => { callAPI('post', 'list', { page: 1, page_size: 10 }); }, []); return ( useButter Example {loading && Loading from API...} {error && There was an error: {error}} {response && !error && !loading && Posts List {response.data.data.map((post, i) => ( {post.title} ))} } ); } export default App;

If you save your project and run yarn start you will see your hook in action. Congratulations!

First hook example
Notice that it loads all posts that I have saved in my account at this moment. Yours will vary.

Remember that I left the usage of the hook to the user. We did this by calling the API after the first render:

const [{ response, loading, error }, callAPI] = useButter(); useEffect(() => { callAPI('post', 'list', { page: 1, page_size: 10 }); }, []);

What if we want to make the page_size configurable? Let’s go ahead and add an input to control this value. First, include the useState hook:

import React, { useEffect, useState } from 'react'; ... function App() { const [pageSize, setPageSize] = useState(10); const [{ response, loading, error }, callAPI] = useButter(); useEffect(() => { callAPI('post', 'list', { page: 1, page_size: pageSize }); }, [pageSize]); ...

Now our effect will re-run every time pageSize changes (once it is in the dependency array). Let’s add the appropriate UI:

... return ( useButter Example {loading && Loading from API...} {error && There was an error: {error}} {response && !error && !loading && Posts List {response.data.data.map((post, i) => ( {post.title} ))} Page Size setPageSize(e.target.value)} type="number" /> } ); ...

Here’s the final result:

And that’s it! We have created a hook that shares logic with any component. Write once, use it everywhere.

Fixing the dependency array

If you have ESLint configured, you will see the following warning:

React Hook useEffect has a missing dependency: 'callAPI'. Either include it or remove the dependency array react-hooks/exhaustive-deps

What exactly does that mean? Recall our useEffect hook:

useEffect(() => { callAPI('post', 'list', { page: 1, page_size: pageSize }); }, [pageSize]);

Notice that callAPI is a dependency of the effect as much as pageSize. Even though we don’t expect it to change, it is a good practice to list all dependencies in the dependency array. Let’s fix it:

useEffect(() => { callAPI('post', 'list', { page: 1, page_size: pageSize }); }, [callAPI, pageSize]);

If you save your project and check it, you will see that there is an infinite loop going on. What’s happening?

Remember that our hook returns callAPI. So every time we call the API, it updates the state and the hook returns a new value. But callAPI is a new definition of the function (even though they are essentially the same) and therefore we trigger the effect again!

return [{ response, loading, error }, callAPI];

So in every state change we redefine callAPI. This is something we don’t want to do. Luckily, this is the exact case where useCallback is valuable: we want a function to persist unless some of its dependencies change. Because callAPI has no dependency, we don’t need it to ever change.

To fix this, go back to useButter.js, make sure you add useCallback along with useState and change the return statement to:

return [{ response, loading, error }, useCallback(callAPI, [])];

And that’s it! Now callAPI won’t be redefined at every render. Save and see that it is working again.

Wrapping up

In this article we learned what Hooks are and that they are meant to solve problems that have been a pebble in the shoes of the React community for a long time — how to easily reuse logic in between components instead of UI.

Hooks are an alternative to Higher-Order Components and Render Props, both with their pros and cons. Moreover, Hooks provide a way to map behaviors of class components to functional components (though they do not map directly).

Even though you can do (almost) everything classes do with Hooks, you don’t need to switch right away. Instead, try playing around with it until you feel comfortable. Although this is always a matter of personal opinion, I’d say Hooks are here to stay, not because of the hype, but ultimately because they are better.

Finally, we saw how to create your own Hook. useButter is an alternative to reuse logic when injecting ButterCMS data in your application. It makes accessing the API trivial and handles network requests. There is still room for improvement, so feel free to tweak my code and contribute in GitHub!

Software Engineering - Rafael Quintanilha

React Best Practices: How to Write Better React Apps

What is React and why use it?

What makes React hard to learn for beginners?

React best practices

Security

Sanitize HTML

useState

useRef

useEffect

Other Hooks

useContext

useReducer

useCallback

Next

Writing your first hook

Modeling the API

Creating the Hook

Setting up Butter

useButter

Hooking up

useButter Example

Posts List

useButter Example

Posts List

Fixing the dependency array

Wrapping up