Understand how React hooks work
Posted on January 3, 2021
The reason hooks cause developers to struggle is that they look simple, just basic functions, but they are a lot more complex than that. The complex logic is very well hidden in the React core, but understanding a little how they work will help you to use them at their full potential, and overcome the issues you face more easily.
How React renders a component without hooks
Letβs consider this component example, which doesnβt involve hooks:
const WithoutHooks = ({ name }) => {
return <p>Hello {name}!</p>
}
Since this component is a function, React renders the component (or more
precisely knows what to render) by invoking this function with the props. When
the props (i.e. name
) are changed, the function is called again to get the new
rendering result.
If we suppose the name was initially βJohnβ and was changed to βJaneβ, we can describe the renderings like this:
// Rendering 1
return <p>Hello John!</p>
// Prop `name` changed
// β
// Rendering 2
return <p>Hello Jane!</p>
Now letβs see what happens when we introduce a local state with the useState
hook.
How React renders a component with a local state
In this variant, the name
is no longer a prop, but a local state, updated with
an input
:
const WithLocalState = () => {
const [name, setName] = useState('John')
return (
<>
<input value={name} onChange={(event) => setName(event.target.value)} />
<p>Hello {name}!</p>
</>
)
}
When React encounters the call to useState
, it initializes a local state
somewhere in the memory, knowing that it is linked to the first hook call in
this component. In the subsequent renderings, it will assume that the first call
to useState
always refers to this first memory index.
Note that there is no magic in this; React does not parse the function code to identify the hooks call: everything is handled in the hooks code itself (and in Reactβs core).
// Rendering 1
const [name, setName] = useState('John')
// β HOOKS[0] := [state: 'John']
return <> ...Hello John... </>
// setName('Jane')
// β HOOKS[0] := [state: 'Jane']
// β
// Rendering 2
const [name, setName] = useState('John')
// β HOOKS[0] already exists, returns 'Jane'
return <> ...Hello Jane... </>
Note that the behavior would be the same with several states, just with several
state elements in our imaginary array HOOKS
.
Now letβs see what happens when we introduce a call to useEffect
.
How React renders a component with effects
Now, instead of rendering a greeting message with the entered name, we want to call a web service each time the name is updated, which will return us an ID associated with the user name, stored in some database.
const WithLocalStateAndEffect = () => {
const [name, setName] = useState('John')
const [id, setId] = useState(0)
useEffect(() => {
getUserId(name).then((id) => setId(id))
}, [name])
return (
<>
<input value={name} onChange={(event) => setName(event.target.value)} />
<p>ID: {id}</p>
</>
)
}
Same as useState
, useEffect
will reserve some space in the memory (our
HOOKS
array), but not to store a state. What useEffect
needs to store is the
dependencies array, so that it knows next time if the function must be executed
again or not.
// Rendering 1
const [name, setName] = useState('John')
// β HOOKS[0] := [state: 'John']
const [id, setId] = useState(0)
// β HOOKS[1] := [state: 0]
useEffect(..., [name])
// β Executes the function
// β HOOKS[2] := [effect: ['John']]
return <> ...ID: 0... </>
On the first rendering, two spaces in the memory are initialized for the two
local states, and a third for the useEffect
, containing the dependencies,
['John']
.
The second rendering is triggered when the promise inside useEffect
is
resolved, invoking setId
, updating the state of the component.
// setId(123) (when the promise in useEffect is resolved)
// β HOOKS[1] := [state: 123]
// β
// Rendering 2
const [name, setName] = useState('John')
// β HOOKS[0] already exists, returns 'John'
const [id, setId] = useState(0)
// β HOOKS[1] already exists, returns 123
useEffect(..., [name])
// β Dependencies ['John'] is already equal to HOOKS[2], do nothing
return <> ...ID: 123... </>
Although the state is modified, the dependencies array of useEffect
is still
evaluated to ['John']
(because name
wasnβt modified), so the function is not
executed again. Now, if we update the name in the input:
// setName('Jane') (when the input value is modified)
// β HOOKS[0] := [state: 'Jane']
// β
// Rendering 3
const [name, setName] = useState('John')
// β HOOKS[0] already exists, returns 'Jane'
const [id, setId] = useState(0)
// β HOOKS[1] already exists, returns 123
useEffect(..., [name])
// β Dependencies ['Jane'] is different from ['John']
// β Executes the function
// β HOOKS[2] := [effect: ['Jane']]
return <> ...ID: 123... </>
This time, name
changed, so the function is useEffect
is executed again,
creating a new promise, which when resolved will trigger a new call to setId
,
therefore a new rendering:
// setId(456) (when the promise in useEffect is resolved)
// β HOOKS[1] := [state: 456]
// β
// Rendering 4
const [name, setName] = useState('John')
// β HOOKS[0] already exists, returns 'Jane'
const [id, setId] = useState(0)
// β HOOKS[1] already exists, returns 456
useEffect(..., [name])
// β Dependencies ['Jane'] is already equal to HOOKS[2], do nothing
return <> ...ID: 456... </>
The model described here is simpler than the real one, but is good enough to
understand how hooks work under the hood. Plus, since all the hooks could be
written using useState
and useEffect
, it allows you to imagine what happens
with all the other hooks.
Rules this model implies when using hooks
You noticed that when rendering a component several times, each call to a hook was referred by an index. The first hook, then the second, etc. It might seem weird, but React has its reasons for this behavior. And what is more important is the consequence it has.
Since each hook call is referred to by its index, it means that this index must
remain consistent from a rendering to the next one. So if at the first
rendering, the first hook is a useState
storing the name, it cannot be another
state storing the user ID at the second one, nor can it be a useEffect
.
What it implies is that you cannot use hooks in conditions, loops, or any function body.
if (id === 0) {
// Using a hook inside a condition is forbidden!
useEffect(() => alert('Wrong ID'), [id])
}
const getUserName = (id) => {
// Using a hook inside a function is forbidden!
useEffect(() => {
fetch(...)
}, [id])
}
It is also not possible to return something prematurly before a hook call:
const Division = ({ numerator, denominator }) => {
if (denominator === 0) return <p>Invalid denominator</p>
// Using a hook after a `return` is forbidden.
const [result, setResult] = useState(undefined)
useEffect(() => {
setResult(numerator / denominator)
}, [numerator, denominator])
return <p>Result = {result}</p>
}
The rules on hooks can be simplified this way: all calls to hooks must be done
at the root of the component function body, and before any return
.
You may think of it as a contraint, but in most cases it is not that hard to
find another way. For instance, instead of having a useEffect
inside a if
,
you can put the if
inside the useEffect
:
useEffect(() => {
if (id === 0) {
alert('Wrong ID')
}
}, [id])
To avoid calling hooks after a return
, you may have to use some tricks.
const Division = ({ numerator, denominator }) => {
const [result, setResult] = useState(undefined)
const [invalid, setInvalid] = useState(false)
useEffect(() => {
if (denominator === 0) {
setInvalid(true)
setResult(undefined)
} else {
setInvalid(false)
setResult(numerator / denominator)
}
}, [numerator, denominator])
if (invalid) {
return <p>Invalid denominator</p>
} else {
return <p>Result = {result}</p>
}
}
I hope this article helped you to understand how hooks work. If you liked it, know that you can learn a lot more about hooks in my course useEffect.dev.
Check my latest articles
- π A better learning path for React with server components (May 26, 2023)What if we took advantage of React Server Components not only to improve how we use React, but also how we help people learn it from the beginning?
- π Display a view counter on your blog with React Server Components (April 24, 2023)A short tutorial with a cool use case for React Server Components, Streaming and Suspense with Next.js: adding a view counter on a blog, calling the Plausible analytics API.
- π Using Zod & TypeScript for more than user input validation (March 8, 2023)If you have ever created an API or a form accepting user input, you know what data validation is, and how tedious it can be. Fortunately, libraries can help us, such as Yup or Zod. But recently, I realized that these libraries allow patterns that go much farther than input validation. In this post, Iβll show you why I now use them in most of my TypeScript projects.