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

When building accessible React applications, one of the most common requirements
is to ensure that form fields and their labels are properly associated. This
usually means giving each input a unique `id` and making sure the corresponding
`<label>` uses the same value in its `htmlFor` attribute. But if you've ever
tried to build a reusable form component, you know that generating unique IDs
can be a pain.

Let's talk about why this matters, the problems with common approaches, and how
React's `useId` hook makes it all so much easier.

## Why Unique IDs Matter

Imagine you have a form with several fields:

```jsx
function ContactForm() {
	return (
		<form>
			<label htmlFor="name">Name</label>
			<input id="name" type="text" />
			<label htmlFor="email">Email</label>
			<input id="email" type="email" />
		</form>
	)
}
```

This works fine—until you want to reuse a field component multiple times, or
render a list of fields dynamically. If you hardcode the `id` and then reuse
that component, you end up with duplicate IDs, which is invalid HTML and breaks
accessibility for screen readers.

One easy way to tell whether a label is associated with an input is to click on
the label and see if the input is focused. If it is, then the label is
associated with the input. If it's not, then you've got work to do.

## The Temptation of Random IDs (and Why It's a Trap)

A common workaround is to generate a random string for each field:

```jsx
function Field({ label, ...props }) {
	const id = Math.random().toString(36).slice(2)
	return (
		<div>
			<label htmlFor={id}>{label}</label>
			<input id={id} {...props} />
		</div>
	)
}
```

This seems to work, but it introduces subtle bugs:

- The ID changes on every render, which can confuse screen readers.
- If you're doing server-side rendering (SSR), the IDs generated on the server
  won't match the ones on the client, causing hydration errors.

## Enter `useId`: The React Way

React 18 introduced the `useId` hook to solve this exact problem. It generates a
unique, stable ID for each component instance, and it works seamlessly with SSR.

Here's how you use it:

```jsx
import { useId } from 'react'

function Field({ label, ...props }) {
	const id = useId()
	return (
		<div>
			<label htmlFor={id}>{label}</label>
			<input id={id} {...props} />
		</div>
	)
}
```

Now, every time you render `<Field label="Name" />`, it gets a unique, stable
ID. You can safely use this component multiple times—even in lists or dynamic
forms—without worrying about duplicate IDs or hydration mismatches.

## When _Not_ to Use `useId`

It's important to note that `useId` is only for DOM relationships, like
associating a label with an input. Don't use it for React keys in lists:

```jsx
const key = useId()
// ❌ Don't do this!
return <div key={key}>{item}</div>
```

React keys should come from your data, not from `useId`. The ID from `useId` is
only stable for the lifetime of a component instance, not across renders or data
changes.

## Takeaways

- Unique IDs are essential for accessible forms and DOM relationships.
- Generating IDs manually is error-prone, especially with SSR.
- `useId` gives you a stable, unique ID for each component instance, the React
  way.
- Use `useId` for DOM relationships, not for React keys.

For more, check out the
[official React docs on useId](https://react.dev/reference/react/useId).

You'll learn this and other accessibility tips in the workshops on
[EpicReact.dev](https://www.epicreact.dev).


Learn how React’s useId hook ensures unique, accessible form field IDs, avoids SSR bugs, and improves usability in reusable components. Boost accessibility!

Improving React Accessibility with `useId`

I still remember when I first heard about React. It was January 2014. I was listening to a podcast. Pete Hunt and Jordan Walke were on talking about this framework they created at Facebook with no support for two way data-binding, no built-in HTTP library, no dependency injection, and in place of templates it had this weird XML-like syntax for the UI. And to top it all off, I was listening to it while driving to the first ever ng-conf. I was so hyped on Angular.js that I didn't really give React.js more thought than: "Huh."

However, a few months later I started seeing some of my friends and co-workers try it out and share why they thought it was interesting. They encouraged me to give it a solid shake. I put it off for a while.

I was busy.

I felt like my current tools were good enough.

But finally, I gave it 5 minutes and that was all it took. I instantly knew that React was an upgrade on my current tools. Unfortunately I couldn't just switch my work project from Angular.js to React. But I started working on side-projects and open source libraries with React. I was living two lives. Angular.js expert during the day, React padawan at night.

Eventually I decided I wanted to spend my work time working with React and got a job at PayPal working with React full-time where I was super happy.

So what was it that hooked me on React (no pun intended... hooks weren't a thing back then) so strong? Honestly, it was a few things, but if I had to summarize it to one thing it was this:

**React is simple.**

I didn't say "easy" because it's not easy for everyone ("easy" is relative to each individual). But it _is_ simple. It is simpler than my former tools, and that's what hooked me.

For more on the distinction between easy and simple, watch [Simplicity Matters](https://www.youtube.com/watch?v=rI8tNMsozo0) [Rich Hickey](https://twitter.com/richhickey) which is a fantastic talk.

## What makes React simple?

### Explicit state updates

The fact that React shuns mutation as an API for changing state and instead state updates are explicit function calls was a huge improvement for me. I can't tell you how much time I spent wondering what was causing my state to change incorrectly. My software was complected by the "ease" of state updates.

Yes, if you compare "two-way data binding" in Angular.js to what it takes to wire up a controlled input with React, you'll find Angular.js takes less code. And that demos incredibly well. But I've learned that what "demos" well and what is maintainable in a real-world scenario are not always correlated. React's choice to go with "one-way data flow" was a good one. It is simple, sensible, flexible, and powerful. I don't care how much code I have to write. I care about how much work it takes for me or my co-workers to change that code in the future without causing any bugs.

### JSX over templates

Using JSX syntax (aka `React.createElement` syntax sugar) instead of string templates meant that I could leverage (and improve) my knowledge of the JavaScript language features rather than learning and being limited by template syntax and struggling with the global namespace/registry of Angular.js directives. I spent a lot of time trying to figure out what I messed up in my template. It's a DSL (domain-specific language) with an enormous amount of complexity.

On top of that, all the time I invested in learning that syntax is now wasted. It's completely inapplicable to anything else I work on (even if I had decided to move on to Angular 2 instead of React). However, by using JSX and understanding the basic syntax sugar, I'm able to use what I learn in non-React code all the time.

### Hooks

React hooks weren't available when I started using React, but React hooks is definitely another thing that makes React simple:

- `useState` when you need to manage state.
- `useEffect` when you need to synchronize something outside of React with your   app's state.

There are certainly some things to _familiarize_ yourself about these hooks, and there are some other hooks to help with other use cases, but these things are conceptually simple (again, not necessarily "easy").

My favorite part of hooks is how relatively easy it is to share code in a way that is also simple. To share a chunk of hooks logic between components you apply the same techniques you would when sharing non-hooks code: make a function and call it where you want to use the logic.

On top of that, it's all functions, so you can compose things together. You can combine these hooks into a single custom hook, and then you can combine other custom hooks into yet another custom hook. It's incredibly powerful and doing it is also still simple. For more on this, watch [Custom Hooks in React: The Ultimate UI Abstraction Layer](https://www.youtube.com/watch?v=J-g9ZJha8FE) by [Tanner Linsley](https://twitter.com/tannerlinsley).

### React for everything

I had great success using React to build applications used by millions of PayPal users all over the world. I love it for that scale. And what's awesome about React is that it's not limited to Facebook-scale problems. I've used it successfully to handle my small side-projects to great success. So another thing I love about React and its simplicity is how well it handles challenges, whatever the scale. I recently had a side-project I needed built fast and I was able to build the whole thing in a single `index.html` file using [this approach](https://kentcdodds.com/blog/super-simple-start-to-react). No tooling necessary.

On top of that, React also supports really any platform with a UI. React Native, React VR, even interactive CLIs with Ink. React's simple component-based model and the power of hooks can reach anywhere. Big or small.

Once you learn React, you can build UIs anywhere.

## Community

Aside from the simplicity of the framework, another thing that I love about React is that by any metric, it's the most popular and widely used tool for building frontend applications in the world.

By a huge margin.

This kind of thing is hard to get real metrics on, but the best metric I can find to determine relative popularity is the number of users of the Developer Tools browser extension. In the Chrome DevTools, there are 2+ million users, which is twice the next most popular framework's DevTools.

However you slice it, React is extremely popular. And this has some extremely nice side-effects. In addition to React being worked on by some of the smartest engineers in the world, the size of the community means that many of the smartest engineers in the world are participating in creating and contributing to the surrounding ecosystem of libraries and tools.

This is not to suggest other frameworks don't have this (they do), but React's dominate size means that the number of people experiencing problems and solving them increases the likelihood that any problem you face has been faced and solved by someone in the community already. And if you're hiring, it's also more likely that someone is looking for a job too.

## Conclusion

Betting on React was a big leap for me. I loved Angular.js and I built some awesome applications, libraries, and tools with it. But I'm so glad that I gave React some of my time because it's paid me back in productivity and velocity that I didn't even realize was possible before. If you'd like that in your life and you haven't jumped onboard with React, then I definitely suggest you give it a try.

And I've been working hard on [something](https://EpicReact.Dev) that will really help you with that 😉

I still remember when I first heard about React. It was January 2014. I was listening to a podcast. Pete Hunt and Jordan Walke were on talking about this framework they created at Facebook that with no support for two way data-binding, no built-in HTTP library, no dependency injection, and in place of templates it had this weird XML-like syntax for the UI. And to top it all off, I was listening to it while driving to the first ever ng-conf.

Why I Love React

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.

Use CSS Variables instead of React Context

Focus management is one of those things you don't think about until it's broken.
But when it is, it can make your app feel clunky, inaccessible, or just plain
wrong. Let's talk about a little-known React API that can help you nail focus
management: [`flushSync`](https://react.dev/reference/react-dom/flushSync).

## Why focus management is tricky in React

React is fast and smart about how it updates the DOM. When you call a state
updater like `setShow(true)`, React doesn't immediately re-render your
component. Instead, it batches up state updates and processes them all at once,
after your event handler finishes. This is great for performance, but it can
trip you up when you need to interact with the DOM _right after_ a state change.

Here's a classic example:

```tsx
function MyComponent() {
	const [show, setShow] = useState(false)

	return (
		<div>
			<button onClick={() => setShow(true)}>Show</button>
			{show ? <input /> : null}
		</div>
	)
}
```

Suppose you want to focus the input as soon as it appears. You might try this:

```tsx
function MyComponent() {
	const inputRef = useRef<HTMLInputElement>(null)
	const [show, setShow] = useState(false)

	return (
		<div>
			<button
				onClick={() => {
					setShow(true)
					inputRef.current?.focus() // This probably won't work!
				}}
			>
				Show
			</button>
			{show ? <input ref={inputRef} /> : null}
		</div>
	)
}
```

But this doesn't work! Why? Because when you call `setShow(true)`, React
_schedules_ the update, but doesn't apply it until after your handler finishes.
So when you try to focus the input, it doesn't exist in the DOM yet.

## Why not just use setTimeout or requestAnimationFrame?

Early in my career, I tried to work around this by wrapping my focus call in a
`setTimeout` or `requestAnimationFrame`. Sometimes it worked, sometimes it
didn't. The timing depended on the device, the browser, and what else was
happening in the app. It was unreliable and hacky.

```tsx
onClick={() => {
	setShow(true)
	setTimeout(() => {
		inputRef.current?.focus()
	}, 10) // 🤞
}}
```

But this is a guessing game. You don't want to rely on magic numbers or hope
that the browser is fast enough. You want a guarantee.

## Enter `flushSync`

[`flushSync`](https://react.dev/reference/react-dom/flushSync) from `react-dom`
is your escape hatch. It tells React: "Hey, I know you like to batch updates for
performance, but I need you to process this update _right now_." Any state
updates inside the `flushSync` callback are applied immediately, so the DOM is
up-to-date as soon as the callback finishes.

Here's how you'd use it:

```tsx
import { flushSync } from 'react-dom'

function MyComponent() {
	const inputRef = useRef<HTMLInputElement>(null)
	const [show, setShow] = useState(false)

	return (
		<div>
			<button
				onClick={() => {
					flushSync(() => {
						setShow(true)
					})
					inputRef.current?.focus()
				}}
			>
				Show
			</button>
			{show ? <input ref={inputRef} /> : null}
		</div>
	)
}
```

Now, when you click the button, the input appears and is immediately focused. No
hacks, no guessing, just reliable focus management.

## Real-world example: EditableText

Let's look at a more practical example from the
[Epic React Advanced React APIs workshop](https://www.epicreact.dev/workshops/advanced-react-apis/).
This specific component was borrowed from
[Ryan Florence](https://x.com/ryanflorence) (thanks Ryan!). We have an
`<EditableText />` component that lets users edit a piece of text inline. When
the user clicks the button, it turns into an input. When they submit, blur, or
hit escape, it turns back into a button. We want to:

- Focus the input and select its text when editing starts
- Return focus to the button when editing ends (by submit, blur, or escape)

Here's how we do it:

```tsx
import { useRef, useState } from 'react'
import { flushSync } from 'react-dom'

function EditableText({
	initialValue = '',
	fieldName,
	inputLabel,
	buttonLabel,
}: {
	initialValue?: string
	fieldName: string
	inputLabel: string
	buttonLabel: string
}) {
	const [edit, setEdit] = useState(false)
	const [value, setValue] = useState(initialValue)
	const inputRef = useRef<HTMLInputElement>(null)
	const buttonRef = useRef<HTMLButtonElement>(null)

	return edit ? (
		<form
			onSubmit={(event) => {
				event.preventDefault()
				flushSync(() => {
					setValue(inputRef.current?.value ?? '')
					setEdit(false)
				})
				buttonRef.current?.focus()
			}}
		>
			<input
				required
				ref={inputRef}
				type="text"
				aria-label={inputLabel}
				name={fieldName}
				defaultValue={value}
				onKeyDown={(event) => {
					if (event.key === 'Escape') {
						flushSync(() => {
							setEdit(false)
						})
						buttonRef.current?.focus()
					}
				}}
				onBlur={(event) => {
					flushSync(() => {
						setValue(event.currentTarget.value)
						setEdit(false)
					})
					buttonRef.current?.focus()
				}}
			/>
		</form>
	) : (
		<button
			aria-label={buttonLabel}
			ref={buttonRef}
			type="button"
			onClick={() => {
				flushSync(() => {
					setEdit(true)
				})
				inputRef.current?.select()
			}}
		>
			{value || 'Edit'}
		</button>
	)
}
```

This approach ensures that focus is always exactly where the user expects it to
be, no matter how quickly they interact with the UI.

## Keyboard accessibility: Not just for some users

Why go to all this trouble? Because keyboard accessibility matters for everyone.
Some users rely on the keyboard due to disabilities, but many power users (like
me and probably you!) just prefer it. If your focus management is broken,
keyboard navigation becomes frustrating or impossible. Good focus management
means:

- When you tab into the editable text, pressing Enter or clicking it should
  focus the input and select the text.
- When you finish editing (by submitting, blurring, or pressing Escape), focus
  should return to the button so you can keep tabbing through the UI.

This is the kind of polish that makes your app feel great for everyone.

## When should you use `flushSync`?

- **Focus management**: When you need to move focus to an element that only
  exists after a state update.
- **Third-party integrations**: When you need to coordinate React updates with
  browser APIs or other libraries that expect the DOM to be updated immediately
  (e.g., `onbeforeprint`).

But be careful! [`flushSync`](https://react.dev/reference/react-dom/flushSync)
is a performance de-optimization. Use it sparingly and only when you really need
synchronous DOM updates. Most of the time, React's normal async updates are
exactly what you want.

## Wrap-up

Focus management is a subtle but critical part of building accessible,
delightful React apps. `flushSync` is a powerful tool for those rare cases when
you need to break out of React's normal update flow and make something happen
_right now_. Use it wisely, and your users will thank you.

Want to learn more? Check out the
[official flushSync docs](https://react.dev/reference/react-dom/flushSync) and
the
[Epic React Advanced React APIs workshop](https://www.epicreact.dev/workshops/advanced-react-apis/).


Master focus management in React with flushSync. Learn why batching matters, when to use flushSync, and how to create accessible, keyboard-friendly UIs.


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

Improving React Accessibility with `useId`

Why I Love React

Use CSS Variables instead of React Context

Mastering Focus Management in React with `flushSync`