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

Before we get started, here's a brief look of valid (today) ways to import React and use the `useState` hook:

```javascript
// global
window.React.useState()

// CommonJS
const React = require('react')
React.useState()

// ESModules default import
import React from 'react'
React.useState()

// ESModules named import
import {useState} from 'react'
useState()

// ESModules namespace import
import * as React from 'react'
React.useState()
```

Below I'll explain where each of these mechanisms came from and why I prefer the last one.

## Before the dawn of time

I started writing React code back in the `React.createClass` days. Here's how we did things back then:

```javascript
var React = require('react')

var Counter = React.createClass({
  propTypes: {
    initialCount: React.PropTypes.number.isRequired,
    step: React.PropTypes.number,
  },
  getDefaultProps: function () {
    return {step: 1}
  },
  getInitialState: function () {
    var initialCount = this.props.hasOwnProperty('initialCount')
      ? this.props.initialCount
      : 0
    return {count: initialCount}
  },

  changeCount: function (change) {
    this.setState(function (previousState) {
      return {count: previousState.count + change}
    })
  }

  increment: function () {
    this.changeCount(this.props.step)
  },

  decrement: function () {
    this.changeCount(-this.props.step)
  },

  render: function () {
    return (
      <div>
        <div>Current Count: {this.state.count}</div>
        <button onClick={this.decrement}>-</button>
        <button onClick={this.increment}>+</button>
      </div>
    )
  },
})
```

Yup, `var`, `React.createClass`, `require`, `function`. Good times.

## Classes and Modules

Eventually, we got ES6 (and later) which included modules, classes, and some other syntax niceties:

```javascript
import React from 'react'

class Counter extends React.Component {
  state = {count: this.props.initialCount ?? 0}
  changeCount() {
    this.setState(({count}) => ({count + change}))
  }
  increment = () => this.changeCount(this.props.step)
  decrement = () => this.changeCount(-this.props.step)
  render() {
    return (
      <div>
        <div>Current Count: {this.state.count}</div>
        <button onClick={this.decrement}>-</button>
        <button onClick={this.increment}>+</button>
      </div>
    )
  }
}
```

This is when the "how should I import React" question started popping up. A lot of people preferred doing this:

```javascript {1, 3}
import React, {Component} from 'react'

class Counter extends Component {
  state = {count: this.props.initialCount ?? 0}
  changeCount() {
    this.setState(({count}) => ({count + change}))
  }
  increment = () => this.changeCount(this.props.step)
  decrement = () => this.changeCount(-this.props.step)
  render() {
    return (
      <div>
        <div>Current Count: {this.state.count}</div>
        <button onClick={this.decrement}>-</button>
        <button onClick={this.increment}>+</button>
      </div>
    )
  }
}
```

Normally this sort of thing isn't even a question. You just do what the library exposes. But React never actually exposed ESModules. It exposes itself as either a global variable called `React` or a CommonJS module which is the `React` object which has `Component` on it (along with other things). But because of the way the code is compiled, both approaches technically work and neither is technically "wrong."

One other note... Looking at the code above you might wonder why we can't change that to:

```diff
- import React, {Component} from 'react'
+ import {Component} from 'react'
```

The reason you need `React` in there is because (at the time) JSX was compiled to use React:

```diff
- <button onClick={this.increment}>+</button>
+ React.createElement('button', {onClick: this.increment}, '+')
```

So if you use JSX, you need to have `React` imported as well.

It wasn't long after this that function components became a thing. Even though at the time these couldn't actually be used to manage state or side-effects, they became very popular. I (and many others) got very accustomed to refactoring from class to function and back again (many people just decided it was easier to use class components all the time).

For me, I preferred using function components as much as possible and this is likely the reason that I preferred using `import React from 'react'` and `React.Component` rather than `import React, {Component} from 'react'`. I didn't like having to update my import statement any time I refactored from class components to function components and vice-versa. Oh, and I know that IDEs/editors like VSCode and WebStorm have automatic import features, but I never found those to work very well (I ran into stuff like [this](https://github.com/testing-library/react-testing-library/issues/642#issuecomment-718926429) all the time).

Oh, and one other interesting fact. If you were using TypeScript instead of Babel, then you'd actually be required to do `import * as React from 'react'` unless you enabled [`allowSyntheticDefaultImports`](https://www.typescriptlang.org/tsconfig#allowSyntheticDefaultImports).

## The Age of Hooks

Then hooks took the scene and the way I wrote components evolved again:

```javascript
import React from 'react'

function Counter({initialCount = 0, step}) {
  const [count, setCount] = React.useState(initialCount)
  const decrement = () => setCount((c) => c - step)
  const increment = () => setCount((c) => c + step)
  return (
    <div>
      <div>Current Count: {count}</div>
      <button onClick={decrement}>-</button>
      <button onClick={increment}>+</button>
    </div>
  )
}
```

This brought up another question on how to import React. We had two ways to use hooks:

```javascript
import React from 'react'
// ...
const [count, setCount] = React.useState(initialCount)

// alternatively:
import React, {useState} from 'react'
// ...
const [count, setCount] = useState(initialCount)
```

So again, should we do named imports, or just reference things directly on `React`? Again, for me, I prefer to not have to update my imports every time I add/remove hooks from my files (and again, I don't trust IDE auto-import), so I prefer `React.useState` over `useState`.

## The new JSX transform and the future of React + ESM

Finally, React 17 was released with basically no real breaking changes but [an announcement](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html) of great import (pun intended): There's a new JSX transform that means you no longer need to import React to transform JSX. So now you can write:

```javascript
function App() {
  return <h1>Hello World</h1>
}
```

And this will get compiled to:

```javascript
// Inserted by a compiler (don't import it yourself!)
import {jsx as _jsx} from 'react/jsx-runtime'

function App() {
  return _jsx('h1', {children: 'Hello world'})
}
```

So the import happens automatically now! That's great, but that also means that if you want to migrate to use this new capability, you'll need to remove any `import React from 'react'` that's just for JSX. Luckily the React team made a script to do this automatically, but they had to make a decision on how to handle situations where you're using hooks. You have two options:

```javascript
import * as React from 'react'
const [count, setCount] = React.useState(initialCount)

// or
import {useState} from 'react'
const [count, setCount] = useState(initialCount)
```

Both of these work today, are technically correct, and will continue to work into the future when React finally exposes an official ESModules build.

The React team decided to go with the named imports approach. I disagree with this decision for reasons mentioned above (having to update my import all the time). So for me, I'm now using the `import * as React from 'react'` which is a mouthful for my hands to type, so I have a snippet:

```javascript
// snippets/javascript.json
{
  "import React": {
    "prefix": "ir",
    "body": ["import * as React from 'react'\n"]
  },
}
```

For me, I'm sticking with `import * as React from 'react'` so I don't have to worry about my imports. And that's my overly long blog post answer for a very common question I get. Hope it was helpful!

How and why I import react using a namespace

Importing React Through the Ages

React components afford us the opportunity to encapsulate state, logic, and markup in a single place. A component is like a magical machine where you pass in props and a beautiful component pops out the other end.

Unfortunately, truly maintainable, flexible, simple, and reusable components require more thought than: "I need it to do this differently, so I'll accept a new prop for that." Seasoned React developers know this leads to nothing but pain and frustration for both the maintainer and user of the component. Ever hear of [the apropcalypse](https://twitter.com/gurlcode/status/1002110517094371328)? It's not fun.

The only thing you can really expect about the future is the unexpected. Nobody can know the future for certain, so you need some tools in your toolbelt that help you avoid committing yourself to a path that may not satisfy the needs of the future. With React components, these tools are patterns that have been battle tested in real applications and libraries and if you're not using them in your components today, you're likely dealing with APIs that result in more workarounds than lines of maintainable code.

And that's slowing you down.

## For example

One of my favorite tools for creating great component abstractions is the idea of "compound components." The idea of compound components has been around forever (think `<select>` and `<option>`), and it's been implemented in some of my favorite libraries (check [Reach UI](https://reach.tech/)). Utilizing compound components, you can go from an inflexible API like this:

```jsx
<Modal
  modalTitle="Register"
  modalLabelText="Registration form"
  openButtonText="Register"
  dismissable={true}
  contents={
    <LoginForm
      onSubmit={register}
      submitButton={<Button variant="secondary">Register</Button>}
    />
  }
/>
```

To something with ultimate flexibility like this:

```jsx
<Modal>
  <ModalOpenButton>
    <Button variant="secondary">Register</Button>
  </ModalOpenButton>
  <ModalContents aria-label="Registration form">
    <ModalDismissButton>
      <CircleButton>
        <VisuallyHidden>Close</VisuallyHidden>
        <span aria-hidden>×</span>
      </CircleButton>
    </ModalDismissButton>
    <ModalTitle>Register</ModalTitle>
    <LoginForm
      onSubmit={register}
      submitButton={<Button variant="secondary">Register</Button>}
    />
  </ModalContents>
</Modal>
```

(Note, the compound components are all the ones that start with `Modal`).

I can tell some of you are looking at this thinking: "Huh... well I actually like the first one better." But remember, we can't anticipate all the needs of our component's API in the future, so we want to focus on which will be most adaptable.

Consider the difficulty in the following possible future use cases:

- We want to add a "cancel" button (but still need to support the dismiss   button) - We want to style the modal title, open button, or dismiss button (you want to   add a `openButtonProps` prop? lol, I wish I could say I've never tried that   before 🤦‍♂️)

Oh, and the neat thing about this is that if you really _do_ like the first one better, there's nothing stopping you from creating a component that uses the compound components API to expose the same API as the first. But try doing that in the reverse 😉

Taking things further, if it's really common enough, you could create a special `ModalContents` component that handles rendering the dismiss button and title, so in the end it looks like:

```jsx
<Modal>
  <ModalOpenButton>
    <Button variant="secondary">Register</Button>
  </ModalOpenButton>
  <ModalContents aria-label="Registration form" title="Register">
    <LoginForm
      onSubmit={register}
      submitButton={<Button variant="secondary">Register</Button>}
    />
  </ModalContents>
</Modal>
```

But you don't have to sacrifice the benefits of the previous API thanks to composition. Sure you could do something similar with our previous API, but have you ever tried to maintain a component with a hodgepodge of props like that? I mean, I love that React components can be black boxes just as much as the next developer, but I'd prefer to not experience soul-crushing maintainability nightmares any time I need to venture into that black box...

## Conclusion

The beauty of patterns like compound components, state reducers, prop getters, controlled props, etc. is that you can have your simple API _and_ a simple implementation at the same time. If you aren't doing this yet, **now's a great time to start.**

And I'm excited to teach you how on [EpicReact.Dev](https://epicreact.dev).

Truly maintainable, flexible, simple, and reusable components require more thought than: "I need it to do this differently, so I'll accept a new prop for that". Seasoned React developers know this leads to nothing but pain and frustration for both the maintainer and user of the component.

Avoid soul-crushing components

If you've ever used a native `<select>` and `<option>` in HTML, you've already
experienced the power of **compound components**—even if you didn't know the
name.

But what if you could bring that same flexibility and declarative power to your
own React components? That's what the Compound Components pattern is all about.

## What and Why: Compound Components in React

Compound components are a set of components that work together to form a
complete UI, implicitly sharing state and behavior. Think of them as a family:
each member has a role, but they all work together seamlessly.

The classic example is HTML's select:

```html
<select>
	<option value="1">Option 1</option>
	<option value="2">Option 2</option>
</select>
```

The `<select>` manages the state, and the `<option>`s are just configuration.
You don't have to wire them up manually—they just work.

You _could_ build a custom select like this:

```tsx
<CustomSelect
	options={[
		{ value: '1', display: 'Option 1' },
		{ value: '2', display: 'Option 2' },
	]}
/>
```

But what if you want to add custom attributes to an option, or change how it's
displayed when selected? You'd have to keep adding more props and configuration,
making your API more complex and less flexible.

Compound components let you keep your API simple and declarative:

```tsx
<CustomSelect>
	<CustomOption value="1">Option 1</CustomOption>
	<CustomOption value="2">Option 2</CustomOption>
</CustomSelect>
```

Now, you can pass _anything_ as children, and each option can be as flexible as
you need.

The parent component (like `<CustomSelect>`) manages the shared state and passes
it down to its children using React's context API. The children (like
`<CustomOption>`) consume that context and interact with the parent as needed.

This pattern lets you build components that are:

- **Flexible:** Users can compose your components however they want.
- **Declarative:** The structure of the UI matches the structure of the code.
- **Extensible:** Add new features without breaking existing APIs.

## Real-World Impact & When to Use

This isn't just a theoretical pattern. It's used in some of the most popular UI
libraries, like
[Radix UI Tabs](https://www.radix-ui.com/primitives/docs/components/tabs) and
[Radix UI Accordion](https://www.radix-ui.com/primitives/docs/components/accordion).
In fact, most of [Radix UI](https://www.radix-ui.com/primitives) is built on
this pattern.

Reach for compound components when:

- You want to give users maximum flexibility in composing your UI.
- You want to avoid prop explosion and keep your API clean.
- You want your components to "just work" together, like native HTML elements.

Want to master patterns like this—and many more?
[EpicReact.dev](https://epicreact.dev) is packed with hands-on workshops,
real-world examples, and deep dives into the patterns that make React apps
scalable and maintainable. Whether you're a beginner or a seasoned pro, you'll
find something to level up your React skills.


Build flexible, declarative UIs like native HTML with Compound Components—a powerful React pattern you’ll master at EpicReact.dev.

Compound Components: Truly Flexible React APIs

If you've ever used a controlled input in React, you've already experienced the
power of the **Control Props** pattern—even if you didn't know its name.

But what if you could bring that same flexibility to your own components? That's
what the Control Props pattern is all about.

The Control Props pattern lets users of your component take full control over
its state—just like how you can control the value of an `<input />` with React
state. By default, your component manages its own state, but if a user provides
a "control prop" (like `value`), your component defers to them and simply
"suggests" state changes via callbacks (like `onChange`).

This is the same pattern you use every time you write a controlled input:

```tsx
function MyCapitalizedInput() {
	const [capitalizedValue, setCapitalizedValue] = useState('')

	return (
		<input
			value={capitalizedValue}
			onChange={(e) => setCapitalizedValue(e.target.value.toUpperCase())}
		/>
	)
}
```

Here, the `<input />` is "controlled" by your state. If you don't provide a
`value` prop, it manages its own state. But as soon as you do, you're in charge.

## Why Does This Matter?

Control props "inverts control" from your component to the developer using it.

- **Flexibility:** Users can manage state however they want—capitalize,
  lowercase, sync across multiple components, or even control from a parent.
- **Predictability:** State lives where the user wants it, not hidden inside
  your component.
- **Composability:** Multiple components can share and sync state easily.

For example, you can synchronize two inputs with different transformations:

```tsx
function MyTwoInputs() {
	const [capitalizedValue, setCapitalizedValue] = useState('')
	const [lowerCasedValue, setLowerCasedValue] = useState('')

	function handleInputChange(e) {
		setCapitalizedValue(e.target.value.toUpperCase())
		setLowerCasedValue(e.target.value.toLowerCase())
	}

	return (
		<>
			<input value={capitalizedValue} onChange={handleInputChange} />
			<input value={lowerCasedValue} onChange={handleInputChange} />
		</>
	)
}
```

## Real-World Examples

This isn't just a pattern for inputs. It's used in powerful libraries like
[downshift](https://github.com/downshift-js/downshift) and
[Radix UI Select](https://www.radix-ui.com/primitives/docs/components/select#controlling-the-value-displayed-in-the-trigger).
These libraries let you control their state from the outside, making them
incredibly flexible and easy to integrate into any app.

Here's a simple example of a controlled select using Radix UI:

```jsx
import * as React from 'react'
import { Select } from '@radix-ui/react-select'

export default function ControlledSelect() {
	const [value, setValue] = React.useState('apple')
	return (
		<Select.Root value={value} onValueChange={setValue}>
			<Select.Trigger>
				<Select.Value placeholder="Pick a fruit" />
				<Select.Icon />
			</Select.Trigger>
			<Select.Portal>
				<Select.Content>
					<Select.Item value="apple">Apple</Select.Item>
					<Select.Item value="orange">Orange</Select.Item>
					<Select.Item value="grape">Grape</Select.Item>
				</Select.Content>
			</Select.Portal>
		</Select.Root>
	)
}
```

You control the value from outside the component, and Radix just "suggests"
changes via `onValueChange`—a perfect example of the control props pattern in
action. This allows you to programatically control the value of the select,
while still allowing the user to select from the list.

[See the official docs for more.](https://www.radix-ui.com/primitives/docs/components/select#controlling-the-value-displayed-in-the-trigger)

## Simple implementation

This can actually get a little complex (which is why we have an exercise on it
in [EpicReact.dev](https://epicreact.dev)). The reason it's tricky is because
you want to support both controlled and uncontrolled modes.

Here's a simple implementation:

```tsx
function MySelect({ value, onChange }) {
	const [internalValue, setInternalValue] = useState(value)

	function handleChange(e) {
		setInternalValue(e.target.value)
		onChange?.(e)
	}

	return (
		<select value={value ?? internalValue} onChange={handleChange}>
			<option value="apple">Apple</option>
		</select>
	)
}
```

This allows you to use the component in both controlled and uncontrolled modes.

There's definitely more to it, but hopefully this gives you an idea of what's
going on.

## Conclusion

When should you use control props? Reach for this pattern when you want your
component to be both easy to use and highly customizable, when you want to let
users sync or transform state across multiple components, or when you want to
empower users to manage state in the way that fits their app.

Want to master patterns like this—and many more?
[EpicReact.dev](https://epicreact.dev) is packed with hands-on workshops,
real-world examples, and deep dives into the patterns that make React apps
scalable and maintainable. Whether you're a beginner or a seasoned pro, you'll
find something to level up your React skills.


Control Props let you hand over component state to your users—just like a controlled input. Learn to build ultra-flexible UIs at EpicReact.dev.

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

Importing React Through the Ages

Avoid soul-crushing components

Compound Components: Truly Flexible React APIs

Control Props: Give Your React Components Superpowers