Test Post With Video

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

So, you've got some code in `React.useEffect` and you want to know how to test it. This is a pretty common question. The answer is kinda anti-climatic and general. Here's how you think about testing _anything_:

> How does the user make that code run? Make your test do that.

That's it. That's the secret. The trick is discovering what constitutes a "user." Your React components actually have 2 users: the developer who renders it and the end-user who interacts with it. Generally, your tests should do no more or less than what these users do. For more on this, read [Avoid the Test User](https://kentcdodds.com/blog/avoid-the-test-user).

So, let's take a look at an example. I'll grab some code from one of the exercises in [EpicReact.dev/app](https://epicreact.dev/app) (it's a pretty long example, feel free to scan it quickly):

```javascript
/** @jsx jsx */
import {jsx} from '@emotion/core'

import * as React from 'react'
import Tooltip from '@reach/tooltip'
import {FaSearch, FaTimes} from 'react-icons/fa'
import {Input, BookListUL, Spinner} from './components/lib'
import {BookRow} from './components/book-row'
import {client} from './utils/api-client'
import * as colors from './styles/colors'

function DiscoverBooksScreen() {
  const [status, setStatus] = React.useState('idle')
  const [data, setData] = React.useState()
  const [error, setError] = React.useState()
  const [query, setQuery] = React.useState()
  const [queried, setQueried] = React.useState(false)

  const isLoading = status === 'loading'
  const isSuccess = status === 'success'
  const isError = status === 'error'

  React.useEffect(() => {
    if (!queried) {
      return
    }
    setStatus('loading')
    client(`books?query=${encodeURIComponent(query)}`).then(
      (responseData) => {
        setData(responseData)
        setStatus('success')
      },
      (errorData) => {
        setError(errorData)
        setStatus('error')
      },
    )
  }, [query, queried])

  function handleSearchSubmit(event) {
    event.preventDefault()
    setQueried(true)
    setQuery(event.target.elements.search.value)
  }

  return (
    <div
      css={{maxWidth: 800, margin: 'auto', width: '90vw', padding: '40px 0'}}
    >
      <form onSubmit={handleSearchSubmit}>
        <Input
          placeholder="Search books..."
          id="search"
          css={{width: '100%'}}
        />
        <Tooltip label="Search Books">
          <label htmlFor="search">
            <button
              type="submit"
              css={{
                border: '0',
                position: 'relative',
                marginLeft: '-35px',
                background: 'transparent',
              }}
            >
              {isLoading ? (
                <Spinner />
              ) : isError ? (
                <FaTimes aria-label="error" css={{color: colors.danger}} />
              ) : (
                <FaSearch aria-label="search" />
              )}
            </button>
          </label>
        </Tooltip>
      </form>

      {isError ? (
        <div css={{color: colors.danger}}>
          <p>There was an error:</p>
          <pre>{error.message}</pre>
        </div>
      ) : null}

      {isSuccess ? (
        data?.books?.length ? (
          <BookListUL css={{marginTop: 20}}>
            {data.books.map((book) => (
              <li key={book.id} aria-label={book.title}>
                <BookRow key={book.id} book={book} />
              </li>
            ))}
          </BookListUL>
        ) : (
          <p>No books found. Try another search.</p>
        )
      ) : null}
    </div>
  )
}

export {DiscoverBooksScreen}
```

> Keep in mind that the above example would be better with `useReducer` and we > get to improving this later in the workshop exercises.

Let's look at this bit specifically:

```javascript
React.useEffect(() => {
  if (!queried) {
    return
  }
  setStatus('loading')
  client(`books?query=${encodeURIComponent(query)}`).then(
    (responseData) => {
      setData(responseData)
      setStatus('success')
    },
    (errorData) => {
      setError(errorData)
      setStatus('error')
    },
  )
}, [query, queried])

function handleSearchSubmit(event) {
  event.preventDefault()
  setQueried(true)
  setQuery(event.target.elements.search.value)
}
```

Because we've properly mocked our backend using [MSW](https://mswjs.io/) (learn more about that in [Stop Mocking Fetch](https://kentcdodds.com/blog/stop-mocking-fetch)), we can actually make that request and get results. So let's interact with this component just the same way the end user would. Here's a test that actually works with this code:

```javascript
import * as React from 'react'
import {
  render,
  screen,
  waitForElementToBeRemoved,
  within,
} from '@testing-library/react'
import userEvent from '@testing-library/user-event'
import {DiscoverBooksScreen} from '../discover.extra-1'

// Learn more: https://kentcdodds.com/blog/stop-mocking-fetch
import {server} from 'test/server'
beforeAll(() => server.listen())
afterAll(() => server.close())
afterEach(() => server.resetHandlers())

test('queries for books', async () => {
  // 🤓 this is what developer users do
  render(<DiscoverBooksScreen />)

  // 🤠 this is what end users do
  userEvent.type(
    screen.getByRole('textbox', {name: /search/i}),
    'Sanderson{enter}',
  )
  // 🤠 end users will also note the presence of the loading indicator
  // and wait until it's gone before making som assertions
  await waitForElementToBeRemoved(() => screen.getByLabelText(/loading/i))

  // 🤠 end users will look at all the items in the list to see the book titles
  // Also, assistive technologies will take advantage of the implicit "listitem"
  // ARIA role of our `li` elements.
  const results = screen.getAllByRole('listitem').map((listItem) => {
    return within(listItem).getByRole('heading', {level: 2}).textContent
  })
  // I rarely use snapshots, but this seemed like a pretty good application:
  // https://kcd.im/snapshots
  expect(results).toMatchInlineSnapshot(`
    Array [
      "The Way of Kings (Book 1 of the Stormlight Archive)",
      "Words of Radiance (Book 2 of the Stormlight Archive)",
      "Oathbringer (Book 3 of the Stormlight Archive)",
    ]
  `)
})
```

There are other ways I could write this test (there are some important things that happen in that `test/server` module that we don't have time to cover in this post), but the principles are all the same:

> How does the user make that code run? Make your test do that.

Stated differently:

> The more your tests resemble the way your software is used, the more > confidence they can give you. > [– me](https://twitter.com/kentcdodds/status/977018512689455106)

So don't try mocking `useEffect` or `useState` or whatever. Stay away from that third user (the dreaded test user). The only thing that user is good for is turning you into a glorified test babysitter. And I don't know about you, but I'd rather ship awesome stuff to real people.

Testing React.useEffect is much simpler than you think it is.

How to Test React.useEffect

In this post, we’re going to dive deep on how you use modern React APIs for building forms. We will not be using third party libraries or frameworks. Understanding these lower level primitives will unlock them for you when using libraries and frameworks.

I recently heard someone say that web applications are just a skin on top of a database. And that’s actually pretty accurate. Since the beginning of the web, modern web applications have had two sides to them:

1. Users view data
2. Users mutate data

Loading data into a web application is a pretty straightforward proposition. It’s only when we start talking about needing to modify that data and keep things in sync that things get more complicated.

From day 1, HTML supported mechanisms for both of these use cases.

## Viewing Data

This allows the user to navigate to another page to view more data:

```html
<a href="/remix-utah/events/301213597">Remix Meetup June 🏖</a>
```

This *also* allows the user to navigate to another page to view more data, but enables them to control the data that comes back by including the user’s input in the generated URL:

```html
<form action="/remix-utah/events/search">
	<label for="event-search">Query</label>
	<input id="event-search" type="search" name="query" />
	<button type="submit">Search</button>
</form>
```

Let’s say the user types “August” in the input and hits enter. Thanks to the `action` the user would be sent to `/remix-utah/events/search?query=August`. So by default, `<form>` is just like `<a>` with the special ability of allowing the user to provide input.

## Mutating data

For both `<form>` and `<a>`, the navigation is performed via a `GET` request, which makes sense because you’re trying to `GET` data. But what if the user is trying to *modify* the data?

For example, let’s say you want to be able to sign up for an event with `/remix-utah/events/301213597/join`. If we made that endpoint a `GET` then we could do that like so:

```html
<a href="/remix-utah/events/301213597/join">Join Remix Meetup June 🏖</a>
```

This would certainly work (you could even use a `<form>` with a submit button if you wanted. However, this would also open your users up to a potential problem: **accidental or malicious modification of data**. Since `GET` requests are designed to be idempotent (they should be callable repeatedly without observable effects), using them for state-changing actions can lead to unintended consequences.

Additionally, if you made a login form using a `GET` request, then the user submits their password and the URL looks like this: `/login?username=kody&password=kodylovesyou`! The user’s submission is in plain text in plain sight!

This is part of the reason we have `POST` requests and while you can’t make `<a>` use `POST` instead of `GET`, you can do this with `<form>`.

`POST` requests are designed for submitting data to be processed to a specified resource. There’s no feature of HTML that triggers a `POST` request without user interaction, so they can safely be used to change the state of the server, which is perfect for our scenario of joining an event. Here’s how you can use a form to `POST` data:

```html
<form action="/remix-utah/events/301213597/join" method="POST">
	<button type="submit">Join Remix Meetup June 🏖</button>
</form>
```

By using `method="POST"`, we indicate that this form is meant to modify data on the server. The server will then process this request and update its state accordingly, ensuring that the user's intent to join the event is recorded.

### Handling Data Mutations with JavaScript

While traditional form submissions cause a full page reload, modern web applications often use JavaScript to handle these actions asynchronously, providing a smoother user experience.

Here's an example of how you might handle a form submission with JavaScript:

```html
<form id="join-event-form">
	<button type="submit">Join Remix Meetup June 🏖</button>
</form>

<script type="module">
	const form = document.getElementById('join-event-form')
	form.addEventListener('submit', async (event) => {
		event.preventDefault()

		const response = await fetch('/remix-utah/events/301213597/join', {
			method: 'POST',
			headers: { 'Content-Type': 'application/json' },
			body: JSON.stringify({ /* any necessary data can go here */ }),
		})

		if (response.ok) {
			alert('Successfully joined the event!')
		} else {
			alert('Failed to join the event.')
		}
	})
</script>
```

This script intercepts the form submission, prevents the default browser behavior, and instead sends an asynchronous `POST` request to the server. This way, the page does not need to reload, and the user receives immediate feedback on their action.

You may notice the lack of `method="POST"` in this example and that’s because it’s not strictly necessary since we prevent the browser’s default behavior.

While preventing the full page refresh is great, we lose a lot of things the browser does for us automatically when we prevent that default behavior which result in bugs we find in applications all the time.

For example, race conditions and data revalidation. That said, if you have a framework that helps you with those things (like [React Router](https://reactrouter.com/)/[Remix](https://remix.run)), then the effort is worth the improved user experience.

## React Form Actions

Mutations are an important and common part of dynamic web applications. So is linking to different parts of the application. However, mutating data is complicated because as soon as the user has performed the mutation, there are parts of the UI they could be looking at that could be out of date.

Now, to be clear, with a regular browser mutation there isn’t a problem because the full page refresh means the user always sees the latest that the server has to offer. However, if we’re focused on providing the best user experience possible, the full page refresh is unacceptable. But that means we need to update the data on the page after the mutation.

Another thing that complicates both links and forms in client-side applications is managing pending states. By default, the browser will show a spinner (often in place of the favicon), but when we prevent that default behavior we need to think about giving feedback to the user during the transition.

React has a great solution [for transitions](https://react.dev/reference/react/useTransition), but that’s only half of the story for forms. Because of this added complexity, React 19 has a built-in mechanism for handling forms called “actions.”

Just like the action attribute in an HTML form, you use the action prop in a React component. However, in addition to a URL, you can instead provide a function which will be called upon submission of the form.

```tsx
function JoinEventForm() {
	function joinEvent(formData) {
		const response = await fetch('/remix-utah/events/301213597/join', {
			method: 'POST',
			body: formData,
		})

		if (response.ok) {
			alert('Successfully joined the event!')
		} else {
			alert('Failed to join the event.')
		}
	}

	return (
		<form action={joinEvent}>
			<button type="submit">Join Remix Meetup June 🏖</button>
		</form>
	)
}
```

If you’re familiar with React forms using the `onSubmit` prop, I want you to note a few key differences here:

1. There’s no need to add `event.preventDefault` because that’s handled for us by React
2. The `action` is automatically treated as a transition, so anything that happens during the action which trigger components to suspend will be a part of that same transition. More on this in a bit.
3. We can hook into the pending state of this action using `useFormStatus` .
4. React manages errors and race conditions to ensure our form’s state is always correct (no infinite spinners).

## Pending States

There are a couple ways to manage the pending states for this interaction.

### useFormStatus

If you’re familiar with how context works in React apps, think of the `<form>` component as a provider and the `useFormStatus` hook as a function which accesses that provider’s data. Fundamentally, the `<form>` in React manages state of the status of the form and we can access that in any child component of the `<form>` . So to access the pending state of our form (while the submission is in flight) we need to create a child component.

```tsx
function JoinButton({ children }: { children: React.ReactNode }) {
	const { pending } = useFormStatus()

	return (
		<button type="submit">
			{pending ? 'Joining...' : children}
		</button>
	)
}

function JoinEventForm() {
	async function joinEvent(formData) {
		const response = await fetch('/remix-utah/events/301213597/join', {
			method: 'POST',
			body: formData,
		})

		if (response.ok) {
			alert('Successfully joined the event!')
		} else {
			alert('Failed to join the event.')
		}
	}

	return (
		<form action={joinEvent}>
			<JoinButton>Join Remix Meetup June 🏖</JoinButton>
		</form>
	)
}
```

The cool thing about [the `useFormStatus` hook](https://react.dev/reference/react-dom/hooks/useFormStatus) is that it also gives you access to other things about the form (including the submitted data). So if you’re building a login form, you could have the pending state say: `logging you in as {data.get('username')}` .

One thing I don’t love about it though is the requirement to make an entirely new component to consume the form’s state, so let’s look at an alternative approach.

### useActionState

It’s easiest to explain [`useActionState`](https://react.dev/reference/react/useActionState) with an example:

```tsx
const JOIN_URL = '/remix-utah/events/301213597/join'

async function joinEvent(
	previousState: { joined: boolean },
	formData: FormData,
) {
	const response = await fetch(JOIN_URL, {
		method: 'POST',
		body: formData,
	})

	if (response.ok) {
		return { joined: true }
	} else {
		return { joined: false }
	}
}

function JoinEventForm() {
	const [state, formAction, isPending] = useActionState(
		joinEvent,
		{ joined: false },
		JOIN_URL,
	)

	return (
		<div>
			{state.joined ? (
				<p>See you there!</p>
			) : (
				<form action={formAction}>
					<button type="submit">
						{isPending ? 'Joining...' : 'Join Remix Meetup June 🏖'}
					</button>
				</form>
			)}
		</div>
	)
}
```

Alright, so what’s going on here is `useActionState` accepts a function (`joinEvent`), some initial state (`{ joined: false }`), and optionally a permalink URL (`JOIN_URL`). It then returns an array with the current state (`state`), a function you can call to trigger the action (`formAction`), and whether the form submission is pending (`isPending`).

The `joinEvent` function accepts the previous state. In a way you can think of it as a reducer a la `useReducer`. When our form is submitted, it’s `action` is called with the `formData`. Our `action` is the `formAction`. The `formAction` function will call `joinEvent` with the current state followed by any arguments it’s called with. I understand that may be a little confusing, so let me illustrate by being obnoxiously verbose:

```tsx
function JoinEventForm() {
	const [state, formAction, isPending] = useActionState(
		(prevState, ...args) => joinEvent(prevState, ...args),
		{ joined: false },
		JOIN_URL,
	)

	return (
		<div>
			{state.joined ? (
				<p>See you there!</p>
			) : (
				<form
					action={(formData) => {
						const args = [formData]
						formAction(...args)
					}}
				>
					<button type="submit">
						{isPending ? 'Joining...' : 'Join Remix Meetup June 🏖'}
					</button>
				</form>
			)}
		</div>
	)
}
```

The `action` prop is called with the `formData`, we then make an array called `args` with only one element of `formData` which we then spread into a call of `formAction`. `formAction` then calls our inline function with the `prevState` and the rest of the args (in our case that’s just the `formData`, but as far as `useActionState` is concerned, it doesn’t have to be. It just forwards along whatever arguments there are.

From there, our `joinEvent` function performs whatever async stuff it needs to do, and then it returns a value which ends the transition and triggers our form to rerender with the `state` being equal to our returned value.

Of course during the transition, `isPending` will be `true` so we can show our pending state. However, we don’t have access to the `formData` outside our `action` so we wouldn’t be able to use the form submission as part of our pending UI like we could with `useFormStatus`. But there’s even more we can do!

Before we talk about that, I’ll just briefly mention that the third argument to `useActionState` is called a `permalink` and it’s there for server rendering and progressive enhancement. What React does with that is set the `action` to the URL you provide during server rendering. That way if the form is submitted before React has a chance to load on the page, the regular browser behavior will take over and submit the form with the full-page refresh functionality we’re used to (you’ll just want to make sure your server can handle the form submission properly). Hooray for progressive enhancement!

### useOptimistic

Showing the user feedback of pending tasks is important and useful. It’s awesome if the pending state actually looks like the finished state (maybe with a subtle indicator that it’s not actually complete). A good example of this is when you send a Slack/Discord message. The message appears in the messages list, but it’s slightly transparent to give you the sense that it’s an incomplete mutation.

You can do this with [`useOptimistic`](https://react.dev/reference/react/useOptimistic):

```tsx
// ...

function JoinEventForm() {
	const [state, formAction] = useActionState(
		joinEvent,
		{ joined: false },
		JOIN_URL,
	)
	const [optimisticJoined, setOptimisticJoined] = useOptimistic(state.joined)

	return (
		<div>
			{optimisticJoined ? (
				// show faded a bit if we've not yet finished joining...
				<p style={{ opacity: state.joined ? 1 : 0.8 }}>See you there!</p>
			) : (
				<form
					action={(formData) => {
						setOptimisticJoined(true) // Optimistically set the state to joined
						return formAction(formData)
					}}
				>
					<button type="submit">
						Join Remix Meetup June 🏖
					</button>
				</form>
			)}
		</div>
	)
}
```

The `useOptimistic` hook allows you to immediately update the UI to reflect the user's action before the network request completes. If the actual request fails, the state is reverted to the previous state. This provides a smoother user experience by reducing the perceived latency of the action.

We can even remove the pending UI from the button, but we add a little transparency to the success message to give the impression things are not completely settled. You may want to consider the experience for non-seeing users as well. React provides us with all we need to build this kind of experience!

You can even perform multiple steps and keep the user up-to-date with what’s happening with `useOptimistic`. It’s awesome:

```tsx
// ...

function JoinEventForm() {
	const [state, formAction] = useActionState(
		joinEvent,
		{ joined: false },
		JOIN_URL,
	)
	const [optimisticMessage, setOptimisticMessage] = useOptimistic("")

	return (
		<div>
			{state.joined ? (
				<p>See you there!</p>
			) : (
				<form
					action={async (formData) => {
						setOptimisticMessage("Joining meetup...")
						await formAction(formData)
						setOptimisticMessage("Sending notifications...")
						await sendNotification()
					}}
				>
					<p>{optimisticMessage}</p>
					<button type="submit">
						Join Remix Meetup June 🏖
					</button>
				</form>
			)}
		</div>
	)
}
```

In this example, we use the `useOptimistic` hook to provide feedback to the user at multiple stages of the form submission process. Initially, we set the optimistic message to "Joining meetup...", then await the `formAction`. Once that completes, we update the message to "Sending notification..." and await the `sendNotification` function.

## Conclusion

I think it’s awesome that we’ve not needed to reach for any libraries other than React to have all of this functionality. Really, what’s cool is what you *don’t see* but get like declarative management of errors and pending transitions and proper management of race conditions. And a great Optimistic UI story is also awesome. We also didn’t get to talk much about how this integrates with the server via the [`"use server"`](https://react.dev/reference/rsc/use-server) directive, but that’s a huge win as well which we’ll have to explore in the future.

I hope this article helped you get a more clear picture of what’s possible with React 19’s form primitives.

React 19 introduces terrific primitives for building great forms. Let's dive deep on forms for the web with React.

A deep dive on forms with modern React

At the end of a long day when the lights are out and I lie down in bed ready to fall into a blissful sleep, sometimes my wife will remind me that I forgot to lock the back door. When this happens, for some reason I often decide (irrationally) to take a chance in the darkness rather than turn on my phone's flashlight. Maybe it's because I like living on the edge. Maybe I'm not thinking. Whatever the reason, doing this is... dangerous.

It's dangerous because I have four children and a dog who's as black as night. If I'm lucky, I'll return to the sanctuary of my bed unscathed with nothing more than an increased heart rate (what a rush!). But often I'll also have stepped on some toys, kicked a door frame, bumped into the banister, and on really unfortunate nights, stepped on my snoozing dog (sorry Gemma!).

Learning can be a lot like stumbling around in the darkness. Except not only is there no illumination to guide you, you're also in someone else's house and their kids are less clean than yours and their dogs are darker and less forgiving than yours. Sound terrifying? If you've ever learned something new, you know it is.

The big problem is you don't know what you don't know. This means you don't know what to look for. You try something and it "works" but you don't know why it works or whether there's a better or easier (less painful) way to do it. You're trying to lock the back door and you walk around the couch 8 times because you're not sure whether there's a more direct route to get there. If you're lucky, you've got other co-workers alongside you.

If you're really lucky they've done this before and can guide you along. But more often they're either too busy or they're just as inexperienced as you are and all they can do is hold your hand and tell you "it's going to be ok." While this is appreciated, it's not directly helpful.

When you're learning something new, you're stumbling in the sea of things you don't know you don't know. Perhaps you've cobbled together API docs from here, a tutorial from there, an online course from way over there, and a tweet or two from back there. You attempt to piece those things together in your mind to try to give you something that resembles knowledge and experience, but often you'll find you've tried to shove a round peg in a square hole. There's no cohesion. And in your rush to create a candle to light your way, you've forgotten the wick.

The other day I tweeted this:

https://twitter.com/kentcdodds/status/1310042224600649729

I had several people make the suggestion that "learning isn't suffering." I actually agree with this. "Suffering" is the wrong word for what learning **should be**. Learning **is** a struggle, but it **should be** guided struggle where you are presented with problems, but also the right tools and information you need to identify and implement the solution.

Far too many online courses posing as "learning resources" completely take away that struggle. They sit you in a high chair and attempt to spoon feed you knowledge. Unfortunately, leaving out the struggle is basically like forgetting to put food on the spoon 🥄. All the movements are there, but none of the sustenance. They show you the happy path of what you're trying to do and leave you to fend for yourself on error messages (or worse, silent errors) only to later realize that the solution they've given you won't work for the problem you're facing.

There's different kind of struggles though. There's the struggle of working through a problem with a solution that you've been guided into by experience. This first kind of struggle is what creates retention so you can use that as a gained skill later. And then there's the struggle of hitting a wall on some unrelated problem that's simply a road block to what you're really trying to learn.

Maybe you haven't experienced the first, but you've probably experienced the second. That wall-hitting struggle is so often (and unfortunately) unavoidable. Eventually you'll bust down that wall and you'll leave victorious with knowledge of how to bust down that wall in the future, but the victory is hollow because you'll never hit that wall again anyway. It's a side-quest with all the challenge, but none of the reward. Maybe it's fun in the moment, but when you're done your product is not shipped and your manager is not sure you deserve the raise you asked for.

Another struggle involves the struggle of "holding it wrong" or "using the wrong tool for the job." This often comes from learning about the tools that are available, but not learning how the tools work, how they should be used, what problems they're intended to solve, and (just as important) what problems they're _not_ intended to solve. For example, maybe you heard once that using `React.useCallback`, `React.useMemo`, and `React.memo` will improve performance, so you start applying those tools everywhere. And now you're struggling because your code is more complex than it needs to be and in the back of your mind you're worried about that one time the component didn't re-render when it should have.

Learning _can be_ suffering if you're doing the wrong kind of struggling. Stumbling around in the learning darkness is not fun or productive. It's frustrating and far too many people give up completely when that's their experience when struggling to learn.

But there's a way to avoid suffering when learning: **Have a complete and cohesive guide that provides the right kind of struggle and a support system to help you avoid the wrong kind.**

This is [EpicReact.Dev](https://epicreact.dev)

It's not a candle. It's a freaking spotlight.

EpicReact is not just a "happy path" video course that will leave you with all the pieces, no instructions, and no support telephone number. EpicReact is a series of workshops that shows you the tools you can use, how to use them, and gives you experience with the right kind of struggle. The kind that helps you side-step distracting and wasteful side-quests and promotes the reward bearing ones. The kind of struggle that requires work on your part, but work that gives you actual learning retention. It's the kind of struggle that gives you a support system for those times when you're really stuck and things aren't quite clicking for you.

Stop stumbling around in React learning darkness. I've got a spotlight for you so you don't step on any legos or poor innocent dogs. I'm excited to give you the _right_ kind of learning struggle on [EpicReact.Dev](https://epicreact.dev).

Epic React is your learning spotlight so you can ship harder, better, faster, stronger.

Test Post With Video

Get my free 7-part email course on React!

More Articles

Why I Love React

How to Test React.useEffect

A deep dive on forms with modern React

Stop Stumbling Around in React Learning Darkness