DEV Community: Bryan Almaraz

Understanding Reconciliation: React Rendering Phases

Bryan Almaraz — Mon, 16 Nov 2020 08:10:27 +0000

Ever wonder how React takes your code and creates what you see on the screen? Or how React knows whether to update your component or not?

Learning how rendering works in React will allow you to optimize your apps and make better decisions on how to structure your React application.

Let's get started...

How React Works

There are two phases to the React rendering cycle.

The render phase and the commit phase.

Here's the quick overview. The Render phase takes your JSX and turns it into a javascript representation of what the HTML structure should look like. This is called the VirtualDOM. While the commit phase is actually taking that representation and applying it to the real DOM. The whole process is called reconciliation.

Rendering Phase

There are also two types of renders. An initial render and a re-render. Initial rendering is when your app first starts up. A re-render is when your state or props have updated.

The initial rendering phase starts from your root component (usually App if using CRA) and works its way down the tree. React will take your JSX components and build out a javascript representation of what the actual DOM will look like with it. This is called the VirtualDOM and this is one part of the rendering phase.

Once the Virtual DOM is created, React will compare what it has built out to what the actual DOM has using a fancy diff algorithm. However, once it has finished comparing it ends up with a list of what needs to be changed. This is still considered part of the rendering phase.

Side Note: It's important to note that React goes through its virtualDOM and creates a list of those changes that need to be made to the actual DOM. Meaning that React will wait to commit all the updates so it does it in one swift process and not in parts. This is what it means when you read that React does batch updates. This is crucial to understand when working with state.

Re-rendering is similar, but with one key difference. It does not go through every component to check for updates. Instead, when your component state or props update React uses a flag to mark that component. Basically saying that this component has been marked for an update.

Commit Phase

Once React has done the comparison between its new and old components using that diff algorithm and has a list of changes. It will go ahead and surgically apply those changes to the actual DOM. Meaning that it will only change the particular elements of the DOM that have changes, not every single element. This is called the commit phase.

The commit phase is where React actually touches the DOM and makes changes.

It's important to point out that React may go through the render phase but never commit. This can happen if the component returns the same result as the last time. Often happening if the parent component's state updates causing a render, but the child component(s) still create the same output anyways.

Fast Guide to Using React.memo

Bryan Almaraz — Tue, 10 Nov 2020 16:49:39 +0000

What is React.memo?

React.memo is a Higher Order Component that will wrap the component you want to memoize. It checks if the props have changed, if so it will continue with the re-render, if not then it will stop the re-render and all recursive renders of its child components.

It is important to understand that it will only do a shallow comparison of your props. So functions and objects will be considered new props even if they haven't changed. This is due to reference equality for objects and functions.

Side note: React is pretty smart, if your state is an object. React does some magic behind the scenes and knows that your object in state has not changed. It does not do this with normal objects though.

// if you pass this state, react will not re-render your component unless state updated
const [data, setData] = useState({someData: true});
// if you pass this as a prop, your memoized component will still re-render
const someObject = {someObj: true}

Why do we need it?

React.memo is useful when a parent component has re-rendered due to some state or prop change and a child component that lives inside that parent component does not make use of any of those changes. The child component should not have to re-render if it is going to return the same output.

How to use memo.

// UnrelatedComponent.js
function UnrelatedComponent () {
  return <h2> Footer Content... </h2>
}

// before
export default UnrelatedComponent
// after, now the component will not re-render unless its props have changed.
export default React.memo(UnrelatedComponent)

// App.js
function App () {
  const [count, setcount] = useState(0)

    return (
     <div>
           <h2>{count}</h2>
           <UnrelatedComponent />
     </div>
    )
}
export default App

If count updates and UnrelatedComponent is not using memo, then it will re-render even though it does not make use of the count state.

Some Gotchas

A few good to knows when using react.memo.

If you are passing in a function, use the useCallback hook to memoize the function or else it will re-render due to reference type equalities.
If you are passing in an object, use the useMemo hook to memoize the object or else it will re-render due to reference type equalities.
React.memo takes in a function as a second parameter that has the previous and next props so you can have more fine grain control on what props should trigger a re-render.
If your memoized component is using the children prop, it will always re-render due to the prop always being a reference.
If you are using a function that should be updated every time a re-render happens, like for example a date function, or a random calculation, then you should not memoize the component.

More Resources: https://dmitripavlutin.com/use-react-memo-wisely/

Understanding The Execution Context & Stack

Bryan Almaraz — Mon, 09 Nov 2020 09:36:24 +0000

To become a good JavaScript developer you need to understand how JS is interpreted. Knowing how the execution context works will allow you to connect all the dots when it comes to learning about hoisting, scope, and closures. Let's get started.

This guide is meant to be a quick break down and easy reference when you need it.

What is the Execution Context
- Execution Context Phases
- Execution Context Types
What is the Execution Stack (Call Stack)
What is hoisting
What is scope
What are closures

What is the Execution Context?

Whenever JavaScript first runs your application code or invokes a function it creates an Execution Context. An Execution Context is a wrapper or container that helps manage the code currently executing in the program. It takes into account the environment (context) in which the code is currently executing.

When JavaScript first interprets your code it creates a Global Execution Context. This is like a global environment for your application. This global environment is a giant object. It then creates a special keyword for you called "this". It sets "this" as a pointer to the giant global object. If you are running your code in the browser the giant global object is called the window object. It also creates a reference to the outer environment.

In other words: The execution context is just a container that is currently running code and is taking into account the environment (context) in which it is running.

There are two phases to the Execution Context.

Execution Phases

The Creation phase and the Execution phase.

Creation Phase

Create a global object
Create a "this" keyword and assign it to the global object
Creates memory in its environment for the variables and functions inside the code
Sets variables to undefined & entire functions in memory
Sets a reference to its outer environment (null in Global EC)

Execution Phase

Starts executing your code line by line
Sets values to your variables.

Execution Types

The two important types of execution contexts in Javascript.

Global EC

Functional EC

The global EC we just discussed. The functional EC is not very different from the global EC. It also has the same two phases only with slight alterations in the creation phase.

~~Create a global object~~ | Create an arguments object
Create a "this" keyword and assign it to the existing global object
Set aside memory in it's environment for the variables and functions inside the code
Sets variables to undefined & functions in memory
- Except arguments passed in become variables and are assigned to memory with their value, not to undefined like regular variables.
Sets a reference to its outer environment

Execution Stack (Call Stack)

The execution stack or also known as the "call stack" is where execution contexts are stored. Keep in mind that a stack is a type of data structure that has one rule. "Last In, First Out".

When Javascript runs your script it creates the global execution contexts and pushes it on to the Execution Stack. This becomes the base of your execution stack and will stay there until your program is finally done before it pops off.

As mentioned before, the execution stack is just where execution contexts are stored. There are only two ways an execution context can be pushed onto the execution stack. The first is when your program starts up. The GEC is created and pushed onto the Execution Stack. The second is when JavaScript is executing your code and runs into a line that invokes a function. When a function is called a new execution context is created for that function. That Function Execution Context holds its "personal" variables and functions. Once that function is finished it pops off the Execution Stack and whatever was on the stack before that function was called is resumed.

Hoisting

When JavaScript starts the creation phase of the execution context it creates your variables in memory and sets them to undefined. It's really that simple.

So if you try using a variable before it was initialized it will be undefined (using the var keyword) instead of throwing an error. So it seems like your variable was "hoisted" to the top of the program because it knew that you had that variable. JavaScript just didn't know what the value was yet.

Scope

During the Execution Phase, JavaScript is creating new execution contexts for functions and already created the global execution context. So when referring to scope, it simply means what variables are in the current execution context. The variables and functions that are in that execution context are also in the scope.

When using a variable that is not in a function, but outside the FEC then the scope extends outwards (and only outwards) to find that variable.

Scope has a parent-child relationship where the child scope can ask the parent scope for values of variables but not vice-versa. This is called the scope chain.

Closures

When a function returns a function that references a variable in the outer function a closure is created.

A closure encloses or locks-in its environment variables (scope) and has references to them even after that execution context has been popped off the stack.

How this is possible?

When a function execution context is created remember that it creates it's own memory space for it's variables and functions. Once the function has finished and returns. The variables and functions that were created in that function are not deleted right away. They are just no longer accessible to the outer scope, but they are still somewhere in memory.

It's like the global scope lost its address and can no longer locate it. But when a function returns a function that uses a variable from the function that returned it. Then that function that was returned will always have a reference to those variables even if the rest of the program does not. It encloses its variables and will remember where to find them.

So a closure just makes sure its scope is always intact. A closure just knows where in memory its variables are, even if the execution context that created those variables is not on the call stack anymore.