Recently, I read a great post by Dan Abramov from the React team on
useEffect, which is a Hook as part of React's new Hook-based ecosystem. It was a long read (50 minutes!) but after reading it, I can now say that I (somewhat) understand
useEffect. I'm writing this blog post mainly so that I can try and understand it better myself, and hopefully in the process get you to learn it as well.
I'm not going to include much (if any) images or examples of code, since I'll largely be going over the concepts.
What is an effect and where does it run?
An effect in React is something that runs after the browser is done painting the initial page. Unlike
componentDidUpdate, there isn't a distinction between the two in React.
useEffect literally just runs after the render.
What's the difference between Hooks and classes?
A common misconception about
useEffect is that it can be used similarly to the class methods
componentDidUpdate. This assumption is false because unlike hook-based components, classes use
this.state, which is mutable.
This means that if I add a
setTimeout to display an alert with a value from
this.state which changes when I click something, the class-based component will show me the latest value. Unlike classes, hooks "capture" their current state and props for each render. That means that if I click something and change a state value which triggers a
setTimeout, the captured state will be used, not the current.
You can get the current state by using
useRef as shown in Abramov's post, but try not to since that's essentially swimming against the tide.
What is the array at the end used for?
If you've ever used
useEffect, you know that there's this array that can be provided as a second parameter. You don't have to provide it, but let's talk about what it is.
So if you don't provide the array, you're basically creating an effect that runs after every render. For the sake of example, let's use a simple example: a search component which has a state
query which is changed when you type in an input.
Your goal is to create an effect that checks whenever
query is changed, it will send a request out to a search API, get the data, and store it back in the state to render. This is a perfect use case for dependencies in
If you add
query as a dependency (like
[query] if it's the only dependency), then your effect will essentially run ONLY if the
query from the current render is different from the
query from the last render. By doing this, you ensure there aren't any unnecessary requests sent. Last thing anyone would need is additional requests to an API just for doing some unrelated action that triggers a render.
Well. I hope I'm right in my words. This post may/may not be edited with images later, in which case I'll remove this line later. This is a pretty short introduction but if you're interested, I highly recommend Abramov's post, linked above. Thanks for reading and have a great day!