‫So, I have mentioned
‫the use effect dependency array a few times already,
‫but we don't know yet what it actually does
‫and how it works.
‫So, let's change that in this lecture.
‫So, as we saw at the beginning of this section,
‫by default in effect will run after each and every render.
‫However, that's almost never what we want.
‫But, the good news is
‫that we can change this default behavior
‫by passing a dependency array into the useEffect hook
‫as a second argument,
‫but why does use effect actually need
‫an array of dependencies, you might ask?
‫Well, the reason is that without this array,
‫React doesn't know when to actually run the effect.
‫But, if we do specify the effect dependencies
‫by passing in the dependency array,
‫the effect will be executed each time
‫that one of the dependencies changes.
‫And, we will come back to why this is so amazing
‫in the next slide.
‫But, for now, this is all you need to know.
‫Now, what exactly are those dependencies?
‫Well, effect dependencies are state variables
‫and props that are used inside the effect.
‫And, the rule is that each
‫and every one of those state variables and props
‫must be included in the dependency array.
‫But, let's take a look at an example
‫to understand what I'm talking about.
‫And, the code here is really not important.
‫What matters is that the effect uses the title prop
‫and the user rating state.
‫We can clearly see at the top of the code
‫that title is indeed a prop
‫and that user rating is indeed a APs of state.
‫Therefore, both of them must be included
‫in the dependency array.
‫So, the effect function depends on these variables
‫to do its work,
‫and therefore we need to tell React about them.
‫Otherwise, if the title or the user rating changes,
‫React will not know about this change,
‫and, therefore, it won't be able to re-execute
‫the effect code.
‫And, this will then lead to a bug called stale closure.
‫And, we will talk about what a stale closure is
‫and also about some more rules for the dependency array
‫in a later more advanced section.
‫But, for now, let's actually understand
‫why the dependency array is so important
‫for the useEffect hook.
‫So, I like to think of the useEffect hook
‫as an event listener that is listening
‫for one or more dependencies to change.
‫And, when one of the dependencies does change,
‫use effect will simply execute the effect again.
‫So, a bit like a regular event listener,
‫but for effects.
‫But, let's go back to our previous example
‫where we had the title and user rating dependencies
‫in the array.
‫So, whenever the title or the user rating changes,
‫React will execute the effect again.
‫So, it will run the code one more time,
‫which will in turn update the document title.
‫So, the website title that we see in a browser tab.
‫So, essentially, effects react to updates
‫to state and props that are used inside the effect,
‫because, again, those are the effects' dependencies.
‫So, in a way, effects are reactive,
‫just like React reacts to state updates
‫by re-rendering the UI.
‫And, this is extremely useful and powerful,
‫as we will see throughout the rest of the course.
‫But, all this only works if we correctly specify
‫the dependency array.
‫Okay, but now let's remember how I said
‫in the very first lecture about effects,
‫that effects are used to keep a component synchronized
‫with some external system.
‫So, some system that lives outside of our React based code.
‫And, if we think about it,
‫that's exactly what is happening here.
‫So, the state and props of our component
‫are now in fact synchronized with an external system,
‫which is, in this case, the title of the document.
‫Now, updating the title in some other way
‫will, of course, not magically update the title
‫or user rating.
‫So, the synchronization only works in one way,
‫but that's not really the point.
‫The same actually happens with state updates
‫and we still say that the UI is in sync with state.
‫So, the point is that use effect
‫truly is a synchronization mechanism,
‫so a mechanism to synchronize effects
‫with the state of the application.
‫And, you will discover this
‫each time that you're going to use an effect.
‫And, so let's go explore this a little bit further.
‫So, as we just learned, whenever a dependency changes,
‫the effect is executed again.
‫But, now, let's remember that dependencies
‫are always state or props.
‫And, what happens to a component each time that its state
‫or props are updated?
‫Well, that's right.
‫The component will re-render.
‫This means that effects
‫and the life cycle of a component instance
‫are deeply interconnected.
‫That's why when the useEffect hook was first introduced,
‫many people thought that it was a life cycle hook
‫rather than a hook for synchronizing the component
‫with a side effect.
‫Now, the conclusion and the big takeaway from this
‫is that we can use the dependency array
‫in order to run effects
‫whenever the component renders or re-renders.
‫So, in a way, the useEffect hook
‫is actually about synchronization
‫and about the component life cycle.
‫Okay, and so with this knowledge,
‫let's look at the three different types of dependency arrays
‫that we can specify
‫and also how they affect both synchronization
‫and life cycle.
‫So, when we have multiple dependencies
‫like in this first example, variables X, Y, and Z,
‫it means that the effect synchronizes with X, Y, and Z.
‫Now, in terms of the life cycle,
‫it means that the effect will run on the initial render
‫and also on each re-render triggered by updating
‫one of the dependencies X, Y, or Z.
‫So, again, just to make this crystal clear,
‫the effect will be executed each time
‫the component instance is being re-rendered
‫by an update to X, Y, or Z.
‫But, if some other piece of state or prop is updated,
‫then this particular effect will not be executed.
‫Now, if we have an empty dependency array,
‫that means that the effect synchronizes
‫with no state or props,
‫and therefore it will only run on mount.
‫In other words, if an effect has no dependencies,
‫it doesn't use any values that are relevant
‫for rendering the component.
‫And, so, therefore, it's safe to be executed only once.
‫Finally, if we have no array at all,
‫we already know that the effect will run on every render,
‫which is usually a really bad idea and not what we want.
‫Now, if the effect runs on every render,
‫that basically means that the effect
‫synchronizes with everything.
‫So, essentially every state and every prop in the component
‫will be dependencies in this case.
‫And, now, to finish,
‫let's look at when exactly effects are executed
‫during the render and commit process.
‫Now, I mentioned in the first lecture on effects
‫that effects are executed after render.
‫And, while that's not wrong, it's also not the full story.
‫So, let's look at a timeline of events that happen
‫as components render and re-render.
‫And, I found this extremely useful
‫when I first learned about the useEffect hook myself.
‫And, so I think that you will benefit from this as well.
‫So, as we already know,
‫the whole process starts with mounting
‫the component instance,
‫in this case an instance of movie details.
‫After that, the result of rendering
‫is committed to the dom,
‫and finally the dom changes are painted onto the screen
‫by the browser.
‫So, this is just what we learned in the previous section,
‫but where do effects come into play here?
‫Well, effects are actually only executed
‫after the browser has painted the component instance
‫on the screen.
‫So, not immediately after render,
‫as you might have thought initially.
‫That's why we say that effects run asynchronously
‫after the render has already been painted to the screen.
‫And, the reasons why effect work this way
‫is that effects may contain long-running processes,
‫such as fetching data.
‫So, in a situation like that,
‫if React would execute the effect
‫before the browser paints a new screen,
‫it would block this entire process,
‫and users would see an old version of the component
‫for way too long.
‫And, of course, that would be very undesirable.
‫Now, one important consequence of the fact
‫that effects do not run during render
‫is that if an effect sets state,
‫then a second additional render
‫will be required to display the UI correctly.
‫And, so this is one of the reasons
‫why you shouldn't overuse effects.
‫Okay, but moving on now,
‫let's say that the title was initially set to Interstellar,
‫but then it changes to Interstellar Wars.
‫And, since this title is a prop,
‫it means that the component will re-render,
‫and the dom changes will be committed
‫and painted to the screen again.
‫Now, since title is part
‫of the dependency array of this effect,
‫the effect will be executed again at this point.
‫So, just as we learned in the last slide.
‫And, this whole process can of course be repeated
‫over and over again
‫until this movie details instance
‫finally unmounts and disappears from the screen.
‫Now, you might notice that there is actually a hole
‫between the commit and browser paint, right?
‫And, the reason is that, in React,
‫there's actually another type of effect
‫called a layout effect.
‫So, the only difference between a regular effect
‫and a layout effect is that the layout effect runs
‫before the browser actually paints the new screen.
‫But, we almost never need this.
‫And, so the React team actually discourages
‫the use of this use layout effect hook.
‫I simply mentioned this here
‫so that you know that this also exists.
‫And, actually, there are even two more holds
‫in this timeline.
‫But, we will talk about these mystery steps
‫by the end of the section.
‫So, stay tuned for that.