[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

> "Why can't I just use try/catch in my React components?" If you've ever asked
> this, you're not alone! Let's dig into why React error boundaries exist, how
> they work, and why they're not just a fancy try/catch block for your UI.

## The Problem: Errors Happen (and try/catch Isn't Enough)

No matter how careful you are, things will go wrong in your app. Maybe a network
request fails, a typo sneaks in, or a third-party library throws a fit. In plain
JavaScript, you might reach for `try/catch`:

```js
try {
	// Something that could error
	doSomethingDangerous()
} catch (error) {
	// Handle the error
	showErrorToUser(error)
}
```

But in React, things are a bit different. When you write JSX like this:

```jsx
const element = (
	<div>
		<h1>Calculator</h1>
		<Calculator left={1} operator="+" right={2} />
		<Calculator left={1} operator="-" right={2} />
	</div>
)
```

React doesn't actually _call_ your `Calculator` function when it creates this
element. It just creates a description of what should be rendered. The real work
happens later, when React walks the tree and calls your components. That's why
you can't just do this:

```jsx
try {
	const element = (
		<div>
			<h1>Calculator</h1>
			<Calculator left={1} operator="+" right={2} />
			<Calculator left={1} operator="-" right={2} />
		</div>
	)
} catch (error) {
	// This won't catch anything!
}
```

If you try to wrap your JSX in a `try/catch`, you'll only catch errors that
happen during the creation of those elements—not when React actually renders
them. The real errors happen _inside_ your components, during rendering,
effects, or event handlers.

You _could_ do this:

```jsx
function Calculator(props) {
	try {
		// ...render logic
	} catch (error) {
		return <div>Oh no! An error occurred!</div>
	}
}
```

But that's a nightmare to maintain. Imagine adding this boilerplate to every
single component! Plus, it doesn't help with errors that happen deeper in the
tree, or in lifecycle methods, or async code.

## Enter: Error Boundaries

React introduced
[error boundaries](https://react.dev/reference/react/Component#catching-rendering-errors-with-an-error-boundary)
to solve this. An error boundary is a special kind of component that _catches_
errors anywhere in its child component tree, logs those errors, and displays a
fallback UI instead of crashing the whole app.

Here's a minimal error boundary:

```jsx
class ErrorBoundary extends React.Component {
	state = { error: null }
	static getDerivedStateFromError(error) {
		return { error }
	}
	render() {
		if (this.state.error) {
			return this.props.fallback
		}
		return this.props.children
	}
}
```

And you use it like this:

```jsx
<ErrorBoundary fallback={<div>Something went wrong!</div>}>
	<MyComponent />
</ErrorBoundary>
```

Now, if `MyComponent` or anything it renders throws during rendering, React will
show your fallback UI instead of a blank screen.

Right now, only class components can be true error boundaries because they use
the special static method `getDerivedStateFromError`. There's no direct
equivalent in function components (yet!). That's why libraries like
[`react-error-boundary`](https://github.com/bvaughn/react-error-boundary)
exist—they give you a nice API and let you use hooks to interact with error
boundaries.

## But Wait! What About Async Errors?

Error boundaries only catch errors during rendering, (legacy) lifecycle methods,
and constructors. They _don't_ catch errors in event handlers, async code, or
effects. For those, you need to surface the error to React yourself.

Here's how you might do it with
[`react-error-boundary`](https://github.com/bvaughn/react-error-boundary):

```jsx
import { useErrorBoundary } from 'react-error-boundary'

function MyComponent() {
	const { showBoundary } = useErrorBoundary()

	async function handleClick() {
		try {
			await doSomethingAsync()
		} catch (error) {
			showBoundary(error)
		}
	}

	return <button onClick={handleClick}>Do something</button>
}
```

## Localized Error Handling: Like try/catch, But Declarative

You can nest error boundaries anywhere in your component tree, just like you'd
nest try/catch blocks in code. This lets you show different fallback UIs for
different parts of your app:

```jsx
function App() {
	return (
		<div>
			<ErrorBoundary fallback={<div>Something went wrong with the list.</div>}>
				<List />
			</ErrorBoundary>
			<ErrorBoundary
				fallback={<div>Something went wrong with the details.</div>}
			>
				<Details />
			</ErrorBoundary>
		</div>
	)
}
```

## Resetting and Recovering from Errors

Sometimes, errors are temporary. Maybe the user lost their internet connection,
or a form submission failed. With `react-error-boundary`, your fallback
component can offer a "Try again" button:

```jsx
function ErrorFallback({ error, resetErrorBoundary }) {
	return (
		<div role="alert">
			<p>Something went wrong:</p>
			<pre>{error.message}</pre>
			<button onClick={resetErrorBoundary}>Try again</button>
		</div>
	)
}

const element = (
	<ErrorBoundary FallbackComponent={ErrorFallback}>
		<MyComponent />
	</ErrorBoundary>
)
```

## Logging and Analytics

Error boundaries can also help you log errors for analytics or debugging. Use
the `onError` prop with `react-error-boundary`:

```jsx
<ErrorBoundary
	FallbackComponent={ErrorFallback}
	onError={(error, info) => {
		// Send error to your logging service
		logErrorToService(error, info)
	}}
>
	<MyComponent />
</ErrorBoundary>
```

## Conclusion

- Error boundaries are _not_ just try/catch for React—they're a declarative,
  component-based way to handle errors in the UI.
- They only catch errors during rendering, lifecycle methods, and
  constructors—not in event handlers or async code.
- Use libraries like
  [`react-error-boundary`](https://github.com/bvaughn/react-error-boundary) for
  a modern, ergonomic API.
- Place error boundaries thoughtfully to give users the best possible experience
  when things go wrong.

---

Want to learn more? Check out the
[Epic React Fundamentals workshop](https://www.epicreact.dev/workshops/react-fundamentals/intro-to-error-boundaries)
and the
[react-error-boundary docs](https://github.com/bvaughn/react-error-boundary) for
deeper dives and more examples.


A deep dive into how React error boundaries work, why they're different from try/catch, and how to use them effectively in your apps.

Why React Error Boundaries Aren't Just Try/Catch for Components

React 19's ViewTransition component makes it easy to create smooth, animated
transitions between pages. Wrap elements with the same name on different pages
and React handles the rest.

Remember when clicking between pages meant an abrupt jump? Users expect smooth
transitions now, especially after years of polished mobile apps. React's new
`<ViewTransition />` component (available in React 19 Canary) makes it easy to
create those smooth, animated transitions between pages.

## What is ViewTransition?

`<ViewTransition />` is React's componentized way to use the platform's View
Transition API. It lets you animate elements as they move from one page to
another, creating that polished, app-like feel users expect.

The concept is simple: wrap elements you want to transition with
`<ViewTransition />` and give them the same `name` prop. When React navigates
between pages, it automatically animates elements with matching names.

## A Practical Example

Let's say you have a movie catalog. When users click a movie card, they navigate
to the details page. Wouldn't it be nice if the poster image smoothly
transitioned from the card to the details page? That's exactly what
ViewTransition does.

Here's the movie card component:

```tsx
<ViewTransition name={`movie-poster-${movie.id}`}>
	<img
		src={movie.poster}
		alt={`${movie.title} poster`}
		className="mb-4 h-64 w-full rounded-lg object-cover"
	/>
</ViewTransition>
```

And here's the same element on the details page:

```tsx
<ViewTransition name={`movie-poster-${movie.id}`}>
	<img
		src={movie.poster}
		alt={`${movie.title} poster`}
		className="h-96 w-full rounded-lg object-cover"
	/>
</ViewTransition>
```

Notice both use the same `name` prop: `movie-poster-${movie.id}`. This tells
React these are the same element transitioning between pages. When you navigate,
React automatically creates a smooth fade transition between them.

## Multiple Elements

You can transition multiple elements at once. Let's also transition the title:

```tsx
<ViewTransition name={`movie-title-${movie.id}`}>
	<h3 className="rr-heading text-lg font-semibold">{movie.title}</h3>
</ViewTransition>
```

And on the details page:

```tsx
<ViewTransition name={`movie-title-${movie.id}`}>
	<h1 className="rr-heading mb-4 text-3xl font-bold">{movie.title}</h1>
</ViewTransition>
```

Now both the poster and title smoothly transition when navigating between pages.
The browser handles the animation automatically with a default cross-fade, but
you can customize it with CSS if you want.

## Important Details

**Unique names are required**: Each `<ViewTransition />` with the same `name`
must be unique across your entire app. That's why we use
`movie-poster-${movie.id}` instead of just `"movie-poster"`. If two components
with the same name are mounted simultaneously, React will throw an error.

**Works with Transitions**: ViewTransition only activates when wrapped in a
`startTransition` call. Most routers (like React Router) handle this
automatically, but if you're managing navigation manually, make sure to use
`startTransition`.

**Placement matters**: The `<ViewTransition />` component must wrap DOM nodes
directly. It can't be placed after other DOM elements in the same parent.

## Customization

By default, ViewTransition uses a smooth cross-fade animation. But you can
customize it with CSS using view transition pseudo-elements:

```css
::view-transition-old(movie-poster-1) {
	animation-duration: 500ms;
}

::view-transition-new(movie-poster-1) {
	animation-duration: 500ms;
}
```

You can create slide animations, scale effects, or any other CSS animation you
can imagine. The platform's View Transition API is powerful, and React's
component makes it accessible.

## Learn More

ViewTransition is a great example of React making platform APIs more ergonomic.
To dive deeper:

- Check out the
  [React ViewTransition docs](https://react.dev/reference/react/ViewTransition)
  for all the props and options
- Learn about the underlying
  [View Transition API on MDN](https://developer.mozilla.org/en-US/docs/Web/API/ViewTransition)
  for advanced customization

Give ViewTransition a try in your next project. Your users will notice the
difference!


Create smooth, animated page transitions in React 19 with the ViewTransition component. Wrap elements with matching names and React handles the rest.

Use React <ViewTransition /> to Smoothly Transition Images and Titles

Let's say we've got a form that allows you to specify a username. When you try to submit an invalid value, it will show an error message and refocus on the input so you can fix your mistake.

```tsx
import * as React from 'react'

function UsernameForm({
  initialUsername = '',
  onSubmitUsername,
}: {
  initialUsername?: string
  onSubmitUsername: (username: string) => void
}) {
  const [username, setUsername] = React.useState(initialUsername)
  const [touched, setTouched] = React.useState(false)

  const usernameInputRef = React.useRef<HTMLInputElement>(null)

  const usernameIsLowerCase = username === username.toLowerCase()
  const usernameIsLongEnough = username.length >= 3
  const usernameIsShortEnough = username.length <= 10
  const formIsValid =
    usernameIsShortEnough && usernameIsLongEnough && usernameIsLowerCase

  const displayErrorMessage = touched && !formIsValid

  React.useEffect(() => {
    if (displayErrorMessage) usernameInputRef.current?.focus()
  }, [displayErrorMessage])

  let errorMessage = null
  if (!usernameIsLowerCase) {
    errorMessage = 'Username must be lower case'
  } else if (!usernameIsLongEnough) {
    errorMessage = 'Username must be at least 3 characters long'
  } else if (!usernameIsShortEnough) {
    errorMessage = 'Username must be no longer than 10 characters'
  }

  function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
    event.preventDefault()
    setTouched(true)
    if (!formIsValid) return

    onSubmitUsername(username)
  }

  function handleChange(event: React.ChangeEvent<HTMLInputElement>) {
    setUsername(event.currentTarget.value)
  }

  function handleBlur() {
    setTouched(true)
  }

  return (
    <form name="usernameForm" onSubmit={handleSubmit} noValidate>
      <div>
        <label htmlFor="usernameInput">Username:</label>
        <input
          ref={usernameInputRef}
          id="usernameInput"
          type="text"
          value={username}
          onChange={handleChange}
          onBlur={handleBlur}
          pattern="[a-z]{3,10}"
          required
          aria-describedby={displayErrorMessage ? 'error-message' : undefined}
        />
      </div>
      {displayErrorMessage ? (
        <div role="alert" className="error-message">
          {errorMessage}
        </div>
      ) : null}
      <button type="submit">Submit</button>
    </form>
  )
}
```

There's a bit going on there, but let's zoom in on the `useEffect`. That's responsible for focusing the input when an error is displayed so the user can fix the problem.

```tsx
React.useEffect(() => {
  if (displayErrorMessage) usernameInputRef.current?.focus()
}, [displayErrorMessage])
```

If you know me, you know that [I'm a firm proponent](/myths-about-useeffect) of the `exhaustive-deps` rule from the [`eslint-plugin-react-hooks`](https://www.npmjs.com/package/eslint-plugin-react-hooks) package. So you might wonder why my dependency array doesn't include: `usernameInputRef.current`. Isn't that one of the dependencies of my effect callback? After all, what would happen if that value were to change?

Well, let's try adding it to the array:

```tsx
React.useEffect(() => {
  if (displayErrorMessage) usernameInputRef.current?.focus()
}, [displayErrorMessage, usernameInputRef.current])
```

Ah, we get a lint warning from the `exhuastive-deps` rule:

```
React Hook React.useEffect has an unnecessary dependency: 'usernameInputRef.current'.
Either exclude it or remove the dependency array.
Mutable values like 'usernameInputRef.current' aren't valid dependencies because
mutating them doesn't re-render the component.
eslint(react-hooks/exhaustive-deps)
```

Alright, let's dig into that warning. Remember:

**`useRef` is similar to `useState` except changing the value doesn't trigger a re-render.**

In our example above, we're using `useRef` to keep track of a DOM node, but you can use it to keep track of any value whatsoever, just like `useState` (bet you didn't think about putting a function in `useState` before did you 😉, you totally can though).

The fact that an update the a `ref.current` value doesn't trigger a re-render is an intentional feature. React doesn't keep track of the `current` value of a ref. You're responsible for referencing and mutating that value yourself. Because referencing DOM nodes is such a common use case, React will set the `current` value for you when you pass a `ref` prop to an element. But other than that, all React promises is that it will store your object and associate it to a particular instance of a component for as long as that component exists.

By the way, that's what differentiates a `ref` from just a regular variable outside the component. `useRef` ensures that the value is associated with a particular instance of a component.

Alright, so let's bring this back to the warning. Let's recall the purpose of a dependency array: It's there so React can do something when there are changes in the values provided each time the component renders. And that's the answer right there! React can't know that the value changed if a change doesn't trigger a render! Here's a quick contrived example:

```tsx
function Counter() {
  const countRef = React.useRef(0)

  React.useEffect(() => {
    console.log(countRef.current)
  }, [countRef.current])

  const increment = () => (countRef.current += 1)
  return <button onClick={increment}>Click me</button>
}
```

I can click that button over and over again, but I'm never going to get that `useEffect` callback to run again because there's no re-render associated to the update in the value, I won't get any updated logs!

"_But Kent_" you ask, "_what if I *want* an update to a ref to result in a re-render?_" If that's the case, what you actually want is `useState`/`useReducer`, not `useRef`!

## The rule that governs exceptions to the `exhaustive-deps` rule

So refs are an exception to the `exhaustive-deps` rule, but they're actually not the only exception. The exception itself is general. Here's the general rule for the exception:

**Anything you use in your effect callback that won't trigger a re-render when updated should not go into the dependency array.**

Additionally (and consequentially), you should not expect any change in such values to result in the effect callback getting called. If you _need_ the callback to be called when those things change, then you _need_ to put it in `useState` (or `useReducer`).

This general rule is why if you pass the value of a module-level variable into a dependency array like this you'll get a similar lint warning:

```tsx
let log = console.log

function Comp() {
  React.useEffect(() => {
    log(new Date())
  }, [log]) // <-- 🚨 eslint warning here
  return <div>{/* stuff here */}</div>
}
```

Here's what the linter will tell you about that:

```
React Hook React.useEffect has an unnecessary dependency: 'log'.
Either exclude it or remove the dependency array. Outer scope values like 'log'
aren't valid dependencies because mutating them doesn't re-render the component.
eslint(react-hooks/exhaustive-deps)
```

This is because even if I did reassign that `log` variable to something else at some point, React wouldn't know about it so you'd end up with a stale side-effect anyway. So just don't list it, and if you _do_ want a change to trigger the effect to run, then put it in state!

Same thing happens with imports (with the added benefit of the fact that you can't reassign these values anyway):

```tsx
import log from './logger'

function Comp() {
  React.useEffect(() => {
    log(new Date())
  }, [log]) // <-- 🚨 eslint warning here
  return <div>{/* stuff here */}</div>
}
```

The lint warning for this is actually identical to the variable form.

## Custom hooks and the ref object itself

You won't get a warning with code like this:

```tsx
function Comp() {
  const logRef = React.useRef(console.log)
  React.useEffect(() => {
    logRef.current(new Date())
  }, []) // <-- ✅ No eslint warning here
  return <div>{/* stuff here */}</div>
}
```

That's because you're not using any values in your `useEffect` that the lint plugin knows can change on re-renders.

However, you also won't get a warning with code like this:

```tsx
function Comp() {
  const logRef = React.useRef(console.log)
  React.useEffect(() => {
    logRef.current(new Date())
  }, [logRef]) // <-- ✅ No eslint warning here
  return <div>{/* stuff here */}</div>
}
```

That's because the `logRef` value _can never change_. So it actually makes no difference whether you include it or not and I guess the authors of the lint rule decided to not bother you about something that doesn't matter. Good call.

But here's an interesting case. What about a custom hook that accepts a ref?

```tsx
function useDateCall(cbRef) {
  React.useEffect(() => {
    cbRef.current(new Date())
  }, []) // <-- 🚨 eslint warning here
}

function Comp() {
  const logRef = React.useRef(console.log)
  useDateCall(logRef)
  return <div>{/* stuff here */}</div>
}
```

The warning we get there is:

```
React Hook React.useEffect has a missing dependency: 'cbRef'.
Either include it or remove the dependency array.
eslint(react-hooks/exhaustive-deps)
```

The reason we get the warning there when we didn't get it within the component is because ESLint is pretty limited in its ability to trace what you're doing with your JavaScript. So the React plugin for ESLint can't know that `cbRef` is actually a `ref`. So just to be safe, it warns you.

Luckily, as we just learned, including it in the dependency array doesn't make any difference anyway, so just include it!

```tsx
function useDateCall(cbRef) {
  React.useEffect(() => {
    cbRef.current(new Date())
  }, [cbRef]) // <-- ✅ No eslint warning here
}

function Comp() {
  const logRef = React.useRef(console.log)
  useDateCall(logRef)
  return <div>{/* stuff here */}</div>
}
```

And we're all good.

## Conclusion

So the reason you shouldn't list a ref in your `useEffect` dependency array is because it's an indication that you want the effect callback to re-run when a value is changed, but you're not notifying React when that change happens. So the solution is to either:

1. Not include it in the array 2. Put that value in `useState`/`useReducer` so an update will trigger a render.

Hope that cleared up some confusion for you! Good luck.

If you use a ref in your effect callback, shouldn't it be included in the dependencies? Why refs are a special exception to the rule!

Why you shouldn't put refs in a dependency array

When building React applications, you'll often work with data that only exists
on the client—such as items users add to a list before saving them to a server.
These objects usually don't have a unique ID yet, but you still need one for
things like React keys, form field associations, or other DOM relationships.

## Why You Need Unique IDs

Unique IDs are essential for:

- Rendering lists with stable React keys
- Associating labels with form fields
- Managing focus or accessibility relationships

If your data comes from a backend, it often already has an ID. But for
client-only data, you need to generate one yourself.

Don't generate a new ID on every render! Instead, generate the ID once—when the
object is created—and store it on the object. This ensures the ID stays stable
and unique. You don't necessarily need to use that ID if you end up saving that
object in a database or something, but to help React keep track of the items in
the list, you need to have a unique ID for each item.

### Using the Web Crypto API

The Web Crypto API provides a simple and reliable way to generate unique IDs:

```js
crypto.randomUUID()
```

This function returns a universally unique identifier (UUID) string, which is
perfect for most use cases.

## Example: Adding Items to a List

Here's a React component that lets users add items to a list. Each item gets a
unique ID when it's created:

```jsx
import React, { useState } from 'react'

function generateId() {
	return crypto.randomUUID()
}

function ItemList() {
	const [items, setItems] = useState([])
	const [input, setInput] = useState('')

	function handleAdd() {
		if (!input.trim()) return
		setItems([...items, { id: generateId(), label: input }])
		setInput('')
	}

	return (
		<div>
			<input
				value={input}
				onChange={(e) => setInput(e.target.value)}
				placeholder="Add an item"
			/>
			<button onClick={handleAdd}>Add</button>
			<ul>
				{items.map((item) => (
					<li key={item.id}>{item.label}</li>
				))}
			</ul>
		</div>
	)
}
```

When working with client-only data, it's important to generate unique IDs at the
time you create your objects, rather than generating them on every render. The
Web Crypto API's `crypto.randomUUID()` function provides a reliable way to
generate these unique identifiers. Make sure to store the ID directly on the
object when you create it - this ensures the ID remains stable and can be safely
used for React keys and DOM relationships.

For more on accessibility and unique IDs, check out the related article on
[generating unique IDs in React](/improving-react-accessibility-with-use-id-knljs).

Also check out [Why React Needs a Key Prop](/why-react-needs-a-key-prop) for
more on why you need to use a key prop.


Learn how to generate unique IDs for client-only data in React using the Web Crypto API, ensuring stable keys and accessible, dynamic UI components.

Preserving and Resetting State in React

Spoiler Alert: How to Fix It

Get my free 7-part email course on React!

More Articles

Why React Error Boundaries Aren't Just Try/Catch for Components

Use React <ViewTransition /> to Smoothly Transition Images and Titles

Why you shouldn't put refs in a dependency array

Generating Unique IDs for Client-Only Data in React