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
- 📄 13 tips for better Pull Requests and Code Review (October 17, 2023)Would you like to become better at crafting pull requests and reviewing code? Here are the 13 tips from my latest book that you can use in your daily developer activity.
- 📄 The simplest example to understand Server Actions in Next.js (August 3, 2023)Server Actions are a new feature in Next.js. The first time I heard about them, they didn’t seem very intuitive to me. Now that I’m a bit more used to them, let me contribute to making them easier to understand.
- 📄 Intro to React Server Components and Actions with Next.js (July 3, 2023)React is living something these days. Although it was created as a client UI library, it can now be used to generate almost everything from the server. And we get a lot from this change, especially when coupled with Next.js. Let’s use Server Components and Actions to build something fun: a guestbook.