DEV Community: Tiago Ferreira

Elevate Your React Code: Tackling Prop Drilling

Tiago Ferreira — Mon, 29 Jan 2024 16:00:00 +0000

Either by our own hand or by others, we have all seen code along the lines of:

const ComponentA = (props) => {
  const [visible, setVisibility] = useState(true)
  //...
  return <ComponentB visible={visible} />
}

const ComponentB = (props) => {
  //...
  return <ComponentC visible={props.visible} />
}

const ComponentC = (props) => {
  //...
  if (!props.visible) return null
  //...
}

Seems pretty innocent, right? Well, this seemingly reasonable example is actually an anti-pattern called Prop Drilling. Let's dive into what that means and how to avoid it!

What is Prop Drilling?

“Prop drilling” is the act of passing props from parent to child for multiple layers without modification.

In the example given above, the visible prop was drilled from ComponentA to ComponentB to ComponentC without modification.

Why does this matter?

Prop Drilling is regarded as an anti-pattern for React since it can negatively impact the performance and maintainability of your code.

At a high level, Prop Drilling can cause performance issues since it can cause unnecessary re-rendering of components. This happens because React will re-render a component if any of its props change. If a component is passed a prop that it doesn't use, it will still re-render when that prop changes. This may not be a big deal for small applications, but can become a major issue for large applications that contain many expensive-to-render components.

On the maintainability side of things, Prop Drilling introduces dependencies between components that may not be obvious. This can make it difficult to refactor code quickly; which can be killer when developing new features.

If you wish to level up your React code, you should be aware of when you use Prop Drilling and be considerate of other approaches that can solve the problem at hand.

How does Prop Drilling creep into code?

Prop Drilling can be nefarious and creep into code unexpectedly. It requires vigilance in order to avoid it. Let's go through an example!

The following parts reference interactive examples that are available on ferreira.io. Gifs have been used in their place, but the sample app and code tabs for each interactive example are only available in the original published article.

Part 1: Setting Up Our Layout

To start out, let's provide some context for the example that we'll be using! We are building a simple web app with some containers, buttons, and text. Nothing is currently hooked up, so there isn't much functionality, but we can get a general sense of what the application, component hierarchy, and code looks like:

The cursor icon on the top-right of each component indicates that an onClick handler has been set for that component.

All of the components have been given a default onClick handler for this first example. If you click on any of the components in the component hierarchy view, it will forcibly re-render that component which can be seen from the flash of green. You'll also see the number of times a component re-rendered in the bottom right-hand-side of each component.

Part 2: Adding Component State

Let's upgrade our application a little! We'll add some state to the Button component. This state will control a component's theme (which can be 'light' mode or 'dark' mode):

Reminder: clicking on the components from here on out will not forcibly re-render them (though they may re-render due to state update or changed props)

Wonderful! To start, we have set the onClick for the Button component to toggle the theme. If you click on Button, you'll notice that the theme for that component changes and things look good!

Part 3: Pulling Up State

Let's now integrate some more components into our theme. We can start by pulling up the component state to the SettingsPage component so that we can pass the data down to its children. Then we can pass the theme's toggle function down so that our button components can update the theme:

Both IconButton and Button can update the theme in SettingsPage if you click on them.

Awesome, this works as expected! But interestingly enough, all of the child components of SettingsPage are re-rendering every time the theme changes.

This happens because React will re-render children components whenever a parent component re-renders. State updates will cause a component to re-render and thus this causes a cascade of re-renders.

Though this is generally really fast, it can cause performance problems for large applications. Sometimes, you only need data in certain places, and having everything else re-render just for a small change can be expensive. So let's try to do some optimizations!

Part 4: React memo

React provides a nice utility wrapper for components called memo. This utility prevents a component from re-rendering unless the props passed in have changed. At first glance, this sounds perfect for us, so let's try to wrap all of our components with it:

Huh, we still see a lot of components re-rendering even though we only pass the theme's toggle function down, what gives?

Part 5: React useCallback

The important thing to realize is that memo uses Object.is for equality checking. In Javascript, primitives (like number, string, boolean) will be checked by value equality. However, objects, arrays, and functions are checked by reference equality. This means that code that defines a function will have a different reference to that function every time it's called. Thus reference equality checks will fail.

'123' == '123' // true (values are the same)

const A1 = { a: '123' }
A1 == A1 // true (references are the same)

const A2 = { a: '123' }
A2 == A2 // true (references are the same)

A1 == A2 // false (references are different even if contents are the same)

When our SettingsPage component re-renders, it ends up creating a new toggle function each time. This means that when memo checks the props, it sees that the function reference is different and re-renders the component.

One way we can fix this issue is by using the useCallback hook from React. By wrapping our toggle function in that, we can maintain a stable reference which prevents the components from re-rendering:

Amazing! Now only the SettingsPage component re-renders when its state changes. This saves us processing time since we don't need to re-render the child components anymore.

Part 6: Using Our Theme

Great, now that we have fixed our performance problem, let's try to re-add our prior functionality from above where we can use the current state of the theme to change the Button component. We naturally do this by passing the theme's value down through the Content component and into Button:

Great! We can now see the theme change in Button! Understandably, Button re-renders when this state changes. Unexpectedly though, Content also re-renders!

Why is this happening? Well, going back to what was said in the previous section, memo prevents re-renders only if the props are equal. With useCallback, we made sure our toggle function remains stable between renders, but our theme state still changes either way.

At a glance, this may feel inevitable, but we can actually improve this! You may wonder why, but if you imagine the component hierarchy being much larger, or if our Content component was very expensive to render, then avoiding re-renders can be very helpful.

Part 7: Replacing Component State With App State

Alright, let's finally wrap this example up! Now that we see how difficult it is to use component state that spans across our application, we can instead try to use application state instead. This generally takes the form of using a state management library (Redux being the most popular choice), but can be as simple as using React Context.

If we move our component state into app state and change our component code to connect to that app state directly (useSelector in Redux, useContext for React Context), we see something pretty awesome:

As you can see, we removed the state from SettingsPage and placed in into our App State. IconButton and Button can both update this state (by clicking on them) and Button reads from this state in order to show the appropriate theme to the user.

We have now eliminated all component re-renders except for Button (which is to be expected since it changes when the theme changes). From a performance perspective, this is the most ideal state we can get to.

Maintainability

A lot of the focus of the example above has been around creating performant React code. That said, avoiding Prop Drilling is also useful for code maintainability!

When I talk about maintainability, I'm referring to one's ability to extend code, refactor it, compose it, and generally maintain it as a product evolves over time. This is a broad category, but is very useful in order to avoid foot-guns, bugs, and more over time.

Returning to the code we had right before we pulled component state into app state (removing the performance improvements for clarity sake), we can see that toggleTheme and theme are passed down between components.

const Root = () => {
  return (
    <>
      <SettingsPage />
      <Modal />
    </>
  )
}

const Modal = (props) => {
  // ...
}

const SettingsPage = () => {
  const [theme, toggleTheme] = useTheme()

  return (
    <div>
      <IconButton toggleTheme={toggleTheme} />
      <Title />
      <Content toggleTheme={toggleTheme} theme={theme} />
    </div>
  )
}

const IconButton = (props) => {
  const { toggleTheme } = props

  return (
    <button onClick={toggleTheme}>
      <Icon />
    </button>
  )
}

const Title = (props) => {
  return (
    <div>
      <h1>Settings Page</h1>
    </div>
  )
}

const Content = (props) => {
  const { toggleTheme, theme } = props

  return (
    <div>
      <Text />
      <Button theme={theme} toggleTheme={toggleTheme} />
    </div>
  )
}

const Text = (props) => {
  return <p>Change Theme?</p>
}

const Button = (props) => {
  const { toggleTheme, theme } = props

  return (
    <button onClick={toggleTheme} className={theme}>
      Toggle
    </button>
  )
}

The reason this code isn't maintainable is that we have tied Content to both SettingsPage and Button through a dependency (via the props). In order to use Button anywhere else, we need to make sure that its new parent also passes down the same props that Content does.

To clarify this, let's use our example. What happens if we wanted to move Button to be a child of the Title component instead? Well, that change would look like the following.

const Root = () => {
  return (
    <>
      <SettingsPage />
      <Modal />
    </>
  )
}

const Modal = (props) => {
  // ...
}

const SettingsPage = () => {
  const [theme, toggleTheme] = useTheme()

  return (
    <div>
      <IconButton toggleTheme={toggleTheme} />
-     <Title />
-     <Content toggleTheme={toggleTheme} theme={theme} />
+     <Title toggleTheme={toggleTheme} theme={theme} />
+     <Content />
    </div>
  )
}

const IconButton = (props) => {
  const { toggleTheme } = props

  return (
    <button onClick={toggleTheme}>
      <Icon />
    </button>
  )
}

const Title = (props) => {
+ const { toggleTheme, theme } = props
+
  return (
    <div>
      <h1>Settings Page</h1>
+     <Button theme={theme} toggleTheme={toggleTheme} />
    </div>
  )
}

const Content = (props) => {
- const { toggleTheme, theme } = props
  return (
    <div>
      <Text />
-     <Button theme={theme} toggleTheme={toggleTheme} />
    </div>
  )
}

const Text = (props) => {
  return <p>Change Theme?</p>
}

const Button = (props) => {
  const { toggleTheme, theme } = props

  return (
    <button onClick={toggleTheme} className={theme}>
      Toggle
    </button>
  )
}

As we can see from the code diff, we had to manage a few props and make sure they get passed through properly. In this example, it's not too difficult, but imagine if we needed to update several intermediate components in order to get things to work. Things can quickly get more complicated!

Now let's imagine we wanted to move Button to a completely different part of the component hierarchy. We would need to move the component state so that it exists within an ancestor component for all of its instances.

const Root = () => {
+ const [theme, toggleTheme] = useTheme()
+
  return (
    <>
-     <SettingsPage />
-     <Modal />
+     <SettingsPage toggleTheme={toggleTheme} theme={theme} />
+     <Modal theme={theme} />
    </>
  )
}

const Modal = (props) => {
  // ...
}

const SettingsPage = () => {
- const [theme, toggleTheme] = useTheme()
+ const { toggleTheme, theme } = props

  return (
    <div>
      <IconButton toggleTheme={toggleTheme} />
      <Title />
      <Content toggleTheme={toggleTheme} theme={theme} />
    </div>
  )
}

const IconButton = (props) => {
  const { toggleTheme } = props

  return (
    <button onClick={toggleTheme}>
      <Icon />
    </button>
  )
}

const Title = (props) => {
  return (
    <div>
      <h1>Settings Page</h1>
    </div>
  )
}

const Content = (props) => {
  const { toggleTheme, theme } = props

  return (
    <div>
      <Text />
      <Button theme={theme} toggleTheme={toggleTheme} />
    </div>
  )
}

const Text = (props) => {
  return <p>Change Theme?</p>
}

const Button = (props) => {
  const { toggleTheme, theme } = props

  return (
    <button onClick={toggleTheme} className={theme}>
      Toggle
    </button>
  )
}

This example is basic, but in real-world scenarios, this potentially entails moving it up several layers of components. As we would expect, this can quickly get out of hand and it is much more difficult to maintain as the codebase changes. We've now modified several different components unrelated to the feature we were working on (not fun for code review) and introduced an increased risk of accidentally breaking something (not fun for on-call).

Now, what does it look like to change this code to use app state instead? Quite simply, it just takes moving the component in the right place. We've fully encapsulated the logic associated with the component to itself so that we're not polluting the rest of our application in the process.

const Root = () => {
  return (
    <>
      <SettingsPage />
      <Modal />
    </>
  )
}

const Modal = (props) => {
+ const theme = useSelector(themeSelector)
  // ...
}

const SettingsPage = () => {
- const [theme, toggleTheme] = useTheme()
  return (
    <div>
-     <IconButton toggleTheme={toggleTheme} />
+     <IconButton />
      <Title />
-     <Content toggleTheme={toggleTheme} theme={theme} />
+     <Content />
    </div>
  )
}

const IconButton = (props) => {
- const { toggleTheme } = props
+ const dispatch = useDispatch()
+ const toggleTheme = () => dispatch(toggleThemeAction)

  return (
    <button onClick={toggleTheme}>
      <Icon />
    </button>
  )
}

const Title = (props) => {
  return (
    <div>
      <h1>Settings Page</h1>
    </div>
  )
}

const Content = (props) => {
- const { toggleTheme, theme } = props
  return (
    <div>
      <Text />
-     <Button theme={theme} toggleTheme={toggleTheme} />
+     <Button />
    </div>
  )
}

const Text = (props) => {
  return <p>Change Theme?</p>
}

const Button = (props) => {
- const { toggleTheme, theme } = props
+ const dispatch = useDispatch()
+ const theme = useSelector(themeSelector)
+ const toggleTheme = () => dispatch(toggleThemeAction)

  return (
    <button onClick={toggleTheme} className={theme}>
      Toggle
    </button>
  )
}

Now, when we want to move the Button to be a child of the Title component, it's much more simple:

const Root = () => {
  return (
    <>
      <SettingsPage />
      <Modal />
    </>
  )
}

const Modal = (props) => {
  const theme = useSelector(themeSelector)
  // ...
}

const SettingsPage = () => {
  return (
    <div>
      <IconButton />
      <Title />
      <Content />
    </div>
  )
}

const IconButton = (props) => {
  const dispatch = useDispatch()
  const toggleTheme = () => dispatch(toggleThemeAction)

  return (
    <button onClick={toggleTheme}>
      <Icon />
    </button>
  )
}

const Title = (props) => {
  return (
    <div>
      <h1>Settings Page</h1>
+     <Button />
    </div>
  )
}

const Content = (props) => {
  return (
    <div>
      <Text />
-     <Button />
    </div>
  )
}

const Text = (props) => {
  return <p>Change Theme?</p>
}

const Button = (props) => {
  const dispatch = useDispatch()
  const theme = useSelector(themeSelector)
  const toggleTheme = () => dispatch(toggleThemeAction)

  return (
    <button onClick={toggleTheme} className={theme}>
      Toggle
    </button>
  )
}

A lot more simple, yeah? This code is more maintainable which allows us to easily extend, refactor, and compose as we build new features. This is a huge win for developer velocity and developer experience!

How to Create App State

Now, if you're new to React, you may be wondering how to create app state in your application. The best way to do so is to use a state management dependency to help out! The most popular option today is Redux and I'd encouraged you to use Redux Toolkit if you choose to go this route.

If your needs are simple, you can also just use React's builtin context. This is a part of React and doesn't need any additional dependencies to work. That said, there are similar performance issues from above that can occur when using objects and functions for the value of the context (due to reference equality checks).

Wrapping Up: Should I Ever Use Prop Drilling?

Now that we have reached the end of the article, you may be thinking that all forms of Prop Drilling are bad. This is where I tell you that there is time and place for everything. Prop Drilling can sometimes simplify code and definitely makes more sense in certain cases (like generic forms / components).

It's useful to recognize that React is very fast at re-rendering components, so it's important to profile your application to see if there are any performance issues before changing any code.

That said, I hope this has helped you better understand Prop Drilling and how it can impact your app's performance and maintainability! Cheers!

Opaque / Branded Types in Typescript

Tiago Ferreira — Wed, 28 Sep 2022 15:12:53 +0000

Typescript has amassed quite the following as one of the top ten most popular programming languages over the last several years. And for good reason! It has greatly accelerated development by providing compile-time guarantees that supports a greater development velocity while maintaining a high bar of quality.

As a quick overview, Typescript provides compile-time type checking in order to prevent common datatype bugs (among other things 😉). It has several native types defined that you can annotate variables with. These range from number, to string, to array/tuple definitions, and more. It even supports more complex types with unions, intersections, and string literals that can allow for incredibly expressive types to reflect the data that you are working with.

However, number or string isn't always specific enough. Sometimes our code specifically needs a value between 0-1 or only a valid email should be used.

What's wrong with just using the general type?

Although more general types like number or string can suffice in terms of general compile-time checks, they fail to provide checks for more nuanced cases. Take for example a function that requires a percentage as an input:

/**
* Sets the alpha value for an image.
* @param percentage - a number between 0 and 1
*/
function setAlpha(percentage: number) { ... }

In this case, we want a number type passed in, but specifically a number between 0 and 1. However, this can cause several potential problems:

setAlpha(0.5) // Correct
setAlpha(-0.5) // Runtime Error: Invalid Percentage - Typescript doesn't catch this
setAlpha(2.3) // Runtime Error: Invalid Percentage - Typescript doesn't catch this
setAlpha('abc') // Build Error: string instead of number - Typescript does catch this

In classical Javascript fashion, one would usually say "add a runtime check." We could do that, but before Typescript, we would also create runtime checks to confirm that data was a number in the first place.

What if we could do the same for this case? It would make sense to try to add type checking for percentages as well since that would catch the types of errors mentioned above during compile-time.

Ideally, we want to just specify that our function only accepts a percentage as its input:

function setAlpha(percentage: Percentage) { ... }

But how do we create a Percentage type?

Defining a New Type

One may think of aliasing as creating a new type (i.e. type Percentage = number), but that merely gives a new name to an existing type. The problem with an aliased type is that it's purely descriptive rather than a functional change (i.e. it's interchangeable with the original type).

const value: number = 1.5 // Invalid `Percentage`
setAlpha(value) // Works even though setAlpha expects `Percentage`

What we want to do is to create a new opaque type (also known as a tagged / branded type). Other type systems, like Flow, already have this ability built in, but Typescript does not.

Instead, to achieve something similar, we can 'tag' the type to indicate that it's different from the base type (in this case a number):

type Percentage = number & { _tag: 'percentage' }

By intersecting number with a unique object, we prevent the type that we have defined from accepting any value that satisfies the base type. In this case, a generic number would not be accepted in functions that expect a Percentage:

const value: number = 0.5 // Valid `Percentage`, but typed as a general `number`
setAlpha(value) // Build Error: number instead of Percentage

Typescript playground example

However, you may now wonder how do you define a variable as a Percentage type. The simple method is to explicitly cast the value with the as keyword:

const value = 0.5 as Percentage

The downside is that this is only reasonable for constants specified at compile-time, what about runtime values?

Conversion Functions

We can solve this issue by creating runtime checks as functions that refine types appropriately:

function isPercentage(input: number): input is Percentage {
  return input >= 0 && input <= 1
}

The is keyword indicates to Typescript that if this function returns true, then the input is a Percentage type (known as a type predicate). You can then use this runtime check function to create a set of conversion functions:

function toPercentage(input: number): Percentage | null {
  return isPercentage(input) ? input : null
}

function fromPercentage(input: Percentage): number {
  return input
}

You can now use these functions throughout your codebase if you need runtime checks for data. Then you'll get the benefits of compile-time checks for functions that you defined that require these specific values.

Does this actually help?

For smaller applications, this level of type granularity is likely not particularly useful. However, as an application grows in complexity, compile-time type checking can seriously help prevent bugs related from misunderstanding the intention behind code (imagine looking at your own code from 6 months ago...).

Let's take our setAlpha example from above:

function setAlpha(percentage: number) { ... }

It may seem obvious from the naming that this should be a value from 0 to 1, but consider potentially a value between 0% and 100%. I can understand someone thinking that setAlpha(20) is a reasonable use of the function. Only at runtime will we realize that something is wrong.

To further this problem, as your application gets even more complicated, you may not immediately notice the error during runtime. Only at a later time when you've forgotten about writing this could the issue pop up again unexpectedly.

By changing the type of the percentage parameter, we can enforce better compile-time type-checking in order to catch these issues earlier on. Now if we defined setAlpha with the more refined type:

function setAlpha(percentage: Percentage) { ... }

Then we can get appropriate errors at compile-time when you try to pass in a generic number into the function. It will require either an explicit casting, or an assertion using our isPercentage function in order to make sure the type is correct.

This has the great benefit of allowing you to use the runtime check once for user input, and then have a compile-time guarantee for the data as it's passed through the system. Like so:

// User input is a string from a text field
const percentage = parseFloat(userInput) // type: number
if (!isPercentage(percentage)) {
  // percentage is not of type `Percentage` and is therefore
  // and invalid input. Handle appropriate error code here.
  return
}

// percentage is type `Percentage` and has compile-time checking
// to confirm that it works with the `setAlpha` function
setAlpha(percentage)

If you were to take the same example, and remove the check for percentage's type, then you'd get a compile-time error from Typescript regarding the use of number for a parameter that requires a Percentage (Typescript playground example).

Opaque Type Variations

Now that we've hopefully determined that this is generally a good idea, let's take it up a notch with some additional variations of opaque types. All credit to ProdigySim on Github for figuring this out.

For the simplification of defining opaqueness, let's define a simple helper type:

type Tag<T> = { _tag: T }

Weak Opaque Type

This is the opaque type we've been talking about here with Percentage. It's uses the same definition as above (though cleaned up using the helper type this time):

type Percentage = number & Tag<'percentage'>

This weak opaque type is useful because it can be downcasted into the base type of number in cases like passing it into a function while protecting from the incorrect use of number in cases where we need a Percentage. For example:

function add(number): number
function setAlpha(Percentage): void

const num = 0.5 as number
const per = 0.5 as Percentage

add(num) // Works: number = number
add(per) // Works: Percentage downcasts to number

setAlpha(num) // Error: Cannot use a number when it expects a Percentage
setAlpha(per) // Works: Percentage = Percentage

Strong Opaque Type

A strong opaque type is defined a little bit differently:

type Percentage = (number & Tag<'percentage'>) | Tag<'percentage'>

Key difference is the addition of | Tag<"percentage"> at the end.

Strong opaque types have the additional restriction of requiring explicit casting in order to be used as their base types (number in this example). This means that we wouldn't be able to pass a Percentage into the add function above without explicitly casting it first:

function add(number): number
const per = 0.5 as Percentage

add(per) // Error: Percentage is incompatible with number
add(per as number) // Works: Percentage explicitly casted to number

This can be useful in cases where you don't accidentally want to use the more specific type for more general cases without a clear exception being made via explicit casting.

Super Opaque Type

A super opaque type has the simplest definition of them all:

type Percentage = Tag<'percentage'>

Super opaque types have the most stringent typings and cannot be implicitly or explicitly casted to their base types. This means that we need to cast the type to any first before we can cast it to the base type for use:

function add(number): number
const per = 0.5 as Percentage

add(per) // Error: Percentage is incompatible with number
add(per as number) // Error: Percentage does not sufficiently overlap number
add(per as any as number) // Works: Ignoring the inherent types to allow Percentage to be used in place of number

This is useful for cases where you are truly making a new type that is unrelated any base type. This is like comparing number to string.

Note: Super Opaque Type boils down to just typing the data as an object with a special key, thus this can cause unexpected edge-cases when functions accept any object.

Defining Opaque Helper Types

From these different opaque types, we can define some simple helper types that reflect the different ways we can define an opaque type within Typescript:

type Tag<T> = { _tag: T }
type WeakOpaqueType<BaseType, T> = BaseType & Tag<T>
type StrongOpaqueType<BaseType, T> = (BaseType & Tag<T>) | Tag<T>
type SuperOpaqueType<T> = Tag<T>

You can copy and use these helper types within your own code in order to begin defining your own custom types. Good luck!

3rd Party Libraries

Now you may be wondering if there are any prebuilt solutions for you to use within your code. I'm happy to say that there is! One notable library I've come across is taghiro. It defines several numeric and string types (like UUID, ascii, and regex) with corresponding validation functions to allow for assertions within your code that refines the types appropriately.

Something to note from the library is that all of the exported types are super opaque types while all of the assertions refine into weak opaque types.

Note: I’m not connected to development of taghiro. Use at your own risk.

React Re-Mounting vs. Re-Rendering

Tiago Ferreira — Fri, 06 Nov 2020 17:35:00 +0000

What would the following lines of code do when React is rendering a component? Would they cause Counter to get re-mounted or re-rendered?

// 'name' is a variable that is either "A" or "B"

// Passing in the name as a prop
<Counter name={name} />

// Ternary expression with two written cases of Counter
{name === "A" ? <Counter name="A" /> : <Counter name="B" />}

// Ternary expression with a Counter and a different element
{name === "A" ? <Counter name="A" /> : <p>EMPTY</p>}

If you said that the first two will re-render Counter while the third will cause a re-mount, then you are correct! You can verify this for yourself with this codesandbox link. The "Basic" section shows all three cases mentioned above.

The Basic Case

To provide some context on Counter, it's a simple component that holds an internal count (with the useState hook) for the number of times it has been pressed:

const Counter = (props) => {
  const [count, setCount] = useState(0)
  const increment = () => setCount(count + 1)

  return (
    <>
      <button onClick={increment}>{props.name}</button>
      <p>{count}</p>
    </>
  )
}

From this component, the most basic use case would simply be passing in the name as a prop as follows:

// Passing in the name as a prop
<Counter name={name} />

This is probably the most common and intuitive case. When React receives new props for a component, it will re-render the component. This results in any internal useState hooks maintaining their internal data – which in our case means the count remains the same.

The Unintuitive Re-Render Case

The next case is less intuitive:

// Ternary expression with two written cases of Counter
{name === "A" ? <Counter name="A" /> : <Counter name="B" />}

At first glance, there appears to be two separate components that are being used in order to render counters; each counter associated with a different name. This could lead one to believe that both counters will go through a mount and unmount process when switching between them. However, that is not the case.

Since these are both the same component type, React actually sees this as identical to the first case. Under the hood, React uses a Virtual DOM reconciler based on a Fiber Architecture that determines how to update components (re-rendering, mounting, unmounting, etc). This reconciler uses the type of the component and the props in order to determine what lifecycle operations to take. In this case, both branches of the ternary use the same component type, but different props. This causes the reconciler to re-render the component and simply change the props passed in.

Why is this important?

"Of course this case is the same! The code is functionally equivalent! Why are you telling me this?"
- someone who's too impatient to continue reading

Consider an application with tabs. You may have the same components that stay within the same locations across tabs. Since the components line up within the Virtual DOM hierarchy between tab transitions, this can unexpectedly cause the same re-rendering behavior to occur.

The Intuitive Re-Mount Case

// Ternary expression with a Counter and a different element
{name === "A" ? <Counter name="A" /> : <p>EMPTY</p>}

Alright, back to the intuitive. To tie it all together, the reason why this case re-mounts is quite simply due to the change in component types. On the left branch we have a Counter component while on the right branch we have a p element. As mentioned above, React's reconciler uses these component types in order to determine what operations to take. Since the types are different when you switch branches, it will unmount the component that was mounted and mount the component that was unmounted.

This unmounting process throws away any data saved within the component's state. Likewise, the mounting process causes component state to initialize with default values (e.g. the initial value passed into a useState hook). This is what causes our count state to reset to 0 whenever switching between branches.

What do I do with this information?

Well, there are a few real world cases where you may want to specifically have re-rendering or re-mounting behavior. Let's continue to use the Counter component and build upon it.

Replicating Re-Mounting

Let's say that we have a web app that allows you to manage multiple users. Each of these users has a Counter component and allows you to save their respective counts. You may write the user component like:

const User = (props) => {
    ...
  return (
    <>
      <Counter name={props.name} />
            ...
    </>
  )
}

And with this User component, you set up a tabs component that shows one user at a time.

The problem that will occur here is that the Counter component's state won't reset between users. This means that when you switch between the tabs, the count will stay the same and you may accidentally save the wrong count for a given user. Extrapolating this out from a simple counter, your app may cause you to save sensitive data to the wrong user – which is a severe breach of security.

So, "how do I fix this?"

Well, the solution is a useEffect hook. We want to listen for changes to props within the Counter component in order to reset the state manually ourselves:

const Counter = (props) => {
  const [count, setCount] = useState(0)
  const increment = () => setCount(count + 1)

    useEffect(() => {
        setCount(0)
    }, [props.name])

  ...

All that we've added here is a simple useEffect hook that runs every time the name prop changes for the component. This causes the internal count to get reset and our 'sensitive' data to avoid leaking into other users.

You can confirm this for yourself by heading to the same codesandbox link as before and checking out the "Replicating Re-Mounting" section. Although it is defined the exact same way as the first case from the "Basic" section, it acts most similarly to the third case with its re-mounting.

Replicating Re-Rendering

Ok, now let's take the original Counter component in a different route. This time, let's assume that we have a Counter that only exists on one tab out of many. We may want to replicate the re-rendering functionality in order to save data when you switch back-and-forth between tabs. That way, as a user, you can work in multiple tabs without losing any data.

What I've described is basically caching the data outside of the component's state in order to prevent it from resetting. You can approach this with a variety of methods: from Redux, to React Context, to a simple cache object external from the component.

For our example, we'll do a simple cache just to show the basics. To start, we want to define a cache for us to use and a way for us to update that cache:

const cache = {}
const Counter = (props) => {
    const [count, setCount] = useState(cache[props.name] ?? 0)
    const increment = () => setCount(count + 1)
  ...

Now we want a way to update the cache when the component’s name prop changes (so that we cache data for each user):

const cache = {}
const Counter = (props) => {
    const [count, setCount] = useState(cache[props.name] ?? 0)
    const increment = () => setCount(count + 1)

    useEffect(() => {
    setCount(cache[props.name] ?? 0)

    return () => {
      cache[props.name] = count
    };
  }, [props.name])

    ...

This useEffect will also run during mount and likewise the cleanup function will run during unmount.

But wait! This code has a problem. When the cleanup function is created, count is captured within a closure and it’ll save the wrong data into the cache. If we try to fix this by adding count as a dependency for the hook, then it’ll cause the page to crash due to a circular reference.

To solve this issue, we can use the useRef hook in order to use its mutative current field:

const cache = {}
const Counter = (props) => {
    const [count, setCount] = useState(cache[props.name] ?? 0)
    const countRef = useRef(count)
    const increment = () => {
    setCount(count + 1)
    countRef.current++
  }

    useEffect(() => {
    setCount(cache[props.name] ?? 0)
        countRef.current = cache[props.name] ?? 0

    return () => {
      cache[props.name] = countRef.current
    };
  }, [props.name])

    ...

Now the cleanup function for the useEffect will always use the most up-to-date data for count when setting the cache's value. This is the approach used within the codesandbox link from before for the "Replicating Re-Rendering" section.

Wrapping Up

This post was born from the mistakes that my colleagues and I have made in the past. I hope this has helped you understand React a little better and I welcome you to share anything you've learned from prior mistakes!

Finally, if you've noticed any issues above, please let me know.