when does the `render()` method in react get called - reactjs

As far as I know these are the scenarios when react calls the render() method provided shouldComponentUpdate() is not implemented.
when your component get mounted initially
when state got changed using this.setState()
when your component receives new props
when this.forceUpdate() get called.
Is there any other scenarios that I am missing?

Yes there's one more case I can think of. When parent component is re-render.
Every time a component is re-render all its children get re-render too. Unless you implement shouldComponentUpdate method in the children.
Hope it helps.

when context gets changed render gets called

Related

component Updated without even a call to shouldComponentUpdate()

I have an issue with my react app: In a parent component I have shouldComponentUpdate() returning false. As expected the shouldComponentUpdate() of child components is not called. However the componentDidUpdate() of the child components is called (but not the one of the parent component). It causes performance issus, and I would like child component not to be updated.
I've checked that:
Each child component is still the same : the key does not change and the constructor is not called again.
I do not make use of forceUpdate() anywhere
Does anyone have an idea of what could go wrong ?
In case the answer can help others : it is a consequence of the use of contexts : whenever the value changes, everything component using the context gets updated no matter what.

Will componentDidUpdate fire everytime for a component that renders null?

Will componentDidUpdate always fire for a component that renders empty fragment/null ? It receives redux connected props from the parent container.
This component needs to access previous props and compare, then make an API call based on it. It doesn't have UI, so it renders empty fragment (or null)
EDIT : It is working and firing componentDidUpdate in my sample application. Is this guaranteed to be the behavior always?
It says here that there is a chance it may not fire when there was no change in the virtual DOM: Props updated, componentDidUpdate did not fire
MyContainer
|
-MyComponent
Yes it run every time instead at time of first initial render
Yes componentDidUpdate is called every time, even when rendering null. You can check this in the react documentation: React Lifecycle

Will componentWillMount run again if component is re-rendered because of parent component?

Will componentWillMount run again if component is re-rendered because of parent component?
No, componentWillMount is called only once.
Also, componentDidMount is called only once.
componentDidUpdate is called on every re-render.
To correctly understand about the react lifecycle methods you can go through this link.
https://engineering.musefind.com/react-lifecycle-methods-how-and-when-to-use-them-2111a1b692b1
The short answer is NO
It's called once right before your component is about to be rendered to the DOM.
The long answer is:
componentWillMount
Your component is going to appear on the screen very shortly. That chunky render function, with all its beautifully off-putting JSX, is about to be called.
Most Common Use Case: App configuration in your root component.
Can call setState: Yes, but don't. Use the default state instead.
componentDidMount
Here is where you load in your data. ComponentDidMount is also where you can do all the fun things you couldn’t do when there was no component to play with. Basically, here you want to do all the setup you couldn’t do without a DOM, and start getting all the data you need. Most Common Use Case: Starting AJAX calls to load in data for your component.
componentWillReceiveProps
Perhaps some data that was loaded in by a parent component’s componentDidMount finally arrived and is being passed down. Before our component does anything with the new props, componentWillReceiveProps is called, with the next props as the argument.
shouldComponentUpdate
shouldComponentUpdate should always return a boolean — an answer to the question, “should I re-render?” Yes, little component, you should. The default is that it always returns true. It's an awesome place to improve performance.
componentWillUpdate
Most Common Use Case: Used instead of componentWillReceiveProps on a component that also has shouldComponentUpdate (but no access to previous props). It’s basically the same as componentWillReceiveProps, except you are not allowed to call this.setState.
componentDidUpdate
Here we can do the same stuff we did in componentDidMount — reset our masonry layout, redraw our canvas, etc. Basically, we use it when it's all said and done, but we don’t want to waste time to redraw the canvas every time it updates. Most Common Use Case: Updating the DOM in response to prop or state changes.
componentWillUnmount
Here you can cancel any outgoing network requests, or remove all event listeners associated with the component. Basically, clean up anything to do that solely involves the component in question — when it’s gone, it should be completely gone.

Does my component need force update to scrollIntoView?

I'm making my first react + redux app and I have a question. I have a component that render a input field and, as some content is added above it, I need it to scrollIntoVIew.
So, I just added the scrollIntoView in the component componentDidUpdate() lifecycle method :
componentDidUpdate() {
console.log("scroll");
this.refs.input.scrollIntoView();
}
The only problem is that this component does not re render each time (as nothing change in it) so the scrollIntoVIew is called only one time.
I could force update to component but this is not really good practice isn't it ? What can I do in this case ?
You could call setState and update some object in the component's state every time content is added to re-render the component, and componentDidUpdate will be invoked.
You could also use the second argument (callback) to setState, but the React docs say the following about second argument of setState:
The second parameter is an optional callback function that will be
executed once setState is completed and the component is re-rendered.
Generally we recommend using componentDidUpdate() for such logic
instead.

Why componentDidUpdate trigger when prevState/prevProps are same as this.state/this.props

I have a component, and its componentDidUpdate seems to trigger for no reason. It's a child component, has no state. Even though the prevProps and this.props are the exact same its triggering, is there any reason for this? I thought update should only trigger when there is a change in the props/state?
componentDidUpdate() is fired every time the parent component re-renders (and passes in new props). And in stateful components also whenever setState() is fired.
Even if old prevprops and this.props are exactly the same, componentDidUpdate() is still fired if the parent component re-renders.
If you want to prevent react to enter a render cycle, you should implement the shouldComponentUpdate() method, where you can compare new and old props.
update should only trigger when there is a change in the props/state
No, React renders to VirtualDOM everything each time. But then it updates only changed properties in real DOM.
To avoid that you can use PureRenderMixin or your custom comparation code in shouldComponentUpdate.

Resources