Often times, the inability to debug a certain error stems from not understanding some foundational concept.

You can say the same thing if you don’t understand some more advanced concepts because you lack the knowledge of certain fundamentals.

In this article, I hope to explain what I consider some of the most important foundational React concepts you need to understand.

These concepts aren’t particularly technical. There are lots of other articles that cover those — things like props, state, context, setState , and so on.

However, in this article I’ll focus on some more conceptual knowledge that forms the basis of most technical things you’ll do in React.

Ready?

How React works under the hood

One of the first things everyone learns in React is how to build components. I’m pretty sure you learned that too.

For example:

// functional component function MyComponent() {  return <div> My Functional Component </div> }// class based component class MyComponent extends React.Component {  render() {     return <div> My Class Component </div>   }}

Most components you write will return some elements:

function MyComponent() {  return <span> My Functional Component &lt;/span> //span element}class MyComponent extends React.Component {  render() {     return <div> My Class Component &lt;/div> //div element  }}

Under the hood, most components return a tree of elements.

tQn1uuZsujd4JU-cIxVrjn8-3Giy1CRAqjCD
Components, when evaluated internally, often times return a tree of elements.

Now, you must also remember that components are like functions that return values based on their props and state values.

7NCegDIGXAs8OGYEP733SK7L-uOpMI4vZwSR
Components are like functions with “props” and “state” parameters.

Consequently, whenever the props or state values of a component change, a new tree of elements is rendered.

jqur2fLzWkWzsXgcm0bDIVRRJWSfnN0v6DSN
If the props or state values change, the tree of elements is re-rendered. This results in a new tree.

If the component is a class-based component, the render function is invoked to return the tree of elements.

class MyComponent extends React.Component {    render() {    //this function is invoked to return the tree of elements  }}

If the component is a functional component, its return value yields the tree of elements.

function MyComponent() {     // the return value yields the tree of elements   return <div>
   </div>}

Why is this important?

Consider a component, <MyComponent /> which takes in a prop as shown below:

<MyComponent name='Ohans'/>

When this component is rendered, a tree of elements is returned.

3DsSWux3GMF8nLy8KyWXqaciojsvhKaIcts8
A tree of elements returned from rendering <MyComponent />

What happens when the value of name changes?

<MyComponent name='Quincy'/>

Well, a new tree of elements is returned!

OQ1FFA7FNaRpmkrMH43CpbHJCV2opTEBNMqe
A NEW tree of elements returned from rendering <MyComponent /> with different props

Okay.

Now, React has in its custody two different trees — the former and the current element tree.

At this point, React then compares both trees to find what exactly has changed.

cO44K8IzUSeTPwvnGm5nJwYhfn0AvC5lnyGX
Two different trees. What’s really changed in both trees?

Most times the entire tree hasn’t changed. Just some updates here and there.

Upon comparing these two trees of elements, the actual DOM is then updated with the change in the new element tree.

Easy, huh?

This process of comparing two trees for changes is called “reconciliation”. It’s a technical process, but this conceptual overview is just great for understanding what goes on under the hood.

React Only Updates What’s Necessary. True?

When you get started with React, everyone’s told how awesome React is — particularly how it just updates the essential part of the DOM being updated.

o83thhmBUVqoiatZw56dEY6yGNMJn5jxemhw
From the React Docs: DOM inspector showing granular updates.

Is this completely true?

Yes it is.

However, before React gets to updating the DOM, remember that under the hood — it had first constructed the element tree for the various components and did the essential “diffing” before updating the DOM. In other words, it had compared the changes between the previous and current element trees.

The reason I re-iterate this is, if you’re new to React you may be blind to the performance ditches dug in your app because you think React just updates the DOM with what’s necessary.

While that is true, the performance concerns in most React apps begin with the process before the DOM is updated!

Wasted Renders vs. Visual Updates

No matter how small, rendering a component element tree takes some time (no matter how minute). The time for rendering gets larger as the component element tree increases.

The implication of this is that in your app you do not want React re-rendering your component element tree if it is NOT important.

Let me show you a quick example.

Consider an app with a component structure as shown below:

sN9IozHOb0YjHvIPzCleBcjPZsTR8nPNZn3y
An app with a parent component A and child components B,C and D.

The overall container component, A receives a certain prop. However, the sole reason for this is to pass the props down to component D.

5xX0JPX-o-Gej4yKA3iJ8mv4EQpLEaWkvQgH
The parent component A receives some props and passes them down to the child component D.

Now, whenever the prop value in A changes, the entire children elements of A are re-rendered to compute a new element tree.

74D67kRq4cnFHlKfw86OUkdCO1nMYgT9E-rN
iAEokbsFD2IW1AOG7DSnhfRFTp0VztjXf5YA
When the parent component receives new Props, every child element is re-rendered and a new tree returned.

By implication, the components B and C are also re-rendered even though they haven’t changed at all! They have not received any new props!

This needless re-rendering is what is termed a “wasted” render.

In this example, B and C need not re-render, but React doesn’t know this.

There are many ways to deal with such issue, and I cover that in my recent article, How to Eliminate React Performance Issues.

Moving forward, consider the application below:

eSvpbb0SILVtzIf8G7peS9DfJOK2gS1bIc1s
Cardey in Action :)

I call this app Cardey.

When I click the button to change the user’s profession, I can choose to highlight updates to the DOM as shown below:

QnX-5eQrP7GkCVyxl5Xkfu78uhxN-9JhJMMJ
Enable the visual updates (Paint Flashing) via Chrome Devtools

And now I see what’s been updated in the DOM.

This is a representation of the visual updates to the DOM. Note the green flash around the “I am a Librarian” text.

This is great, but I am concerned about React’s initial rendering of the component element tree.

So, I could choose the check that as well.

xDeyGJE6fL42FrSmU15nm5she0xfO6mtC42G
Enable the highlight update toggle in React Devtools

Upon doing this, I see what components are actually re-rendered when I hit that button.

zduYcMxUoMrKLzHbLABBf3d2zkVa0gkv9Stc
Note the green flash around the user card.

Do you see how the visual updates to the DOM and react’s render updates are different?

The large user card was re-rendered but just the small text region was updated.

This is important.

Conclusion

I believe you now have a more intuitive understanding how what happens under the hood in your React components.

Actually, a lot more happens than I have discussed here. However, this is a good start.

Go build great apps!

Are you learning React/Redux at the moment? If yes, I have a really great book series on Redux. Some say it’s one of the best tech books they ever read!