> For the complete documentation index, see [llms.txt](https://maissen.gitbook.io/react-grimoire/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://maissen.gitbook.io/react-grimoire/concepts/react-under-the-hood/react-lifecycle.md). # React Lifecycle In React applications, code is separated into components to isolate different aspects of the user experience as well as the logic required to paint the user interface. These components define how the user should interact with the content and how they should see it. `Mounting`, `updating`, and `unmounting` are the three main steps that each component goes through. You might conceive of it as component natural life cycle: they get born (mount), get to live (update), and get to die (unmount). React components are generated by mounting them on the DOM, then changing them through updates, and lastly removing or unmounting them from the DOM. These three milestones are referred to as the React **component lifecycle**. {% hint style="info" %} React Component may or may not go through all of the phases. Sometimes they aren't updated at all. They are never unmounted in other cases. Without ever updating, a component can go through the **mounting** and **`unmounting`** phases back to back.) {% endhint %} {% embed url="" %} Credits : Wojciech Maj {% endembed %} The diagram above depicts the current React component lifecycle, along with the associated lifecycle functions. Specific lifecycle methods are provided by React and can be used to conduct specific tasks in different phases. We'll try to demonstrate the most common and important life cycles by using a component-based and hooks component as an example. {% hint style="info" %} **Bear in mind that Hooks have another rendering flow , but in this section we will try to explain how they mimic the old lifecycles** {% endhint %} if you want to see the new hook flow please see this link: {% embed url="" %} {% endembed %} {% embed url="" %} {% endembed %} ## componentDidMount( ) We aren't actually defining DOM nodes with React even though we're defining virtual representations of nodes in our DOM tree. Instead, we'll establish an in-memory view that React will manage and maintain. When we talk about mounting, we're referring to the process of transforming virtual components into DOM elements that React can place in the DOM. {% hint style="info" %} This method is usually called when the component has finished rendering for the first time. It is only called once throughout the lifecycle once after the component has finished mounting. {% endhint %} This is useful for things such as fetching data to populate the component. ### Class based: ```tsx import React from "react"; class Component extends React.Component { componentDidMount() { console.log("Behavior before the component is added to the DOM"); } render() { return

Hello World

; } }; ``` ### Hooks: ```tsx import React, { useEffect } from 'react'; const Component = () => { useEffect(() => { console.log('Behavior before the component is added to the DOM'); }, []); // Pass an empty array to run only callback on mount only. return

Hello World

; }; ``` In the above example, When the component is `mounted`, the `useEffect` Hook is called. The empty array \[] in the second argument tells the `useEffect` Hook that it only has to run once, when the component is mounted. ## componentDidUpdate( ) Before or after changing the actual rendering, we may wish to update some data in our component. Let's imagine we want to call a function to set up the rendering or to call a function when the props of a component change. The `componentWillUpdate`() method is an effective hook for preparing our component for a change {% hint style="info" %} Throughout the app's lifecycle, this method is called several times. It is called as soon as the data has been updated. This method is not called for the initial render. {% endhint %} ### Class-based : ```tsx import React from 'react'; class Component extends React.Component { componentDidUpdate() { console.log('Behavior when the component receives new state or props.'); } render() { return

Hello World

; } } ``` ### Hooks: As you can see if the below example the second argument in the hooks is blank meaning it will render every single time. ```tsx import React, { useEffect } from 'react'; const Component = () => { useEffect(() => { console.log('Behavior when the component receives new state or props.'); });// No second argument, so run after every render. return

Hello World

; }; ``` But hold on a second. This seems to be much like how `componentDidMount` was implemented. So, what exactly is the difference? The most important thing to note is the absence of the optional second argument (`[]`). Every time the component is re-rendered, the Hook will be evaluated. The optional second argument is an array of dependencies that will cause the `useEffect` Hook to be re-evaluated. It will only evaluate the Hook on mount if no values are provided in the array. If the array isn't provided, it will be evaluated every re-render. . To elaborate on this a bit more — if we wanted to add a condition to `componentDidUpdate` we might do something like this in a class-based component: This allows us to conditionally execute behavior based on the `foo` prop value changing. With Hooks, this becomes trivial: ```tsx class Component extends React.Component { componentDidUpdate(prevProps) { if (this.props.foo !== prevProps.foo) { console.log("Behavior when the value of 'foo' changes."); } } render() { return

Hello World

; } } ``` ```tsx import React, { useEffect } from 'react'; const Component = ({ foo }) => { useEffect(() => { console.log("Behavior when the value of 'foo' changes."); }, [foo]); return

Hello World

; }; ``` The `useEffect` Hook will now only be evaluated if the value of `foo` changes since it is included in the option dependency array. ## ComponentWillUnmount( ) This method will be called when the component is `unmounted`, as the name implies, and it will only be called once during the component's lifecycle. This is where we take care of any cleanup tasks, such as clearing timeouts, cleaning data, disconnecting websockets, and so on. {% hint style="info" %} Before the component is unmounted, React will call out to the `componentWillUnmount()` callback. {% endhint %} ### Class based component: ```tsx import React from 'react'; class Component extends React.Component { componentWillUnmount() { console.log('Behavior right before the component is removed from the DOM.'); } render() { return

Hello World

; } } ``` ### Hooks: ```tsx import React, { useEffect } from 'react'; const Component = () => { useEffect(() => { return () => { console.log('Behavior right before the component is removed from the DOM.'); };// It will be called before unmounting. }, []); return

Hello World

; };tsx ``` Just hang on a minute longer! This seems to be even more similar to how `componentDidMount` was handled! In reality, they're fairly similar. The return statement inside the `useEffect` function body is the only difference. If `useEffect` returns a function, that function is only called after the component is removed from the DOM. ### Final Thoughts There are other life cycle for a react component, even new one are emerging as the `getDerivedStateFromProps` as of [React 17](https://medium.com/@valerii.sukhov/react-17-lifecycle-5b68946c813c) designed to replace `componentWillReceiveProps`. and it's invoked right before calling the render method, both on the initial mount and on subsequent updates. It should return an object to update the state, or null to update nothing. {% embed url="" %} #### **No Lifecycle method replacement** Below are some of the methods that do not have any lifecycle method replacement for hooks according to the react documentation: 1. **componentDidCatch ( )** 2. **getSnapshotBeforeUpdate( )** 3. **getDerivedStateFromError ( )** {% embed url="" %} #### Why Hooks? / Why not Classes? The class components are long and winding. To create a 'effect logic,' we are frequently obliged to duplicate our logic in different lifecycle functions. Class components do not provide an easy method for sharing logic between components (HOC and friends do not provide an elegant solution) — React Hooks, on the other hand, allow us to create our custom hooks. a much simpler solution. Other then that the use of `this` add a lot of complexity and reduce readability of the code i have stumble upon one of **Kent C Dodds** articles that clarify more the complexity of the class components use. {% embed url="" %} {% hint style="success" %} **I truly recommend to have an eye on Kent C Dodds blog , it's a rich maybe the richest resources for React and JavaScript topics.** {% endhint %} {% embed url="" %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://maissen.gitbook.io/react-grimoire/concepts/react-under-the-hood/react-lifecycle.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.