[00:00] All right, let's get some good dad jokes in here. Come on. Let's get some really good ones new joke You can't run through a campsite. You can only ran because it's past tense Yeah, yeah, I'm good with that. That one's good.

[00:15] What do you call a pig with three eyes? Pig. These are hilarious. Why can't a bicycle stand on its own? It's too tired.

[00:24] Oh, that's good. That's good. I should submit a joke. You know, you can submit jokes. That's pretty cool.

[00:30] Let's get one more. How much does a hipster weigh? An Instagram, oh my gosh. That's great, yeah, that one's good. Right, Cody?

[00:38] Yeah, that's hilarious. Good stuff. I hope that Cody's been fun and helpful to you as you've been working through this material. And Cody's a little hand-holding, he likes to be hand-holding, but you are learning stuff as you're going through, even though Cody is telling you where and what to do. I definitely, if you're doing that elaboration and feedback section of each one of these exercises then you will remember this stuff and that's what's really important.

[01:08] So hopefully this gave you a little bit of a laugh, a chuckle to carry you on into the rest of the exercises. So keep it up, you're doing great, and we'll see you around on Epic React.



Test Post With Video

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

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

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

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

So, in the demo below, try this:

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

<ReactAndStaleClosuresDemo />

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

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

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

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

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

export {Post}
```

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

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

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

  toggleLike(post)
}
```

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

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

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

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

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

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

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

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

    toggleLike(props.post)
  }

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

export {Post}
```

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

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

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

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

## Simulate the old default

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

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

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

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

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

    toggleLike(postRef.current)
  }

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

export {Post}
```

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

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

Here's a naive implementation of `debounce`:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## Conclusion

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

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

How React Uses Closures to Avoid Bugs

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

useSyncExternalStore: Demystified for Practical React Development

Here's a form in `JSX`:

```jsx
function UsernameForm({onSubmitUsername}) {
  function handleSubmit(event) {
    event.preventDefault()
    onSubmitUsername(event.currentTarget.elements.usernameInput.value)
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor="usernameInput">Username:</label>
        <input id="usernameInput" type="text" />
      </div>
      <button type="submit">Submit</button>
    </form>
  )
}
```

Let's type that `handleSubmit` function. Here's how some people do it (copying this approach from some blog posts and "semi-official guides" I've seen):

```tsx
function handleSubmit(event: React.SyntheticEvent<HTMLFormElement>) {
  event.preventDefault()
  const form = event.currentTarget
  const formElements = form.elements as typeof form.elements & {
    usernameInput: {value: string}
  }
  onSubmitUsername(formElements.usernameInput.value)
}
```

The reason we have to have the `as` there is because TypeScript isn't quite smart enough to know what elements we're rendering in our form, so we have to use the type cast which I'm not a fan of, but you gotta ship right?

My first improvement to this is to change that `usernameInput` type:

```diff
-     usernameInput: {value: string}
+     usernameInput: HTMLInputElement
```

Definitely take advantage of the type it actually is rather than just cherry-picking the values you need.

The second improvement is:

```diff
- function handleSubmit(event: React.SyntheticEvent<HTMLFormElement>) {
+ function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
```

Incidentally, at the time of this writing, there's no substantive difference in those types, but I prefer to be more clear and accurate with the name of the type, so that's what we're going to go with.

So here we are now:

```tsx
function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
  event.preventDefault()
  const form = event.currentTarget
  const formElements = form.elements as typeof form.elements & {
    usernameInput: HTMLInputElement
  }
  onSubmitUsername(formElements.usernameInput.value)
}
```

But even with those changes, I'm not a fan of this for three reasons:

1. It's a bit verbose and distracts from the main purpose of the function 2. If I need to use that `form` anywhere else, I'll either have to duplicate the    code or extract the type and cast it everywhere I use the form. 3. I don't like seeing `as` in my code because it is a signal that I'm telling    the TypeScript compiler to pipe down (be less helpful). So I try to avoid it    when possible. And it is possible!

Keep in mind that _we're_ the ones telling TypeScript what that `event.currentTarget` type is. We tell TypeScript when we specify the type for our `event`. Right now that's set to `React.FormEvent<HTMLFormElement>`. So we're telling TypeScript that `event.currentTarget` is an `HTMLFormElement` but then we immediately tell TypeScript that this isn't quite right by using `as`. What if instead we just tell TypeScript more accurately what it is at the start? Yeah, let's do that.

```tsx
interface FormElements extends HTMLFormControlsCollection {
  usernameInput: HTMLInputElement
}
interface UsernameFormElement extends HTMLFormElement {
  // now we can override the elements type to be an HTMLFormControlsCollection
  // of our own design...
  readonly elements: FormElements
}
```

So in reality, our `form` is an `HTMLFormElement` with some known `elements`. So we extend `HTMLFormElement` and override the `elements` to have the elements we want it to. The `HTMLFormElement['elements']` type is a `HTMLFormControlsCollection`, so make our own version of that interface as well.

With that, now we can update our type and get rid of all the type casting!

Here's the whole thing altogether:

```tsx
import * as React from 'react'

interface FormElements extends HTMLFormControlsCollection {
  usernameInput: HTMLInputElement
}
interface UsernameFormElement extends HTMLFormElement {
  readonly elements: FormElements
}

function UsernameForm({
  onSubmitUsername,
}: {
  onSubmitUsername: (username: string) => void
}) {
  function handleSubmit(event: React.FormEvent<UsernameFormElement>) {
    event.preventDefault()
    onSubmitUsername(event.currentTarget.elements.usernameInput.value)
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor="usernameInput">Username:</label>
        <input id="usernameInput" type="text" />
      </div>
      <button type="submit">Submit</button>
    </form>
  )
}
```

So now:

1. the type information is removed from the `handleSubmit` code, allowing us to    focus on what the function is doing. 2. If we need to use this `form` somewhere else, we can give it the    `UsernameFormElement` type and get all the type help we need. 3. We don't have to use a type cast, so TypeScript can be more useful for us.

I hope that's helpful to you!

Excellent TypeScript definitions for your React forms

How to type a React form onSubmit handler

React is a JavaScript library for creating user interfaces and managing user interactions. React is used primarily for building web applications in browsers, but the component model is so powerful that it can be used to create native mobile and desktop applications, images, PDFs, terminal applications, and much more.

As a result of React’s success with the component-based model of interface composition, many other UI libraries and frameworks have adopted this approach with their own flare. However, React has been *(by a large margin)* **the dominant way** to build user interfaces for many years now and will likely remain that way as long as you or I continue to develop software on the web.

Let’s go a little deeper and look at the pieces that make up React.

## React’s core building block

The foundational component of user interfaces built with React are elements:

```tsx
import { createElement } from 'react'

const element = createElement('button', { onClick: () => console.log('clicked!') }, 'Click me!')
```

If we inspect the element that React’s created, it looks like this:

```tsx
{
  "$$typeof": Symbol(react.element),
  "type": "button",
  "key": null,
  "ref": null,
  "props": {
    "onClick": () => console.log('clicked!'),
    "children": "Click me!"
  },
  "_owner": null,
  "_store": {}
}
```

This object (which I call a “UI descriptor”) is used to generated UI that’s native to the environment it’s rendered in. In our case we want to generate UI for the browser, so we use the React DOM package to convert this UI into DOM nodes that the browser can understand.

This separation between React elements and DOM elements is part of what makes your React knowledge (or even code) portable to environments other than the browser.

## JSX

Using the `createElement` API directly is not very ergonomic, so when React was initially announced it came with a special lightweight syntax addition to JavaScript to make it easier to create elements. With that syntax, you can create that same button like this

```tsx
const element = <button onClick={() => console.log('clicked!')}>Click me!</button>
```

Because this is a syntax addition that browsers don’t natively run, you need to compile your code before the browser can interpret it. You can technically do this right in the browser (I built an app I used daily for years that did things this way actually), but it’s not optimal.

In most apps, you’ll be using a tool to convert your JavaScript anyway. You’ll at least want a minifier to reduce the amount of text you send over the network and likely a bundler to reduce the number of files the browser has to load. On top of this, especially in anything serious, you’ll want to use TypeScript which supports JSX natively.

Writing UI in this way is delightful. It takes most developers just a few hours of study and practice to understand how JSX translates to regular JavaScript, then you can be highly effective working in the syntax because it’s basically just JavaScript anyway.

## Reusable elements: Components

As React is written in JavaScript, you can of course create parameterized functions which return React elements. React has formalized this in something called a component and it’s how you can create custom React elements. To top it off, you can parameterize these components using something called “props” which is an object received by your component:

```tsx
function ClickMeButton(props) {
  return <button onClick={props.onClick}>Click me!</button>
}
```

You can then create that element like other elements:

```tsx
const element = <ClickMeButton onClick={() => console.log('clicked!')} />
```

Here’s what that element object looks like:

```tsx
{
  "$$typeof": Symbol(react.element),
  "type": ClickMeButton,
  "key": null,
  "ref": null,
  "props": {
    "onClick": () => console.log('clicked!')
  },
  "_owner": null,
  "_store": {}
}
```

When React is ready to render this UI, it will call your function with the props to retrieve the other elements it needs to render.

This API enables React components to compose together in beautifully powerful ways that a decade later we’re still benefitting from. It enables us to build highly reusable abstractions. For example, you could package up all the accessibility requirements for a tabs UI in a couple components that work together and offer something like this:

```tsx
<Tabs defaultValue="account">
  <TabsList>
    <TabsTrigger value="account">Account</TabsTrigger>
    <TabsTrigger value="password">Password</TabsTrigger>
  </TabsList>
  <TabsContent value="account">Make changes to your account here.</TabsContent>
  <TabsContent value="password">Change your password here.</TabsContent>
</Tabs>
```

Composition is the name of the game when it comes to React, even between server-only code which generates the UI and client-side code which makes the UI interactive. Speaking of making the UI interactive…

## Updating UIs with React

React not only helps you generate the initial UI, but also manage changes to that UI over time. Whether you’re building an interactive experience for users, or a dashboard that updates in the background, React will help you keep your UI up-to-date.

Data is used to generate the UI. When that data can change over time, we call it state. In React, you can manage this state a number of ways, but the primary mechanism is via a function called `useState` . This function can only be used within custom components so React knows what UI to update when the state changes:

```tsx
function Counter() {
  const [count, setCount] = useState(0)
  const increment = () => setCount((c) => c + 1)
  return <button onClick={increment}>Current Count: {count}</button>
}
```

Whenever the user clicks the button, `setCount` is called which notifies React that the state value needs to be changed and React needs to retrieve the new elements based on that new value.

As mentioned, there are several ways to manage state built-into React, but the basic idea is always the same: an update happens, React calls the component again with the updated value, React compares what you return this time with what was returned last time and updates the DOM accordingly. In our case the `textContent` of the `button` will be updated each time the button is clicked.

## So, what is React?

Like I said at the start, React is a JavaScript library for creating user interfaces and managing user interactions. There are of course more things to talk about when it comes to building web applications with the most widely used tool in the business with the biggest ecosystem, but this is as far as we’ll take it today.

I’m going to be publishing a lot of articles diving deeper in these aspects and others (so sign up to be notified when they become available!).

React has evolved over the last more than decade since its original release, but the core concept of composability has remained and been pushed further and further over the years. I’ve never been more excited about building applications with React and it just keeps getting better. Thanks for joining me for the ride!

Let's contextualize the most widely used UI framework in the world: React.

Whether you're brand new to building dynamic web applications or you've been working with React for a long time, let's contextualize the most widely used UI framework in the world: React.

Test Post With Video

Get my free 7-part email course on React!

More Articles

How React Uses Closures to Avoid Bugs

useSyncExternalStore: Demystified for Practical React Development

How to type a React form onSubmit handler

What is React?