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.

Generating Unique IDs for Client-Only Data in React

I've taught React to tens of thousands of developers. Before and after hooks were released. One thing I've observed is people tend to struggle with the `useEffect` hook and there are some common hang-ups for them that I'd like to address here.

## ❌ Lifecycles ❌ ✅ Synchronize Side Effects ✅

The biggest struggle I've observed is developers who have experience with React class components and lifecycle hooks like `constructor`, `componentDidMount`, `componentDidUpdate`, and `componentWillUnmount`. You can definitely map these to function components with hooks, but that's a big mistake. Allow me to illustrate. Here's an example of some fun UI:

![User clicks "Bernedoodle" link and information about a Bernedoodle shows up, then the user clicks "Poodle" and poodle info shows up. Then back to "Bernedoodle", then "Bernese Mountain Dog", then "return to list"](/articles-images/myths-about-useeffect/dogs.gif)

Here's a class component implementation of that `DogInfo` component:

```javascript
class DogInfo extends React.Component {
  controller = null
  state = {dog: null}
  // we'll ignore error/loading states for brevity
  fetchDog() {
    this.controller?.abort()

    this.controller = new AbortController()
    getDog(this.props.dogId, {signal: this.controller.signal}).then(
      (dog) => {
        this.setState({dog})
      },
      (error) => {
        // handle the error
      },
    )
  }
  componentDidMount() {
    this.fetchDog()
  }
  componentDidUpdate(prevProps) {
    // handle the dogId change
    if (prevProps.dogId !== this.props.dogId) {
      this.fetchDog()
    }
  }
  componentWillUnmount() {
    // cancel the request on unmount
    this.controller?.abort()
  }
  render() {
    return <div>{/* render dog's info */}</div>
  }
}
```

That's a pretty standard class component for this type of interaction. It's using the `constructor`, `componentDidMount`, `componentDidUpdate`, and `componentWillUnmount` lifecycle hooks. If we naively mapped those lifecycles to hooks, here's how it might look:

```javascript
function DogInfo({dogId}) {
  const controllerRef = React.useRef(null)
  const [dog, setDog] = React.useState(null)
  function fetchDog() {
    controllerRef.current?.abort()

    controllerRef.current = new AbortController()
    getDog(dogId, {signal: controllerRef.current.signal}).then(
      (d) => setDog(d),
      (error) => {
        // handle the error
      },
    )
  }

  // didMount
  React.useEffect(() => {
    fetchDog()
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, [])

  // didUpdate
  const previousDogId = usePrevious(dogId)
  useUpdate(() => {
    if (previousDogId !== dogId) {
      fetchDog()
    }
  })

  // willUnmount
  React.useEffect(() => {
    return () => {
      controllerRef.current?.abort()
    }
  }, [])

  return <div>{/* render dog's info */}</div>
}

function usePrevious(value) {
  const ref = useRef()
  useEffect(() => {
    ref.current = value
  }, [value])
  return ref.current
}
```

There are still some holdouts on hooks. If this is what I thought hooks meant, then I would be a hooks holdout too.

Here's the crux of the issue: **`useEffect` is _not_ a lifecycle hook. It's a mechanism for synchronizing side effects with the state of your app.**

So, in our example, all we care about is: "When the `dogId` changes, fetch the new dog's information." With that as our goal, `useEffect` becomes _much_ simpler for this case:

```javascript
function DogInfo({dogId}) {
  const [dog, setDog] = React.useState(null)

  React.useEffect(() => {
    const controller = new AbortController()
    getDog(dogId, {signal: controller.signal}).then(
      (d) => setDog(d),
      (error) => {
        // handle the error
      },
    )
    return () => controller.abort()
  }, [dogId])

  return <div>{/* render dog's info */}</div>
}
```

🤯 Oh snap. That's _way_ better right?! When the React team introduced hooks, their goal wasn't to simply add lifecycles to function components. Their goal was to fundamentally improve the mental model for application side-effects. And they did.

Big time.

So remember this gem by [Ryan Florence](https://twitter.com/ryanflorence/status/1125041041063665666):

> The question is not "when does this effect run" the question is "with which > state does this effect synchronize with" > > useEffect(fn) // all state > > useEffect(fn, []) // no state > > useEffect(fn, [these, states])

## I can ignore eslint-plugin-react-hooks/exhaustive-deps ❌

Well, technically you can. And _sometimes_ there's a good reason to. But most of the time it's a bad idea and ignoring that rule will lead to bugs. I see this concern come up often when people say: "But I only want this to run on mount!" Again. That's thinking in lifecycles and is wrong. If your `useEffect` callback has dependencies, then you need to make sure that your effect callback is re-run anytime those dependencies change. Otherwise your side-effects will fall out of sync with the state of the app.

Long story short, you'll have bugs. Don't ignore this rule.

## One giant useEffect ❌

Honestly, I don't see this one a whole lot, but I want to include it just in case. No shame if this is you. It happens.

One of the things I love about `useEffect` over lifecycles is it allows me to _really_ separate concerns. Here's a quick example:

![A geochat app showing location based chat, autoscroll, and unread count in the document title](/articles-images/myths-about-useeffect/geo-chat.gif)

Here's some pseudocode for that demo:

```javascript
class ChatFeed extends React.Component {
  componentDidMount() {
    this.subscribeToFeed()
    this.setDocumentTitle()
    this.subscribeToOnlineStatus()
    this.subscribeToGeoLocation()
  }
  componentWillUnmount() {
    this.unsubscribeFromFeed()
    this.restoreDocumentTitle()
    this.unsubscribeFromOnlineStatus()
    this.unsubscribeFromGeoLocation()
  }
  componentDidUpdate(prevProps, prevState) {
    // ... compare props and re-subscribe etc.
  }
  render() {
    return <div>{/* chat app UI */}</div>
  }
}
```

See those four concerns? They're all mixed up. If we wanted to share that code with anything else, it would be a mess. I mean, render props were awesome, but hooks are _way_ better.

I've seen some people create a monster `useEffect` hook that does all the things:

```javascript
function ChatFeed() {
  React.useEffect(() => {
    // subscribe to feed
    // set document title
    // subscribe to online status
    // subscribe to geo location
    return () => {
      // unsubscribe from feed
      // restore document title
      // unsubscribe from online status
      // unsubscribe from geo location
    }
  })

  return <div>{/* chat app UI */}</div>
}
```

But this makes that individual callback pretty complicated. I'd suggest a different approach. Don't forget that you can separate logical concerns into individual hooks:

```javascript
function ChatFeed() {
  React.useEffect(() => {
    // subscribe to feed
    return () => {
      // unsubscribe from feed
    }
  })

  React.useEffect(() => {
    // set document title
    return () => {
      // restore document title
    }
  })

  React.useEffect(() => {
    // subscribe to online status
    return () => {
      // unsubscribe from online status
    }
  })

  React.useEffect(() => {
    // subscribe to geo location
    return () => {
      // unsubscribe from geo location
    }
  })

  return <div>{/* chat app UI */}</div>
}
```

And with this approach, it's _much_ easier to extract this code into a custom hook for each individual concern if that's what you need or want to do:

```javascript
function ChatFeed() {
  // NOTE: this is pseudo-code,
  // you'd likely need to pass values and assign return values
  useFeedSubscription()
  useDocumentTitle()
  useOnlineStatus()
  useGeoLocation()
  return <div>{/* chat app UI */}</div>
}
```

The self-encapsulation of hooks in general is a huge win. Let's make sure we take advantage of that.

## Needlessly externally defined functions ❌

I've seen this one a few times as well. Let me just give you a before/after:

```javascript
// before. Don't do this!
function DogInfo({dogId}) {
  const [dog, setDog] = React.useState(null)
  const controllerRef = React.useRef(null)

  const fetchDog = React.useCallback((dogId) => {
    controllerRef.current?.abort()
    controllerRef.current = new AbortController()
    return getDog(dogId, {signal: controllerRef.signal}).then(
      (d) => setDog(d),
      (error) => {
        // handle the error
      },
    )
  }, [])

  React.useEffect(() => {
    fetchDog(dogId)
    return () => controller.current?.abort()
  }, [dogId, fetchDog])

  return <div>{/* render dog's info */}</div>
}
```

We already saw how simple the above code can be in our earlier example, but let me show that to you again:

```javascript
function DogInfo({dogId}) {
  const [dog, setDog] = React.useState(null)

  React.useEffect(() => {
    const controller = new AbortController()
    getDog(dogId, {signal: controller.signal}).then(
      (d) => setDog(d),
      (error) => {
        // handle the error
      },
    )
    return () => controller.abort()
  }, [dogId])

  return <div>{/* render dog's info */}</div>
}
```

The specific thing I'm trying to call out here is the idea of defining a function like `fetchDog` outside of the `useEffect` callback. Because it's external, you have to list it in the dependencies array to avoid stale closures. And because of _that_ you also have to memoize it to avoid infinite loops. Oh, and then we had to create a `ref` for our abort controller.

Phew, seems like a lot of work. If you _must_ define a function for your effect to call, then do it _inside_ the effect callback, not outside.

## Conclusion

When Dan Abramov introduced hooks like `useEffect`, he compared React components to atoms and hooks to electrons. They're a pretty low-level primitive, and that's what makes them so powerful. The beauty of this primitive is that nicer abstractions can be built on top of these hooks which is frankly something we struggled with before hooks. Since the release of hooks, we've seen an explosion of innovation and progress of good ideas and libraries built on top of this primitive which ultimately helps us develop better apps.

I love it. And I want to teach you all about these primitives as well as abstractions built on top of them in [EpicReact.Dev](https://epicreact.dev) 🚀 Join me.

Some common mistakes I see people make with useEffect and how to avoid them.

Myths about useEffect

When you click a button in your app, how long does it take for the UI to
respond? If you're waiting for a network request to finish before showing the
result, your users might be left staring at a spinner, wondering if anything
happened at all.

That's where **optimistic UI** comes in. The idea is simple: assume the best,
update the UI immediately, and let the server catch up. If something goes wrong,
you can always roll back. But most of the time, things go right—and your app
feels lightning fast.

React 19 introduced a new hook,
[`useOptimistic`](https://react.dev/reference/react/useOptimistic), that makes
this pattern easier than ever.

## What is `useOptimistic`?

`useOptimistic` is a React Hook that lets you show a different state while an
async action is underway. It's perfect for things like instantly adding a new
item to a list when the user submits a form allowing them to quickly add another
item or even change the list item before it's even actually saved. You can also
give users feedback that their action is being processed and even updating the
UI to show individual parts of progress. For example: "reserving your seat" ->
"creating calendar event" -> "sending invitations" -> "done".

Let's see how it works in practice.

## Examples

### Optimistically Toggling a Like Button

Let's try another example: a "Like" button. When a user clicks it, you want the
count to update right away.

```tsx
import { useState, useOptimistic, startTransition } from 'react'

function LikeButton({ initialCount, sendLike }) {
	const [count, setCount] = useState(initialCount)

	// The update function adds the optimistic delta to the count
	const [optimisticCount, addOptimisticLike] = useOptimistic(
		count,
		(current, delta) => current + delta,
	)

	function handleLike() {
		// Optimistically increment the count
		addOptimisticLike(1)

		// Actually send to the server using the provided async function
		startTransition(async () => {
			await sendLike()
			setCount((c) => c + 1)
		})
	}

	return <button onClick={handleLike}>👍 {optimisticCount}</button>
}
```

The user sees the like count go up immediately, even if the network is slow.

### Adding Comments

Suppose you have a comment section. When a user submits a new comment, you want
it to appear instantly—even before the server responds.

Here's how you might do it with `useOptimistic`:

```tsx
import { useState, useOptimistic, startTransition } from 'react'

function CommentSection({ initialComments, sendComment }) {
	const [comments, setComments] = useState(initialComments)

	// The update function merges the optimistic comment into the list
	const [optimisticComments, addOptimisticComment] = useOptimistic(
		comments,
		(currentComments, newComment) => [
			{ ...newComment, optimistic: true },
			...currentComments,
		],
	)

	async function handleAddComment(text) {
		// Show the comment immediately
		addOptimisticComment({ id: Date.now(), text })

		// Actually send to the server using the provided async function
		startTransition(async () => {
			const savedComment = await sendComment(text)
			setComments((prev) => [{ ...savedComment }, ...prev])
		})
	}

	return (
		<div>
			<form
				action={async (formData) => {
					handleAddComment(formData.get('text'))
				}}
			>
				<input name="text" placeholder="Write a comment..." />
				<button type="submit">Add</button>
			</form>
			<ul>
				{optimisticComments.map((comment) => (
					<li
						key={comment.id}
						className={comment.optimistic ? 'text-gray-500' : ''}
					>
						{comment.text}
					</li>
				))}
			</ul>
		</div>
	)
}
```

Notice how the new comment appears instantly, with a grayed out text, even
before the server responds. If there was an error, then the comment will go away
at the end of the transition (you can show an error message if you want). If
there was no error, then the optimistic comment is still gone at the end of the
transition, but the newly created comment will be in the list of regular
comments (and will no longer be grayed out).

### Booking a Flight

Suppose you want to let users book a flight, and you want to show progress
through multiple steps—like "reserving seat", "processing payment", and "sending
confirmation"—with optimistic UI updates for both the booking state and the
progress message. You can accept all async logic and step messages as props,
making the component flexible and focused on UI state.

```tsx
import { useOptimistic, startTransition } from 'react'
import { reserveSeat, processPayment, sendConfirmation } from './api'

function BookFlight() {
	const [message, setMessage] = useOptimistic('Ready to book')

	async function handleBooking(formData: FormData) {
		setMessage('Reserving seat...')
		await reserveSeat(formData.get('flight'))

		setMessage('Processing payment...')
		await processPayment(formData.get('passenger'))

		setMessage('Sending confirmation...')
		const bookingId = await sendConfirmation(
			formData.get('passenger'),
			formData.get('flight'),
		)

		setMessage('Booking complete! Redirecting...')
		// In a real app, you'd use your routing library here
		console.log(`Redirecting to /booking/${bookingId}`)
	}

	return (
		<form action={handleBooking}>
			<input name="passenger" placeholder="Passenger Name" required />
			<input name="flight" placeholder="Flight Number" required />
			<button type="submit">Book Flight</button>
			<div className="mt-2">
				<strong>Status:</strong> {message}
			</div>
		</form>
	)
}
```

This pattern lets you keep all business logic outside the component, while still
providing a rich, step-by-step optimistic UI experience for your users.

## Why Not Just Use `useState`?

You might wonder: why not just update state directly and hope for the best? The
difference is that `useOptimistic` is designed to work seamlessly with React's
concurrent rendering and transitions. It keeps your UI in sync with the "real"
state, and automatically falls back if the action fails or completes.

Additionally, calling `setState` in a transition does not trigger a re-render
due to the nature of React transitions.

## Tips for Using `useOptimistic`

- **Keep your update function pure.** It should only compute the next optimistic
  state, not cause side effects.
- **Handle errors gracefully.** If the server rejects the action, you may want
  to show an error or roll back the optimistic update.
- **Use with transitions.** Pairing `useOptimistic` with `startTransition`
  ensures your UI stays responsive, even during async work.

## Conclusion

Optimistic UI is one of those little touches that can make your app feel
magical. With `useOptimistic`, React gives you a simple, powerful tool to make
your interfaces feel instant—even when the network isn't.

So next time you're building a form, a like button, or anything that talks to a
server, give `useOptimistic` a try. Your users will thank you.

## Ready to Go Deeper?

If you enjoyed this article and want to master hands-on patterns like
`useOptimistic`, Suspense, and more, join me in the Epic React Suspense
workshop! You'll get practical experience, real-world exercises, and a deeper
understanding of modern React.

[Register for Epic React](https://epicreact.dev/) and take your React skills to
the next level!


Make your React apps feel instant with the new useOptimistic hook from React 19. Improve UX by updating UI immediately while async actions complete.

`useOptimistic` to Make Your App Feel Instant

> "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

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.

Generating Unique IDs for Client-Only Data in React

Why You Need Unique IDs

Using the Web Crypto API

Example: Adding Items to a List

Get my free 7-part email course on React!

More Articles

Myths about useEffect

`useOptimistic` to Make Your App Feel Instant

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

Can you modify React Props?