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

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?

React server components have been stirring up the developer community, and I've noticed a mix of excitement and concern. Some folks are uneasy about the blurred lines between server and client, and the implementation challenges, especially with Next.js. But despite these bumps in the road, I want to tell you why I continue to be optimistic about the future of React Server Components.

## Why React Server Components Matter

For decades, we've grappled with integrating backend logic and front-end interactivity in a seamless way. React server components step in as a remarkable solution to this age-old problem. They allow us to compose server and client code without the usual hassle of switching between models.

The network is what makes web development so tough for the majority of web applications. Remix and other frameworks have done a great job of bridging the network chasm and I've really enjoyed using Remix for the last few years. It completely changed what it felt like to build web apps for me and enabled me to handle more and more use cases on my own with a better user experience.

But bridging the network chasm isn't enough. Ryan Florence's talk ["Mind the Gap"](https://www.youtube.com/watch?v=zqhE-CepH2g) at Big Sky Dev Con last month was a real eye-opener. If you haven't seen it yet, do yourself a favor and [watch it](https://www.youtube.com/watch?v=zqhE-CepH2g). He perfectly illustrates the power of React server components in not only bridging the gap between the backend and the frontend, but **making the network completely disappear**.

## Addressing the Pain Points

It's true that React server components introduce new challenges. These fresh pain points can seem daunting because we're not used to them. But let's not forget that all innovations in software come with their own set of hurdles. What's important to remember is that these pain points won't always be there. With any new technology, this is as tough as it gets, and it can only improve from here.

I have high hopes for Remix and its potential to implement React server components in a way that will alleviate many of the current pain points. The team behind Remix is poised to deliver an exceptional developer and user experience (as they have consistently done over the last decade of development with React).

Yes, there are complexities, especially for framework authors grappling with React server components. It's a tough time to be in their shoes, with all the abstractions that need to be figured out. But for the benefit of framework users, the effort is worthwhile. The goal is clear: to build better user experiences with an amazing developer experience. I'm confident the juice is worth the squeeze.

## The Promise of React Server Components

What stands out with React server components is their ability to seamlessly compose interactions between the client and the server. This is what Ryan described as the elimination of the "network chasm" in both directions. I'm confident that React server components are the future, and we'll look back at these times as the necessary growing pains that led to better solutions.

### Looking Ahead with Optimism

Folks who are using React Server Components right now (most of them are working in Next.js apps) are in the midst of uncertainty, dealing with boilerplate and annoyances. But once we develop the right level of abstractions, we'll be able to create user experiences that are not only better but also easier to build.

I'm super bullish on what Remix is doing. They're on track to do an amazing job, and I can't wait to see it unfold. So, to those of you who are worried about React server components and their impact on the React developer's future, I urge you to share my optimism. Things are only going to get better from here.

## What to do now?

Personally, I think it's worthwhile to learn about React Server Components. There are framework implementations of RSCs currently in frameworks that don't match my sensibilities so I'm not actively using them yet. For now, I'm sticking with Remix/React Router as a phenomenal way to build excellent user experiences on the Web. There are shortcomings with Remix for now for sure, but those will be largely solved by RSCs.

If you've not watched Ryan's other talk at React Conf titled ["Vanilla React"](https://www.youtube.com/live/T8TZQ6k4SLE?si=9-31tLaqqIarAO3K&t=5533), then you should definitely watch that to see what the RSC experience with React Router v7 will be like (it'll be amazing). So stick with Remix/React Router and you'll be well situated to take advantage of RSCs when they're ready. And it'll enable you to build better experiences faster.

Have a nice day, and stay optimistic about the future of web development!

React Server Components are going to improve the way we build web applications in a huge way... Once we nail the abstractions...

React Server Components: The Future of UI

Stop UI tearing in React! useSyncExternalStore safely syncs external data. Get best practices for this advanced hook (like stable functions) at EpicReact.dev.

useSyncExternalStore: Demystified for Practical React Development

When the world moved from React class components and lifecycle methods to React function components and hooks, we left behind a bug that many of us didn't even know was plaguing our class-based codebases. This bug was sneaky, hard to identify and reproduce, and it would pop up in places due to seemingly harmless changes over time. To make matters worse, the situations where it pops up are not always bugs, sometimes it's an intended behavior. So you can't even lint against it.

The bug has to do with the mutability of `this.props`. I'm not talking about _you_ the developer mutating `this.props` (you shouldn't do that). I'm talking about when the parent component re-renders and passes new props, `this.props` suddenly points to completely new values. This is by design. I mean, when your `render` method re-runs due to an update in the props, you don't want to render the old props. You want the latest values so the React elements you return shows the right information.

The problem is actually pretty simple. It typically crops up when you have an event handler or lifecycle method that does something asynchronous. Imagine, you start the async thing, then props change while that is in flight, when your code continues `this.props` has the latest values rather than the values that existed at the time the function started running.

Let's add some clarity to this. I've put together [a little demo](https://react-and-stale-closures.netlify.app) which you can play with below. When you click on the ❤️ button, that'll toggle the liked state, but it has to do an async check to determine whether you're permitted to like/unlike the post. That's hard-coded to take 3 seconds to give you time to experience the problem. The specific use case is irrelevant. What matters more is the fact that `this.props` gets changed from beneath you during that async operation.

So, in the demo below, try this:

1. Click the ❤️ button 2. Before the 3 seconds time is up, change the post selection 3. Observe differences

<ReactAndStaleClosuresDemo />

You should observe that with the broken examples (like "The Old Default with Classes"), the post that's updated is the currently active post.

Here's the code for that post (structured to optimize for minimizing distraction):

```javascript
import * as React from 'react'
import {AppContext} from './provider'
import {canLike} from './utils'
import {PostView} from './post-view'

class Post extends React.Component {
  static contextType = AppContext
  handleLikeClick = async () => {
    if (!(await canLike(this.props.post, this.context.user))) return

    this.context.toggleLike(this.props.post)
  }
  render() {
    return (
      <PostView post={this.props.post} onLikeClick={this.handleLikeClick} />
    )
  }
}

export {Post}
```

The important bit here is the `canLike` utility that takes a while to run. So when you click on ❤️, the code execution "pauses" for a little while before continuing to the `this.context.toggleLike(this.props.post)` call. This means that when you change the active post, `this.props.post` is pointing to the wrong thing and the `toggleLike` call goes to the new post, not the one we were trying to like.

This is easily solved, as demonstrated in the "Simulating The New Default with Classes" example:

```javascript
handleLikeClick = async () => {
  const {post} = this.props
  const {user, toggleLike} = this.context
  if (!(await canLike(post, user))) return

  toggleLike(post)
}
```

Basically, we create a variable for everything our function is going to need before we call the async `canLike` function. That way it doesn't matter what happens with `this.props`, we're always referencing what `this.props.post` was at the time ❤️ was clicked, which is what the user intended.

Oh, and did you notice the other potential bug that the refactor avoided? No? Well you may have noticed that I _also_ destructure `user` and `toggleLike` from `this.context`. This isn't just because I like the convention of destructuring things at the top of the function. It's because if the `toggleLike` function were to change on us during that async call then we may be calling a new version of that function which references a different `user` resulting in that _new_ user liking the post instead of the one who clicked the button.

This bug bit me a few times with class components, so much that I created a convention for myself to always destructure everything I needed from `this.` in a function at the top of the function (like in the solution above).

But wouldn't it be better if we just changed the default? Yup! And that's what hooks did for us!

Here's the code for "The New Default with Hooks" example:

```javascript
import * as React from 'react'
import {useApp} from './provider'
import {canLike} from './utils'
import {PostView} from './post-view'

function Post(props) {
  const {user, toggleLike} = useApp()

  async function handleLikeClick() {
    if (!(await canLike(props.post, user))) return

    toggleLike(props.post)
  }

  return <PostView post={props.post} onLikeClick={handleLikeClick} />
}

export {Post}
```

In this case, we don't need to worry because the `props` our component is called with each render will _never_ change for all functions in the component. This is because each render, all functions are created as brand-new functions. And when a function is created, it grabs a reference to all variables outside of itself and hangs onto it for as long as that function exists.

When a re-render is triggered, a new `props` object is created and passed to our function component. At that time a _brand new_ `handleLikeClick` is created which has reference to the latest version of `props`. But if an old version of that function is still running, it's fine because it still has access to the version of props it was called with to begin with. (If this concept is not sinking in, you can learn more about [how closures work here](https://whatthefork.is/closure)).

One interesting observation is that this example actually has nothing to do with classes vs hooks, but really classes vs function components. But the same could be said of `componentDidMount` vs `useEffect`.

Function components flip the default, and I would argue that it's a good trade that helps us avoid that surreptitious bug.

## Simulate the old default

Just like it's possible to simulate the hooks default behavior with class components, it's possible to simulate the classes default behavior with function components. Here's the code for that example:

```javascript
import * as React from 'react'
import {useApp} from './provider'
import {canLike} from './utils'
import {PostView} from './post-view'

function Post(props) {
  const {user, toggleLike} = useApp()

  const postRef = React.useRef(props.post)
  React.useEffect(() => {
    postRef.current = props.post
  })

  async function handleLikeClick() {
    if (!(await canLike(postRef.current, user))) return

    toggleLike(postRef.current)
  }

  return <PostView post={props.post} onLikeClick={handleLikeClick} />
}

export {Post}
```

Refs allow you to update a value without trigger re-renders. It gives you a similar mutable API to `this.` (when refactoring class components, `useRef` is my go-to for any instance values if I can't simplify things as variables within a single `useEffect`).

Of course, the above example is buggy, so you wouldn't do that. But are there situations where the old default was a good idea? Most certainly! A good example of such a case is a `debounce` function like this one [Yago](https://twitter.com/yagopereiraaz) shared with me during my office hours recently.

Here's a naive implementation of `debounce`:

```javascript
function debounce(fn, delay) {
  let timer
  return (...args) => {
    clearTimeout(timer)
    timer = setTimeout(() => {
      fn(...args)
    }, delay)
  }
}
```

And here's a naive implementation of a `useDebounce` hook:

```javascript
function useDebounce(callback, delay) {
  return debounce(callback, delay)
}
```

Unfortunately, that won't work because you be creating a brand new `debounce`ed version of your function every render which results in the `debounce` `timer` variable being different for each one so the debounce is actually just a `delay` and doesn't actually debounce anything. So let's memoize that:

```javascript
function useDebounce(callback, delay) {
  return React.useMemo(() => debounce(callback, delay), [callback, delay])
}
```

The `callback` and `delay` are required, otherwise you'd end up with a debounce function that can't react to changes in the `delay` and it would always call an old version of the `callback` which would have access to old variables and likely result in bugs.

However, this API means that someone would have to memoize the `callback` otherwise you'd get a new debounce function every render which brings us back to the problem that lead to use memoizing this in the first place:

```javascript
const myFn = React.useCallback(() => {
  // do debounced stuff
}, [vars, i, need])
const debouncedMyFn = useDebounce(myFn, 500)
```

But that's not a great API. This is one situation where the new default as described above doesn't work very well. But we can use refs to get around the problem!

```javascript
function useDebounce(callback, delay) {
  const callbackRef = React.useRef(callback)
  // Why useLayoutEffect? -> https://kcd.im/uselayouteffect
  React.useLayoutEffect(() => {
    callbackRef.current = callback
  })

  return React.useMemo(
    () => debounce((...args) => callbackRef.current(...args), delay),
    [delay],
  )
}
```

Sweet, so now people don't need to worry about memoizing their callback:

```javascript
const myFn = () => {
  // do debounced stuff
}
const debouncedMyFn = useDebounce(myFn, 500)
```

For this kind of use case, we should be safe from the aforementioned bug _and_ we have a nice API to boot. I'm satisfied.

If you're curious of real-world scenarios where people have done this to simulate the old default, we actually build something like this in [EpicReact.Dev's Advanced React Hooks Workshop](https://epicreact.dev/modules/advanced-react-hooks/usecallback-custom-hooks-intro) with a custom `useAsync` hook. Dan Abramov's [`useInterval` blog post](https://overreacted.io/making-setinterval-declarative-with-react-hooks/) does this as well. And [`react-query`](https://react-query.tanstack.com/) does this for your `queryFn`s.

## Conclusion

React made the decision to flip the default from things changing out from under you to relying on closures to preserve the value of variables at the time a function is defined. This helps us avoid non-obvious bugs and instead forces us to confront issues before we ship to production. It can definitely be a little confusing until you have a solid grasp on how closures work. Despite that, this is a good change, and our apps are more bug-free thanks to it. 🚫🐛🚫

The sneaky, surreptitious bug that React saved us from by using closures.

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

Can you modify React Props?

React Server Components: The Future of UI

useSyncExternalStore: Demystified for Practical React Development

How React Uses Closures to Avoid Bugs