[Ricky Hanlon posted on Bluesky](https://bsky.app/profile/ricky.fm/post/3lpi3jj3jqc2s):

> what's wrong with this code:
>
> ```jsx
> if (props.wrap) {
> 	return <Wrapper>{children}</Wrapper>
> }
>
> return children
> ```

A lot of people didn't get it right away. In fact, it took me a moment thinking
about it as well, but then
[I replied](https://bsky.app/profile/kentcdodds.com/post/3lpi4rbteqs2g):

> Does it have to do with what happens when the wrap prop changes?

He said "Yes" and I knew for sure what he was talking about.

Have you ever wondered why your React component's state sometimes disappears or
resets unexpectedly? Or why two identical components don't share state? React's
approach to state is all about _where_ a component sits in the UI tree, not just
what it is. This means that state is preserved as long as the same component is
rendered at the same position—but if you swap components, change their keys, or
move them around, React may reset their state.

A common pitfall: toggling between two components (like two players in a
scoreboard) using different keys or types will reset their state every time you
switch. This is often _not_ what you want, especially if you expect the UI to
"remember" previous input or progress. The React docs show how this can trip you
up, and why relying on position and keys for state can be sub-optimal if you're
not careful.

If you've ever been surprised by disappearing form input or state that doesn't
persist the way you expect, this article is for you. It covers:

- How React decides when to preserve or reset state
- The role of keys and component types
- Practical tips for controlling state resets (and when you might want them!)

Curious to learn more and see code examples? Check out the full article:
[Preserving and Resetting State – React Docs](https://react.dev/learn/preserving-and-resetting-state)

### Spoiler Alert: How to Fix It

For Ricky's example specifically, if you want to preserve state while toggling
the wrapper, you need to ensure the component tree structure remains stable. One
way is to always render the `Wrapper`, but conditionally apply styling or
behavior:

```jsx
return (
	<Wrapper style={props.wrap ? {} : { display: 'contents' }}>
		{children}
	</Wrapper>
)
```

Or, if you want to avoid an extra DOM node when not wrapping, you can use a key
to intentionally reset state, or lift state up to a parent component so it isn't
lost when the tree changes. The key is to avoid swapping between two different
component trees at the same position if you want to preserve state.

But really, you should just read
[the whole article](https://react.dev/learn/preserving-and-resetting-state).


How React preserves or resets state depends on component position and keys. Learn why state disappears and how to fix it as well as links to more resources!

Preserving and Resetting State in React

At the end of a long day when the lights are out and I lie down in bed ready to fall into a blissful sleep, sometimes my wife will remind me that I forgot to lock the back door. When this happens, for some reason I often decide (irrationally) to take a chance in the darkness rather than turn on my phone's flashlight. Maybe it's because I like living on the edge. Maybe I'm not thinking. Whatever the reason, doing this is... dangerous.

It's dangerous because I have four children and a dog who's as black as night. If I'm lucky, I'll return to the sanctuary of my bed unscathed with nothing more than an increased heart rate (what a rush!). But often I'll also have stepped on some toys, kicked a door frame, bumped into the banister, and on really unfortunate nights, stepped on my snoozing dog (sorry Gemma!).

Learning can be a lot like stumbling around in the darkness. Except not only is there no illumination to guide you, you're also in someone else's house and their kids are less clean than yours and their dogs are darker and less forgiving than yours. Sound terrifying? If you've ever learned something new, you know it is.

The big problem is you don't know what you don't know. This means you don't know what to look for. You try something and it "works" but you don't know why it works or whether there's a better or easier (less painful) way to do it. You're trying to lock the back door and you walk around the couch 8 times because you're not sure whether there's a more direct route to get there. If you're lucky, you've got other co-workers alongside you.

If you're really lucky they've done this before and can guide you along. But more often they're either too busy or they're just as inexperienced as you are and all they can do is hold your hand and tell you "it's going to be ok." While this is appreciated, it's not directly helpful.

When you're learning something new, you're stumbling in the sea of things you don't know you don't know. Perhaps you've cobbled together API docs from here, a tutorial from there, an online course from way over there, and a tweet or two from back there. You attempt to piece those things together in your mind to try to give you something that resembles knowledge and experience, but often you'll find you've tried to shove a round peg in a square hole. There's no cohesion. And in your rush to create a candle to light your way, you've forgotten the wick.

The other day I tweeted this:

https://twitter.com/kentcdodds/status/1310042224600649729

I had several people make the suggestion that "learning isn't suffering." I actually agree with this. "Suffering" is the wrong word for what learning **should be**. Learning **is** a struggle, but it **should be** guided struggle where you are presented with problems, but also the right tools and information you need to identify and implement the solution.

Far too many online courses posing as "learning resources" completely take away that struggle. They sit you in a high chair and attempt to spoon feed you knowledge. Unfortunately, leaving out the struggle is basically like forgetting to put food on the spoon 🥄. All the movements are there, but none of the sustenance. They show you the happy path of what you're trying to do and leave you to fend for yourself on error messages (or worse, silent errors) only to later realize that the solution they've given you won't work for the problem you're facing.

There's different kind of struggles though. There's the struggle of working through a problem with a solution that you've been guided into by experience. This first kind of struggle is what creates retention so you can use that as a gained skill later. And then there's the struggle of hitting a wall on some unrelated problem that's simply a road block to what you're really trying to learn.

Maybe you haven't experienced the first, but you've probably experienced the second. That wall-hitting struggle is so often (and unfortunately) unavoidable. Eventually you'll bust down that wall and you'll leave victorious with knowledge of how to bust down that wall in the future, but the victory is hollow because you'll never hit that wall again anyway. It's a side-quest with all the challenge, but none of the reward. Maybe it's fun in the moment, but when you're done your product is not shipped and your manager is not sure you deserve the raise you asked for.

Another struggle involves the struggle of "holding it wrong" or "using the wrong tool for the job." This often comes from learning about the tools that are available, but not learning how the tools work, how they should be used, what problems they're intended to solve, and (just as important) what problems they're _not_ intended to solve. For example, maybe you heard once that using `React.useCallback`, `React.useMemo`, and `React.memo` will improve performance, so you start applying those tools everywhere. And now you're struggling because your code is more complex than it needs to be and in the back of your mind you're worried about that one time the component didn't re-render when it should have.

Learning _can be_ suffering if you're doing the wrong kind of struggling. Stumbling around in the learning darkness is not fun or productive. It's frustrating and far too many people give up completely when that's their experience when struggling to learn.

But there's a way to avoid suffering when learning: **Have a complete and cohesive guide that provides the right kind of struggle and a support system to help you avoid the wrong kind.**

This is [EpicReact.Dev](https://epicreact.dev)

It's not a candle. It's a freaking spotlight.

EpicReact is not just a "happy path" video course that will leave you with all the pieces, no instructions, and no support telephone number. EpicReact is a series of workshops that shows you the tools you can use, how to use them, and gives you experience with the right kind of struggle. The kind that helps you side-step distracting and wasteful side-quests and promotes the reward bearing ones. The kind of struggle that requires work on your part, but work that gives you actual learning retention. It's the kind of struggle that gives you a support system for those times when you're really stuck and things aren't quite clicking for you.

Stop stumbling around in React learning darkness. I've got a spotlight for you so you don't step on any legos or poor innocent dogs. I'm excited to give you the _right_ kind of learning struggle on [EpicReact.Dev](https://epicreact.dev).

Epic React is your learning spotlight so you can ship harder, better, faster, stronger.

Stop Stumbling Around in React Learning Darkness

Here’s a simple React component:

```tsx
type User = { firstName: string; lastName: string }

function UserCard(props: { user: User }) {
	return (
		<div className="user-card">
			<h2>
				{props.user.firstName} {props.user.lastName}
			</h2>
		</div>
	)
}
```

Now, let’s say the boss asks you to please lowercase the user’s name. There are a few ways we could go about doing this, but it begs the question, could we just modify the props?

```tsx
type User = { firstName: string; lastName: string }

function UserCard(props: { user: User }) {
	props.user.firstName = props.user.firstName.toLowerCase()
	props.user.lastName = props.user.lastName.toLowerCase()

	return (
		<div className="user-card">
			<h2>
				{props.user.firstName} {props.user.lastName}
			</h2>
		</div>
	)
}
```

Technically, yes, this will correctly lowercase the user’s first and last name, however, we need to talk about encapsulation.

Encapsulation is a very important concept in programming. It is the idea that separate components are isolated from one another. In React, this allows the components to be reusable. The parent component doesn't need to understand the implementation details of the component it renders because of this isolation. And the component itself doesn't need to know about the parent component.

However, if the props passed down to the parent component are modified, this breaks that encapsulation and can present surprises. For example:

```tsx
type User = { firstName: string; lastName: string }

function UserCard(props: { user: User }) {
	props.user.firstName = props.user.firstName.toLowerCase()
	props.user.lastName = props.user.lastName.toLowerCase()

	return (
		<div className="user-card">
			<h2>
				{props.user.firstName} {props.user.lastName}
			</h2>
		</div>
	)
}

function App() {
	const user = { firstName: 'Bob', lastName: 'Jones' }

	return (
		<div>
			<UserCard user={user} />
			<button onClick={() => alert(`Hello, ${user.firstName}!`)}>Greet</button>
		</div>
	)
}
```

When you click the button, you’ll get `Hello, bob`. This is surprising behavior if you don’t know what the `UserCard` component is doing.

Now, we could avoid this if we do things a little differently here. How about instead of passing the user object, we pass the `firstName` and `lastName` properties directly? We could do `<UserCard firstName={user.firstName} lastName={user.lastName} />` or even just `{...user}` which is effectively the same thing.

```tsx
function UserCard(props: { firstName: string; lastName: string }) {
	props.firstName = props.firstName.toLowerCase()
	props.lastName = props.lastName.toLowerCase()

	return (
		<div className="user-card">
			<h2>
				{props.firstName} {props.lastName}
			</h2>
		</div>
	)
}

function App() {
	const user = { firstName: 'Bob', lastName: 'Jones' }

	return (
		<div>
			<UserCard {...user} />
			<button onClick={() => alert(`Hello, ${user.firstName}!`)}>Greet</button>
		</div>
	)
}
```

This will not suffer from the same issue, but we’ll get an error from React:

```
TypeError: Cannot assign to read only property 'firstName' of object '#<Object>'
```

This is because the props object React passes to your component has read only properties (using [Object.defineProperties](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperties)). This is React helping us avoid breaking encapsulation. By modifying props it reduces our confidence in the one-way data flow. It’s not a big issue with the way we’re doing things here, but what if we did something like this:

```tsx
function UserCard(props: { firstName: string; lastName: string }) {
	return (
		<div className="user-card">
			<h2>
				{props.firstName} {props.lastName}
			</h2>
			<button
				onClick={() => {
					props.firstName = props.firstName.toLowerCase()
					props.lastName = props.lastName.toLowerCase()
				}}
			>
				lowercase them
			</button>
		</div>
	)
}
```

What’s supposed to happen in the `onClick`? Presumably we want the UI to show the names as lower cased, but that wouldn’t happen because in React mutation is not a mechanism for re-rendering. This is one of my favorite parts of React honestly, but I digress.

So, React isn’t allowing us to modify the props, and modifying properties of an object passed through props can lead to issues as well. So what can we do? Well, here’s something we could do:

```tsx
function UserCard(props: { firstName: string; lastName: string }) {
	const lowerFirstName = props.firstName.toLowerCase()
	const lowerLastName = props.lastName.toLowerCase()

	return (
		<div className="user-card">
			<h2>
				{lowerFirstName} {lowerLastName}
			</h2>
		</div>
	)
}
```

That works fine. Or you could also just inline it:

```tsx
function UserCard(props: { firstName: string; lastName: string }) {
	return (
		<div className="user-card">
			<h2>
				{props.firstName.toLowerCase()} {props.lastName.toLowerCase()}
			</h2>
		</div>
	)
}
```

Or, you could even do this:

```tsx

function UserCard({
	firstName,
	lastName,
}: {
	firstName: string
	lastName: string
}) {
	firstName = firstName.toLowerCase()
	lastName = lastName.toLowerCase()

	return (
		<div className="user-card">
			<h2>
				{firstName} {lastName}
			</h2>
		</div>
	)
}
```

Now this last one might have you surprised a bit. We’re destructuring the props, but then we’re reassigning them. How is this different from modifying props? It’s different because we’re not actually changing the values on the props object, we’re simply reassigning the variables we made in the process of destructuring.

I find myself doing this occasionally if I don’t want to bother creating and naming a separate variable and I have no need of the original value. And because it’s a variable reassignment rather than an object mutation, it doesn’t suffer from the problem React is trying to protect us against.

So there you are. This is why React doesn’t allow you to mutate props and why you should try. In general, there are only a few situations where you would consider mutation in a React application (I’m looking at you `useRef` 👀). For the most part, rely on React’s single-way data flow and explicit state updates through `setState` via `useState` and `dispatch` via `useReducer` and you’ll find the data flow in your application is much simpler to follow.

Cheers!

Why encapsulation is important and how handle props so your components remain reusable and your application's data flow stays predictable.

React components should not modify props directly. Learn why encapsulation is important and explore different approaches to handle props correctly in React, ensuring your components remain reusable and your application's data flow stays predictable.

Can you modify React Props?

If you've been building for the web for a while, you probably remember the days
when making a page interactive meant sprinkling `<script>` tags throughout your
HTML, hoping everything loaded in the right order, and wrestling with global
variables. If you wanted a dynamic search box or a fancy dropdown, you'd either
write a bunch of jQuery or wire up some custom JavaScript, and then cross your
fingers that it played nicely with your backend-rendered HTML.

Fast forward to today, and React's new Server Components model takes a
completely different approach. Now, you can compose your UI out of both server
and client components, letting each do what it does best. And the best part? You
get to include interactive client components _right in your server-rendered
UI_—no script tag gymnastics required.

Let's dig into why this is such a big deal, and how it works in practice.

## The Old Way: Script Tag Soup

Back in the day, if you wanted a page that showed a list of products (rendered
on the server) and let users filter them with a search box (handled on the
client), you'd end up with something like this:

```html

<input type="search" id="search" />
<ul id="products">
	<li>Product 1</li>
	<li>Product 2</li>
	
</ul>


<script src="/static/search.js"></script>
<script>
	window.initSearch({ selector: 'ul' })
</script>
```

You had to make sure your scripts loaded after the HTML, and that your
JavaScript could find and hook into the right DOM nodes. If you wanted to pass
data from the server to the client, you'd often have to serialize it into a
`<script>` tag or a `data-*` attribute. It worked, but it was fragile and hard
to scale.

## The React Server Components Way: Seamless Composition

With React Server Components (RSCs), you can build your UI as a tree of
components, some of which run on the server (fetching data, rendering markup),
and some of which run on the client (handling interactivity, managing state).
The magic is that you can _compose_ these together—server components can render
client components as children, and everything just works.

Here's what that looks like in practice:

```jsx
// Server component
import { SearchBox } from './search-box.js' // a client component

export default async function ProductList() {
	const products = await fetchProductsFromDatabase()
	return (
		<div>
			<SearchBox>
				<ul>
					{products.map((product) => (
						<li key={product.id}>{product.name}</li>
					))}
				</ul>
			</SearchBox>
		</div>
	)
}
```

The `SearchBox` is a client component—maybe it uses state, effects, or context.
But you can include it directly in your server-rendered UI. No need to wire up
script tags or global variables. React takes care of sending just the code
needed for `SearchBox` to the client, and hydrates it so it's fully interactive.

## Why This Is Awesome

- **No More Script Tag Indirection:** You don't have to manually connect your
  server-rendered HTML to your client-side code. Just compose components.
- **Encapsulation:** Each component (server or client) owns its own data
  fetching, state, and logic. No more prop drilling or global variables just to
  get data where it needs to go.
- **Performance:** Only the interactive bits get sent to the client as
  JavaScript. The rest is just HTML, streamed from the server. Less JS = faster
  loads.
- **Streaming and Suspense:** You can use React's streaming and Suspense
  features to show loading states for slow data, and have parts of your UI load
  in as they're ready. This used to be a nightmare with traditional server
  rendering.

## A Real Example: Ships, Search, and Streaming

In the
[EpicReact.dev Server Components workshop](https://www.epicreact.dev/workshops/react-server-components/intro-to-server-components),
we build a UI that lets users search for spaceships and view details. Here's how
the composition works:

- The **server component** fetches the list of ships and renders the overall
  layout.
- The **client component** handles the search box, managing its own state and
  updating the UI as the user types.
- When the user searches, the server streams back the updated list, and the
  client component stays interactive the whole time.

No script tags. No manual hydration. Just components.

## Juxtaposition: How Far We've Come

Let's compare the two approaches:

| Old Way (Backend Framework)            | React Server Components                  |
| -------------------------------------- | ---------------------------------------- |
| Server renders HTML                    | Server renders UI (as React elements)    |
| Client JS finds DOM nodes              | Client components are included directly  |
| Data passed via script tags or data-\* | Data fetched where it's needed           |
| Manual hydration                       | Automatic hydration of client components |
| Hard to scale, fragile                 | Encapsulated, composable, robust         |

## Bonus: No More Prop Drilling

One of the biggest pain points in React apps has always been prop
drilling—passing data through layers of components just to get it where it's
needed. With RSCs, you can fetch data _right where you need it_ (thanks to async
server components), and you can use platform features like Node's
`AsyncLocalStorage` to avoid prop drilling for global values. (Check out the
[workshop exercise on this](https://www.epicreact.dev/workshops/react-server-components/server-context)
for more.)

## Conclusion

Composing server and client components together is the modern React's
superpower. You get the best of both worlds: fast, data-rich UIs from the
server, and rich interactivity from the client—without the pain of the old days.
If you haven't tried building with React Server Components yet, now's the time.
Your future self (and your users) will thank you.

---

_Want to learn more? Check out the
[EpicReact.dev Server Components workshop](https://www.epicreact.dev/workshops/react-server-components)
for hands-on exercises and deep dives into these concepts._

How React's new model lets you build interactive, data-rich UIs without the pain of old-school script tags and prop drilling.

Composing Server and Client Components: The Modern React's Superpower

I've been riding the CSS-in-JS train for years (I was even a significant contributor to the "movement"). It's awesome. I've never been so productive working with CSS than when I added the power of JavaScript to it.

I'm still a fan of CSS-in-JS, and in recent years, the CSS spec has evolved and improved a lot and modern browsers have too (unfortunately, Internet Explorer is NOT a modern browser in this or any context). Often I'd use a `ThemeProvider` (like those found in emotion), but turns out there aren't a whole lot of advantages to that kind of component for many use cases and there are several disadvantages.

Let's look at a simple example of "Dark Mode" and compare differences in API (developer experience) and performance (user experience). We'll keep the example simple, and in both the before/after, we'll be using emotion's `styled` utility. Keep in mind that with the `ThemeProvider` you can consume the values using the `useTheme` hook, with a styled component, or with the `css` prop. With CSS Variables, you can get the values in your CSS with `var(--css-variable-name)` and in your JavaScript using `getComputedStyle(element).getPropertyValue('--css-variable-name')` (which you really don't need to do...)

Ok, let's look at some code. Here's an approach to using emotion's `ThemeProvider`:

```javascript
import * as React from 'react'
import styled from '@emotion/styled'
import {ThemeProvider} from 'emotion-theming'

const themes = {
  light: {
    colors: {
      primary: 'deeppink',
      background: 'white',
    },
  },
  dark: {
    colors: {
      primary: 'lightpink',
      background: 'black',
    },
  },
}

const PrimaryText = styled.div(({theme}) => ({
  padding: 20,
  color: theme.colors.primary,
  backgroundColor: theme.colors.background,
}))

function ThemeToggler({theme, onClick}) {
  const nextTheme = theme === 'light' ? 'dark' : 'light'

  return (
    <button onClick={() => onClick(nextTheme)}>
      Change to {nextTheme} mode
    </button>
  )
}

function App() {
  const [theme, setTheme] = React.useState('light')
  return (
    <ThemeProvider theme={themes[theme]}>
      <PrimaryText>This text is the primary color</PrimaryText>
      <ThemeToggler
        theme={theme}
        onClick={(nextTheme) => setTheme(nextTheme)}
      />
    </ThemeProvider>
  )
}

export default App
```

What's cool about this is it's "just JavaScript" so you get all the benefits of variables etc. But we're not really doing all that much with this other than passing it around through the ThemeProvider. (To be clear, the way the ThemeProvider works is it uses React's Context API to make the theme accessible to all emotion components without having to pass props all over the place).

Let's compare this with the CSS Variables approach. But before we get to that, I need to mention that there's no "ThemeProvider" for this. Instead, we define the variables in regular CSS that will get applied based on a `data` attribute we apply to the `body`. So here's that css file:

```css
body[data-theme='light'] {
  --colors-primary: deeppink;
  --colors-background: white;
}

body[data-theme='dark'] {
  --colors-primary: lightpink;
  --colors-background: black;
}
```

Alright, so with that, here's the implementation of the exact same UI:

```javascript
import * as React from 'react'
import './css-vars.css'
import styled from '@emotion/styled'

const PrimaryText = styled.div({
  padding: 20,
  color: 'var(--colors-primary)',
  backgroundColor: 'var(--colors-background)',
})

function ThemeToggler() {
  const [theme, setTheme] = React.useState('light')
  const nextTheme = theme === 'light' ? 'dark' : 'light'

  React.useEffect(() => {
    document.body.dataset.theme = theme
  }, [theme])

  return (
    <button onClick={() => setTheme(nextTheme)}>
      Change to {nextTheme} mode
    </button>
  )
}

function App() {
  return (
    <div>
      <PrimaryText>This text is the primary color</PrimaryText>
      <ThemeToggler />
    </div>
  )
}

export default App
```

Let's first compare what it's like to _use_ these values:

```javascript
// ThemeProvider:
const PrimaryText = styled.div(({theme}) => ({
  padding: 20,
  color: theme.colors.primary,
  backgroundColor: theme.colors.background,
}))

// CSS Variables:
const PrimaryText = styled.div({
  padding: 20,
  color: 'var(--colors-primary)',
  backgroundColor: 'var(--colors-background)',
})
```

There's not really much of a difference from a DX (development experience) standpoint here. One point for the CSS Variables approach is not having to create a function that accepts the theme and returning styles (and no need to even learn about that API).

One point for the `ThemeProvider` approach is if you're using TypeScript you could get type safety on your theme... But ummm... [Check this out](https://twitter.com/chochihim/status/1324182272304537600):

```javascript
// src/theme.js
const theme = {
  colors: {
    primary: 'var(--colors-primary)',
    background: 'var(--colors-background)',
  },
}
export {theme}

// anywhere-else.js
import {theme} from 'theme'

const PrimaryText = styled.div({
  padding: 20,
  color: theme.colors.primary,
  backgroundColor: theme.colors.background,
})
```

BOOM. Static typing-friendly.

Either way, that's really the only significant DX difference. Let's consider the UX (user experience) difference. Why don't you play around with it:

<iframe   src="https://codesandbox.io/embed/df90h?view=Editor+%2B+Preview&module=%2Fsrc%2Findex.js"   style={{     width: '100%',     height: '500px',     border: 0,     borderRadius: '5px',     overflow: 'hidden',   }}   title="CSS Variables vs ThemeProvider"   allow="accelerometer; ambient-light-sensor; camera; encrypted-media; geolocation; gyroscope; hid; microphone; midi; payment; usb; vr; xr-spatial-tracking"   sandbox="allow-forms allow-modals allow-popups allow-presentation allow-same-origin allow-scripts" ></iframe>

You'll notice there's not really any observable UX difference, and there's not for this simple example. But why don't you try this with me:

1. pop open the React DevTools Profiler 2. Start a profiling session (click the little circle) 3. Click the toggle button for each 4. Stop the profiling session 5. Compare the two commits

Here's what I see:

**ThemeProvider:**

![Profiling session showing everything rendered](/articles-images/css-variables/theme-provider.png)

**CSS Variables:**

![Profiling session showing only one component rendered](/articles-images/css-variables/css-vars.png)

I don't want you to get hung up on the number of milliseconds to rerender. This isn't a controlled benchmark (we're in React's dev mode for one thing). The thing I want you to consider is how many components needed to re-render for this change. Let's consider the `ThemeProvider` approach first. The main reason for this is the way we've structured our state ([we could restructure things](https://kentcdodds.com/blog/optimize-react-re-renders) and improve it a little bit). But even if we restructured things, when the theme changes, _every_ emotion component needs to be re-rendered to account for the theme change.

Turning to the CSS Variables approach, you'll notice the only component that re-rendered was our `ThemeToggler` component responsible for updating the `body`. And yet the user experience works perfectly! This is the magic behind CSS variables. With the `ThemeProvider` approach, we have to update the styles of every component, and then the browser paints those updates. But with the CSS Variables approach, we update the styles to a single component (the `body`) and then the browser paints those updates. The browser paint should theoretically take the same amount of work on the part of the browser, so the only difference is how much work we're making the browser do to have React re-render all our components and get emotion to update the styles of every component.

This _can_ have negative performance implications as your app grows. Considering the DX isn't objectively better or worse either way, but the UX is quite possibly better with CSS Variables, I feel comfortable recommending CSS Variables over using Context to share a theme like this.

Oh, and consider also that CSS Variables are part of the browser spec and the ThemeProvider isn't. That's another solid point for CSS Variables 😉

This is one standard I'd suggest you embrace.

One last piece of nuance here. What if you not only want to change styles but _also_ want to change component implementations based on the theme? In this case... [YOU CAN DO BOTH](https://twitter.com/sebmarkbage/status/1324097255557767173)! The benefit of doing this is the only components that need to consume the context value are those that need to render differently based on the theme (which is likely a small subset). Most components can use the css variables for styling purposes only, so you'll still get the aforementioned benefits. If you don't _need_ components to render differently based on the theme then I wouldn't bother with this, but if you do, then it's pretty simple to do. There are several ways to accomplish this, I've done one implementation in [the codesandbox](https://codesandbox.io/s/css-variables-vs-themeprovider-df90h?file=/src/both/index.js). Enjoy exploring that.

CSS variables (custom properties) are awesome. Give them a look. Good luck!

How and why you should use CSS variables (custom properties) for theming instead of React context.

Preserving and Resetting State in React

Spoiler Alert: How to Fix It

Get my free 7-part email course on React!

More Articles

Stop Stumbling Around in React Learning Darkness

Can you modify React Props?

Composing Server and Client Components: The Modern React's Superpower

Use CSS Variables instead of React Context