Pure component performance impact

Author: rohan-paul

React/pureComponent-Performance-benefit.md

@@ -0,0 +1,61 @@
+**Generally people think, an easy way to optimize a React component for performance is to make it a class, and make it extend React.PureComponent instead of React.Component. This way, the component will only re-render if it’s state is changed or if it’s props have changed. It will no longer mindlessly re-render every single time its parent re-renders; it will ONLY re-render if one of its props has changed since the last render.**
+
+However its not as straightforward. Read this - [https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578](https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578) - Key takeaway from this article is - we dont have to user Pure component in all places, as it would NOT have any performance optimization effect generally. So, keep PureComponent on the shelf until you have a measurement to justify it.
+
+You can see real performance improvements by understanding two things: shouldComponentUpdate and JavaScript strict equality comparisons.
+
+1. So, if you inline an object in your JSX, it will fail the PureComponent prop diff and move on to diffing the more expensive React elements. The element diff will come up empty and now we’ve wasted time on both diffs. Since functions are objects and PureComponent does a strict equality check on props, an inline function will always fail the prop diff and move on to the element diff in the reconciler.
+2. If a component usually changes when there’s an update, then a PureComponent will be doing two diffs instead of just one (props and state in shouldComponentUpdate, and then the normal element diff).
+
+Why - Think about it. If you have a Component how many diffs are there? If you have a PureComponent how many diffs are there? The answers are “just one” and “at least one and sometimes two”, respectively. If a component usually changes when there’s an update, then a PureComponent will be doing two diffs instead of just one (props and state in shouldComponentUpdate, and then the normal element diff). Which means it’s going to be slower usually but faster occasionally. Apparently, most of my components changed most of the time, so on the whole, my app got slower. Oops.
+
+Oops - (Meaning after refactoring bunch of my regular component with Pure Component, the App actually got slower). So keep PureComponent on the shelf until you have a measurement to justify it.
+
+#### Now some scenarios
+
+#### 1-st Scenario
+
+#### DOM component event handler
+
+````js
+
+<button
+  onClick={() => this.setState(…)}
+>click
+</button>
+
+```js
+
+It’s common to do nothing more than setState inside of event handlers for buttons, inputs, and other DOM components. This often makes an inline function the cleanest approach. Instead of bouncing around the file to find the event handlers, they’re colocated. The React community generally welcomes colocation.
+
+The button component (and every other DOM component) can’t even be a PureComponent, so there are no shouldComponentUpdate referential identity concerns here.
+
+So, the only reason to think this is slow is if you think simply defining a function is a big enough expense to worry about. We’ve discussed that there is no evidence anywhere that it is. It’s simply armchair performance postulation. These are fine until proven otherwise.
+
+
+#### 2-nd Scenario - A “custom event” or “action”
+
+```js
+<Sidebar
+	onToggle={isOpen => {
+		this.setState({ sidebarIsOpen: isOpen });
+	}}
+/>
+````
+
+If Sidebar is a PureComponent we will be breaking the prop diff. Again, since the handler is simple, the colocation can be preferable.
+With an event like onToggle, why is Sidebar even diffing it? There are only two reasons to include a prop in the shouldComponentUpdate diff:
+You use the prop to render.
+
+You use the prop to perform a side-effect in componentWillReceiveProps, componentDidUpdate, or componentWillUpdate.
+Most on<whatever> props do not meet either of these requirements. Therefore, most PureComponent usages are over-diffing, forcing developers to maintain referential identity of the handler needlessly.
+
+#### We should only diff the props that matter. That way people can colocate (inline function execution inside render / return) handlers and still get the performance gains you’re seeking (and since we’re concerned about performance, we’re diffing less!).
+
+#### Conclusion
+
+Pure Components gives a considerable increase in performance because it reduces the number of render operation in the application which is a huge win for complex UI and therefore advised to use if possible. Also, there will be cases where you want to use the lifecycle methods of Component and in such cases, we cannot use stateless components.
+
+#### Reading
+
+1. [https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578](https://cdb.reacttraining.com/react-inline-functions-and-performance-bdff784f5578)

React/pureComponent.md

@@ -19,8 +19,6 @@ But a pure component, on the other hand, will not rerender if its parent rerende
 
 Using PureComponent will help you prevent this wasted re-render. For instance, if a prop is a string or boolean and it changes, a PureComponent is going to recognize that, but if a property within an object is changing, a PureComponent is not going to trigger a re-render.
 
-**An easy way to optimize a React component for performance is to make it a class, and make it extend React.PureComponent instead of React.Component. This way, the component will only re-render if it’s state is changed or if it’s props have changed. It will no longer mindlessly re-render every single time its parent re-renders; it will ONLY re-render if one of its props has changed since the last render.**
-
 Here’s where immutability comes in: if you’re passing props into a PureComponent, you have to make sure that those props are updated in an immutable way. That means, if they’re objects or arrays, you’ve gotta replace the entire value with a new (modified) object or array. Kill it off and replace it with a clone.
 
 **If you modify the internals of an object or array – by changing a property, or pushing a new item, or even modifying an item inside an array – then the object or array is referentially equal to its old self, and a PureComponent will not notice that it has changed, and will not re-render. Weird rendering bugs will ensue.**
@@ -75,10 +73,6 @@ Also in cases where you want to use lifecycle methods of Component then we have
 
 Suppose you want to create a label with some beautiful UI which will be used to rate the credibility of a profile like BEGINNER, MODERATE, EXPERT. Since its a very small component whose re-render will hardly make any difference and creating a new component for such a small case will be time-consuming. Also if you keep making components for very small-small view, soon you will end up with so many components and it will be hard to manage when working with a big project. Also always keep in mind Pure Component comes with peculiarities of the shallowEqual.
 
-#### Conclusion
-
-Pure Components gives a considerable increase in performance because it reduces the number of render operation in the application which is a huge win for complex UI and therefore advised to use if possible. Also, there will be cases where you want to use the lifecycle methods of Component and in such cases, we cannot use stateless components.
-
 Stateless Components are easy and fast to implement. They are good for very small UI view where re-render cost won’t matter that much. They provide cleaner code and less number of files to deal with.
 
 ### What is Shallow Comparison
@@ -105,3 +99,4 @@ In other words, shallow comparison will check that primitives have the same valu
 4. [https://logrocket.com/blog/pure-functional-components/](https://logrocket.com/blog/pure-functional-components/)
 5. [https://daveceddia.com/react-redux-immutability-guide/](https://daveceddia.com/react-redux-immutability-guide/)
 6. [https://reactjs.org/docs/react-api.html#reactpurecomponent](https://reactjs.org/docs/react-api.html#reactpurecomponent)
+

React/this.props.children.md

@@ -36,6 +36,7 @@ function App () {
             <Picture key={PIcture.id} src={picture.src} >
                 // whatever is placed here is passed as props.children
                 // Like I can place a <div></div> here and it will be rendered as a child to the Picture component.
+                // Note, I am not including this extra divs in the Picture componet, but here in App component, where I am calling the picture component.
             </Picture>
         </div>
     )
@@ -50,11 +51,14 @@ You might want to assume that App.js will render as its html within the App.js,
 
 Anything inside the <Picture> JSX tag in the App component gets passed into the Picutre component as a children.prop. Since Picture renders {props.children} inside a <div>, the passed elements appear in the final output.
 
-This de-couples the <Picture> component from its content and makes it more reusable. So basically I take code out of <Picture> component and put them just-in-time, within <Picture> when this component itself is being called or rendered. See this example
+This de-couples the <Picture> component from its content and makes it more reusable, because I will put the children when the Picture component renders inside a parent component, and not when its defined.
+
+So basically I take code out of <Picture> component and put them just-in-time, within <Picture> when this component itself is being called or rendered. See this example for a simple implementation.
+
 [https://medium.com/javascript-in-plain-english/how-to-use-props-children-in-react-7d6ab5836c9d](https://medium.com/javascript-in-plain-english/how-to-use-props-children-in-react-7d6ab5836c9d)
 
 #### Further Reading
 
-### [Another simple example is here](https://codepen.io/rohanpaul/pen/bxoMxr)
+#### [Another simple example is here](https://codepen.io/rohanpaul/pen/bxoMxr)
 
-### [https://codeburst.io/a-quick-intro-to-reacts-props-children-cb3d2fce4891](https://codeburst.io/a-quick-intro-to-reacts-props-children-cb3d2fce4891)
+#### [https://codeburst.io/a-quick-intro-to-reacts-props-children-cb3d2fce4891](https://codeburst.io/a-quick-intro-to-reacts-props-children-cb3d2fce4891)