Can someone explain the order of these operations in the react lifecycle? The picture shows events occurring both vertically and horizontally but I don't understand the order of these events. For example, "First is the mounting phase where first the constructor is called then render is called etc...". In other words, how can one understand this diagram. Is it, for each horizontal phase ie. Mounting, Updating, and Unmounting we evaluate each vertical operation ie, constructor(), render(), ...componentDidMount()?
2 Answers
I believe you have the right idea - for each vertical phase, you evaluate it going down. When a component mounts, it is created (via the constructor call), then it renders, then calls componentDidMount. The trick here is that the same render method is called both during mounting (after construction) and during updating (after new props, setState, or forceUpdate). That's why render is a horizontal bar - it's literally the same function that's called in both vertical flows, so representing it as disjoint processes in each vertical segment could be misleadinng. Does that make sense?
In simple term, though I am more of functional developer/hook developer than class syntasism(this is just my own made grammar) so my answer might not give you the best or all. To go straight to the point, below is the order of react-lifecycle(the whole life sperm of a component or UI).
render => componentWillMount => componentDidMount => componentWillUpdate => componentDidUpdate => componentWillUnmount
render: for class components is the first life-cycle method that ships your UI-structure to the virtual DOM when the Ui is first created(take note: when the Ui is first created it gets executed and when other life-cycles get executed, they also depend on this lifecycle because without it, your Ui in a class component won't show. This makes this lifecyle the only method that exists from first render until unmounted).
componentWillMount: hmmm, this life-cycle is been deprecated 2 years ago but to caught the long story short, you can do some synchronous event here with the mindset that the synchronous operation will be executed while the component is mounting(i call it aka alongSideLifeCycle). Mind you, does synchronous operation don't have to depend on the DOM to be set before carrying out the operation else, there will be some performance issue.
componentDidMount: hmmm, this lifecycle gets executed ones a component has been successfully mounted(but mind you, it works just the way a defer attribute works in HTML script tag,i.e its loads the operation/lifecycle to the component background and that makes the execution super fast and most times can't be noticed if you are not using some tracking devtools ). This lifecycle is the best place to carry out components-side-effects-operation aka effect(effect are things that can utter the current state, view or structure of an application e.g: async operation, DOM nodes update, DOM-API operations like timeouts, eventListeners).
componentWillUpdate: this lifecycle gets executed first anytime a component wants to update/ change anything (either it affects the UI visually or not).
componentDidUpdate: this is the best place to do some necessary clean up to avoid things like memory leak aka direct or indirect unnecessary recursion or re-occurency. e.g best place to do: removeEventLister, clearTimeout/clearInterval, any form of unsubscription.
the last one is componentWillUnMount: basically, a perfect place to the destroy the state to initialState of that component because literally, the component structure aka DOM_NODES has been technically destroyed so why keep the value-less state that its own existence depends on the existence of the destroyed component file but mind you, imperatively, that is automatically done by react-ecosystem and there is no need doing it declaratively!
Bonus point: in react, there is an algorithm called "diffing" and during componentDidUpdate, the react UI dont ship unchanges structures to the actual DOM tree again(never) but it executes the "diffing" algorithm which trys to check the current virtual DOM structure and create a new virtual DOM structure based on things that have changed, and then react do what we call "reconcialiation" which is the process of settling the Virtual-DOM changes with the real Browser DOM to know what to put into the real DOM.
This process of diffing, reconciliation and Virtual DOM made React the boss of UI libraries because it reduces redundant rendering thereby making the ui-mounting process super fast ✈️ ✈️ ✈️
So hope that clarified you
Related