<p>Although what react is doing looks quite complex, the underlying logic is very simple. And the easiest way to understand is just running some simple examples. We’ll dive into how react renders components and updates the actual DOM.</p>
<h2 id="rendering-react-components"><a aria-hidden="true" tabindex="-1" href="#rendering-react-components"><span class="icon icon-link"></span></a>Rendering React Components</h2>
<p>In other words, this is calling the <code>render()</code> method of the component.</p>
<p>Although it might seem confusing at first glance, it’s actually super simple and straightforward. There is one simple rule: when you call <code>setState</code> in a component, that component and all of its children are marked as dirty. That means <code>render()</code> method will be called for each of these dirty components. While doing this, React does not even check whether props/state is actually changed, it just marks them as dirty blindly.</p>
<p>When you call <code>setState()</code> in component B, <code>render()</code> will be called for B, D, E, and H.</p>
<p><img src="https://s3.us-east-1.amazonaws.com/resource.mixa.site/meric/posts/img/how-react-rendering-works-a-step-by-step-guide/cover.jpg" priority="1"></p>
<p>Let’s see it in action.<br>
In this example, we’re calling <code>setState</code> on the Parent. It will mark the Parent and Child component as dirty. So, every second, both Parent and Child will get re-rendered. Please note, we’re not even changing the value of <code>unusedField</code> , it’s still <code>1</code>, but React re-renders everything regardless.</p>
<div class="embed-container">
  <iframe width="100%" height="400" src="//jsfiddle.net/merictaze/3ow61faq/embedded/js,result/" allowfullscreen frameborder="0"></iframe>
</div>
<p>When we move <code>setState</code> to the Child component, only child will get re-rendered every second while Parent is rendered only once.</p>
<div class="embed-container">
  <iframe width="100%" height="400" src="//jsfiddle.net/merictaze/ko2La8jg/embedded/js,result/" allowfullscreen frameborder="0"></iframe>
</div>
<p>Some of you might be asking “<em>OK, when state changes, component and its children re-renders, but what about props?</em>”. Let’s say component has <code>props.firstName</code>. Since it’s a prop, it means it is passed by its parent (parent can also be a HOC such as redux’s <code>connect()</code>). If you keep following <code>firstName</code> prop, it will eventually be defined as a <code>state</code> variable in one of the ancestors. If <code>state.firstName</code> is changed using <code>setState()</code>, it will trigger a re-render for that ancestor and all of its children. That means all the components which have <code>state.firstName</code> and  <code>props.firstName</code> also get re-rendered. So, all components will be showing the latest value for <code>firstName</code>. That's why React only cares about <code>state</code> not <code>props</code> while deciding on whether to render a component.</p>
<p>That’s it about default component rendering. Easy peasy! This simple logic will work great for most of the applications. If you have a complex application, you might need to fine-tune this behavior. Now, let’s see some ways of doing that.</p>
<h3 id="using-shouldcomponentupdate"><a aria-hidden="true" tabindex="-1" href="#using-shouldcomponentupdate"><span class="icon icon-link"></span></a>Using shouldComponentUpdate</h3>
<p>When react marks a component as dirty due to <code>setState()</code> call, it calls this method to decide whether to re-render the component and its children. By default, this method returns <code>true</code> . That’s why they are all re-rendered on every <code>setState()</code> call. You can override this method and tell React when you want your components to get re-rendered, and when it's safe to skip.</p>
<p>In below example, since we know <code>unusedField</code> is not needed in our component, we can ignore it. Also instead of re-rendering the component on every <code>setState</code> call, we can tell to re-render only when the actual value of <code>usedField</code> changes.</p>
<p>Although we call <code>setState()</code> every second for two fields, nothing will be re-rendered as <code>state.unusedField</code> is not used in <code>shouldComponentUpdate()</code> and <code>state.usedField</code> is always <code>1</code>. So, <code>shouldComponentUpdate</code> will return false.</p>
<div class="embed-container">
  <iframe width="100%" height="400" src="//jsfiddle.net/merictaze/ynpLavwt//embedded/js,result/" allowfullscreen frameborder="0"></iframe>
</div>
<p>When we actually change the value of <code>state.usedField</code>, both Parent and Child will get re-rendered every second since <code>componentShouldUpdate</code> will return true.</p>
<div class="embed-container">
  <iframe width="100%" height="400" src="//jsfiddle.net/merictaze/efuxgms4/embedded/js,result/" allowfullscreen frameborder="0"></iframe>
</div>
<p>It’s suggested not to use <code>shouldComponentUpdate()</code> unless you really know what you’re doing and need to optimize the component really bad. It’s because in real world, your component will not be as simple as the one above. You’ll have tons of props/state with complex JSON and it will get hard to keep <code>shouldComponentUpdate</code> up-to-date. If you add a new prop and forget to add in the method, your component will not re-render and good luck debugging it.</p>
<p>Another case might be you only care about some nested fields in a prop. Say you have a prop like this</p>
<pre><code class="language-javascript">order: {
  orderId: '12345',
  shippingDetails: {
    deliveryDate: '2019-10-10 12:00',
    status: 'IN TRANSIT'
  },
  customerName: 'John Doe'
}
</code></pre>
<p>You only care about <code>props.order.shippingDetails.deliveryDate</code> and <code>props.order.orderId</code>. You can compare these two specific fields in your <code>shouldComponentUpdate</code> method.</p>
<pre><code class="language-javascript">shouldComponentUpdate(nextProps, nextState) {
  return this.props.order.orderId !== nextProps.order.orderId
    || this.props.order.shippingDetails.deliveryDate !== nextProps.order.shippingDetails.deliveryDate;
}
</code></pre>
<p>What if some developer decides to use <code>props.order.customerName</code> in the component and forgets to add this field to <code>shouldComponentUpdate</code> method? React will not re-render the component when <code>customerName</code> changes. One way to prevent this is using a deep equality check on <code>props.order</code> which will compare every single nested field in the object. (but, please don’t do this)</p>
<pre><code class="language-javascript">shouldComponentUpdate(nextProps, nextState) {
  return !deepEqual(this.props.order, nextProps.order);
}
</code></pre>
<p>If you don’t want to care even individual props, you can do something like below and your <code>shouldComponentUpdate</code> will always be up-to-date. (please don’t do this either)</p>
<pre><code class="language-javascript">shouldComponentUpdate(nextProps, nextState) {
  return !deepEqual(this.props, nextProps)
    || !deepEqual(this.state, nextState);
}
</code></pre>
<p>This might get super slow easily. At this point, you may realize the importance of immutable objects. If you create a new <code>order</code> object whenever <code>order.shippingDetails.deliveryDate</code> or any other field changes, you wouldn’t need to compare any sub-field. As long as the old and new references are the same (i.e. <code>this.props.order === nextProps.order</code>), you are sure nothing changed in this object. If they’re not the same, that means some field somewhere in <code>order</code> was changed, so no more <code>deepEqual</code>.</p>
<p>So, with everything we learned so far, this seems like the best way to implement <code>shouldComponentUpdate()</code> as long as you don’t mutate sub-fields in your state. ( <code>shallowEqual</code> will compare top-level fields only like <code>this.props.field1 === nextProps.field1 &#x26;&#x26; this.props.field2 === nextProps.field2</code>)</p>
<pre><code class="language-javascript">shouldComponentUpdate(nextProps, nextState) {
  return !shallowEqual(this.props, nextProps)
    || !shallowEqual(this.state, nextState);
}
</code></pre>
<p>Guess what? This is exactly what PureComponent does. That’s why it’s the suggested approach over using <code>shouldComponentUpdate()</code>. It’s safer, faster with one rule, that is making state fields immutable.</p>
<h3 id="pure-components"><a aria-hidden="true" tabindex="-1" href="#pure-components"><span class="icon icon-link"></span></a>Pure Components</h3>
<p>If you remember, default implementation for <code>shouldComponentUpdate</code> was returning true all the time. So, when you extend <code>React.Component</code> in your component, that's what you get. But, you have another option, extending <code>React.PureComponent</code> to have a better implementation of <code>shouldComponentUpdate</code> as long as you promise you'll keep it pure. And its implementation is exactly what we've seen in the previous part, shallow checks on <code>props</code> and <code>state</code>. Now let's check some examples.</p>
<p>First, let's see the beauty of PureComponent. In the example below, we call <code>setState</code> every second, and update order object at random times.</p>
<div class="embed-container">
  <iframe width="100%" height="400" src="//jsfiddle.net/merictaze/L80sjoxp/embedded/js,result/" allowfullscreen frameborder="0"></iframe>
</div>
<p>As you've realized, render counter does not increase every second although you call <code>setState()</code> every second. It re-renders the components only when <code>order</code> object is changed.</p>
<p>Now, let's see what could go wrong if you don't use PureComponent properly. Here, we're going to update a field in <code>order</code> object in-place and call <code>setState</code> with that. If you were extending <code>React.Component</code>, it would just work since you call <code>setState()</code> and <code>shouldComponentUpdate()</code> always returns true. However, when you use <code>React.PureComponent</code>, shallow equality check in <code>shouldComponentUpdate</code> will return false since reference of <code>order</code> object hasn't changed. So, no re-rendering and you won't be able to see the latest value of the <code>customerName</code>.</p>
<div class="embed-container">
  <iframe width="100%" height="400" src="//jsfiddle.net/merictaze/fcm8begw/embedded/js,result/" allowfullscreen frameborder="0"></iframe>
</div>
<h2 id="rendering-dom"><a aria-hidden="true" tabindex="-1" href="#rendering-dom"><span class="icon icon-link"></span></a>Rendering DOM</h2>
<p>Every time you make a change in the actual DOM, it triggers a bunch of events and browser needs to do  some more stuff which is time-consuming. Because of that React came up with this idea of Virtual DOM. It’s a simplified JSON representation of the DOM. No events attached to elements and also browser does not care when you change it. It’s just the elements, their attributes and their children in a JSON object. It makes it cheap to make changes while rendering React components, and then React finds an efficient way of updating the actual DOM by diffing the old and new virtual DOMs.</p>
<p>It’s an internal React logic and there is not much you can do about it. But, it’s good to know how it works so that you create your components in a way that it causes fewer DOM updates. However, the problem is that React can change the logic any time as it’s an internal implementation detail. So, better not to rely on anything on this part as it can change any time.</p>
<p>More on how React updates the actual DOM can be found here <a href="https://reactjs.org/docs/reconciliation.html">https://reactjs.org/docs/reconciliation.html</a></p>
<h2 id="wrap-up"><a aria-hidden="true" tabindex="-1" href="#wrap-up"><span class="icon icon-link"></span></a>Wrap up</h2>
<p>Don't go the route of premature optimization. Just go with the default behavior. When you realize re-rendering some components is really concerning and causing performance issues then try to optimize it by overriding <code>shouldComponentUpdate()</code>.</p>
<p>If you're confident of the purity of your components or using libraries like <code>immutable-js</code>, which ensures you won't be able to make in-place updates to your <code>state</code>, then it's better to go with <code>React.PureComponent</code> than implementing your own <code>shouldComponentUpdate()</code> as it gives less room for error and shallow equality check is cheap.</p>

Maybe you’re just getting started with distributed systems and system design, or you just need a quick recap for your upcoming interview. In either case, in this post, you’ll find the most common concepts of system design and the most important aspects of them. Let’s get started.

Recap of System Design Interview Concepts

Although what react is doing looks quite complex, underlying logic is very simple. And the easiest way to understand is just running some simple examples. We’ll dive into how react renders components and updates the actual DOM.

How React Rendering Works - A Step by Step Guide

DynamoDB is Amazon’s NoSQL database which offers single-digit milliseconds latency. It is great for variety of use cases, but when you need to run complex search queries on your dataset, you quickly realise it is not designed for it.

Indexing DynamoDB Items to ElasticSearch using AWS Lambda

Multitasking is the source of all evil. Until recently, I also liked having multiple screens and multi-tasking like many others. It was great to code on one screen while reading the slack messages and emails on the other screen. But, it was so easy to get distracted by continuous incoming notifications while trying to read, write or code something. Often, I was feeling tired in the middle of the day because continuous context switching was draining my energy and destroying my focus on the task I was working on. 

5 Tips To Stop Multitasking and Double Your Productivity

In this post, we are going to setup an environment with API Gateway, Lambda and DynamoDB using serverless framework which can be deployed to AWS directly or run fully local.

Going Serverless Offline

You solved 60 LeetCode hard and 300 LeetCode medium questions, you were a rockstar in your coding round and provided the most efficient solution in the world, but you couldn’t get the offer. Sounds familiar? Either case, keep reading, you might find some useful tips.

How to Succeed in Your Coding Interview

While making a simple request to https://google.com to see that simple search page, there are a lot of things going on behind the scenes to keep you secure. Understanding this flow will give you a lot of confidence in various topics like Digital Certificates and Signatures, Symmetric/Asymmetric key encryptions, Certificate Authorities and how they all work together to help you have secure communication.

What happens when you hit google.com using HTTPS

We are going to create a single component that supports text, textarea, select, radio, and checkbox. It will absorb all implementation differences for different inputs and will allow us using a unified component in our Formik forms.

Creating a unified Formik input field to support all input types seamlessly

System design questions can be asked for any level with different expectations from the candidate, but to get a Senior offer, you have to rock this round. Practice makes perfect - like for anything else, it applies for system design interview too. So, keep practicing without taking shortcuts, practice as if it’s the real interview and always follow the same steps to make it perfect.

How to Succeed in Your System Design Interview

Attacks like CSRF or XSS are still not clear to many of us. It is not because they are super hard to understand, but it requires some basic understanding of concepts like SOP, CORS, CSP, HTTPS. Let's start with what's Same-origin Policy