react.gg

/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, _provideComponents(), props.components);
  return _jsx(_components.p, {
    metastring: "",
    children: "To enable React to run in web workers"
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, _provideComponents(), props.components);
  return _jsx(_components.p, {
    metastring: "",
    children: "To allow React to prioritize high-priority tasks (like user input) over low-priority tasks (like rendering lists)"
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, _provideComponents(), props.components);
  return _jsx(_components.p, {
    metastring: "",
    children: "To make React compatible with multiple versions running simultaneously"
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, _provideComponents(), props.components);
  return _jsx(_components.p, {
    metastring: "",
    children: "To replace class components with function components"
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, _provideComponents(), props.components);
  return _jsx(_components.p, {
    metastring: "",
    children: "To mark certain state updates as higher priority"
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, _provideComponents(), props.components);
  return _jsx(_components.p, {
    metastring: "",
    children: "To pause all React rendering temporarily"
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, _provideComponents(), props.components);
  return _jsx(_components.p, {
    metastring: "",
    children: "Tells React to not block any other higher-priority events that may occur during the state update"
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, _provideComponents(), props.components);
  return _jsx(_components.p, {
    metastring: "",
    children: "To enable concurrent mode across the entire application"
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx, jsxs: _jsxs} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    code: "code"
  }, _provideComponents(), props.components);
  return _jsxs(_components.p, {
    metastring: "",
    children: ["Both do the same thing, but one is coupled to an ", _jsx(_components.code, {
      metastring: "",
      inline: true,
      children: "isPending"
    }), " value"]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx, jsxs: _jsxs} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    code: "code"
  }, _provideComponents(), props.components);
  return _jsxs(_components.p, {
    metastring: "",
    children: [_jsx(_components.code, {
      metastring: "",
      inline: true,
      children: "React.startTransition"
    }), " is sync while the one from ", _jsx(_components.code, {
      metastring: "",
      inline: true,
      children: "useTransition"
    }), " is async"]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx, jsxs: _jsxs} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    code: "code"
  }, _provideComponents(), props.components);
  return _jsxs(_components.p, {
    metastring: "",
    children: ["You can't call the one from ", _jsx(_components.code, {
      metastring: "",
      inline: true,
      children: "useTransition"
    }), " conditionally"]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, _provideComponents(), props.components);
  return _jsx(_components.p, {
    metastring: "",
    children: "Nothing"
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p"
  }, _provideComponents(), props.components);
  return _jsx(_components.p, {
    metastring: "",
    children: "Transitions don't work with inputs"
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx, jsxs: _jsxs} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    code: "code"
  }, _provideComponents(), props.components);
  return _jsxs(_components.p, {
    metastring: "",
    children: ["We should use ", _jsx(_components.code, {
      metastring: "",
      inline: true,
      children: "React.startTransition"
    }), " instead of ", _jsx(_components.code, {
      metastring: "",
      inline: true,
      children: "useTransition"
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx, jsxs: _jsxs} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    code: "code"
  }, _provideComponents(), props.components);
  return _jsxs(_components.p, {
    metastring: "",
    children: [_jsx(_components.code, {
      metastring: "",
      inline: true,
      children: "useTransition"
    }), " needs a default value when we invoke it"]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx, jsxs: _jsxs} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    code: "code"
  }, _provideComponents(), props.components);
  return _jsxs(_components.p, {
    metastring: "",
    children: [_jsx(_components.code, {
      metastring: "",
      inline: true,
      children: "useDeferredValue"
    }), " doesn't come with its own setter function"]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx, jsxs: _jsxs} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    code: "code"
  }, _provideComponents(), props.components);
  return _jsxs(_components.p, {
    metastring: "",
    children: ["We don't need ", _jsx(_components.code, {
      metastring: "",
      inline: true,
      children: "useState"
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


/*@jsxRuntime automatic @jsxImportSource react*/
const {jsx: _jsx, jsxs: _jsxs} = arguments[0];
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    code: "code"
  }, _provideComponents(), props.components);
  return _jsxs(_components.p, {
    metastring: "",
    children: ["We should pass ", _jsx(_components.code, {
      metastring: "",
      inline: true,
      children: "searchQuery"
    }), " to the ", _jsx(_components.code, {
      metastring: "",
      inline: true,
      children: "Invoices"
    }), " component instead of ", _jsx(_components.code, {
      metastring: "",
      inline: true,
      children: "deferredSearchQuery"
    })]
  });
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? _jsx(MDXLayout, Object.assign({}, props, {
    children: _jsx(_createMdxContent, props)
  })) : _createMdxContent(props);
}
return {
  default: MDXContent
};


Concurrent Rendering

Welcome to reactgg, the interactive way to master Modern React.

When we started making this course, our goal was ambitious – make it the best programming course ever created. Over a year and a half later, we couldn't be happier with how it turned out.

Before we dive in, here are some things to help you get the most out of the course.

First, despite the dopamine rush you got when you gave us money, you haven't actually accomplished anything yet. I beg of you – don't let this course collect dust with all those Udemy courses you've purchased over the years.

Second, learning new things is hard. We've tried our best to make this course as simple and as enjoyable as possible – but at the end of the day, you're going to have to sit down and put in the work. It'll be hard, but if you do, and you're able to get through the course, I promise you you'll know more React than most senior React developers.

Third, is how we think about education. A lot of Twitter heads will preach complexity and sell you their course as the cure. That's not our thing. We're more interested in helping you establish a first-principles mental model for how to think in React than we are teaching you how to glue a bunch of npm packages together.

You can see that in how we've structured the course. Each time you're introduced to a new topic, you're given some text and a video about that topic. From there, once you've gone through both (and we recommend you start with the text first and then watch the video as a review), you're given a quiz as a gentle test of your understanding. 

If you find the quiz to be difficult, go back through the text and video one more time. The entire course is linear, meaning each section builds on top of the next. If you move on before feeling comfortable, it'll just get worse. 

Finally, the most important part, before you move onto the next section you'll be given a collection of challenges optimized for scenarios you'd see in real life. If you're able to get through all of these, you can feel confident that you're able to move on. And if at any point you get stuck and aren't sure what to do next, create a new thread and we'll be there to help.

As is, the course is about 90% done with the remaining section coming out over the next few months. So you don't have to keep checking in, we'll send you email updates when new sections go live.

This course wasn't cheap, and the opportunity cost of your time going through it is even more expensive. We don't take that for granted and we hope it lives up to the bar we've set for ourselves. 

Good luck.

\- [Tyler](https://twitter.com/tylermcginnis), [Lynn](https://twitter.com/lynnandtonic), [Ben](https://twitter.com/benadam11), and [Alex](https://twitter.com/alexbrown40)

Getting Started

Welcome

Believe it or not, when React first launched, it was... [not well received](https://news.ycombinator.com/item?id=5789055).

Developers <Emph color="var(--blue)">really</Emph> didn't like it. And at first glance, why would they? It was drastically different than anything that had come before it.

<StaticTweet
  handle="cowboy"
  name="Ben Alman"
  children="Facebook: Rethink established best practices™"
  date="May 29th, 2013"
  avatar="https://ui.dev/images/courses/react/ben_alman.jpg"
/>

So the question is, how in the world did React go from sentiments like this, to being universally loved and <i>mostly</i> respected?

To answer that, we need to go back to before React was created.

At the time, building for the web was... different. jQuery, Backbone, and Angular dominated discussion.

jQuery was the most popular way to build for the web. It embraced websites for what they truly were, a tree of DOM nodes. With jQuery, the state of your application lived inside the DOM. Whenever you wanted to update that state, you'd imperatively traverse the DOM, find the node you wanted to update, then update it. Needed to respond to an event? Again, traverse the DOM, find the node, then add an event listener to it.

<Jquery />

jQuery revolutionized building for the web by both creating a simple _and_ unified abstraction over manipulating the DOM that worked in _any_ browser - regardless of typical browser compatibility issues.

Ironically, jQuery's biggest blessing was also its biggest curse. Turns out, relying on shared mutable state was a bad idea.

With jQuery, what started out as a simple way to update DOM state, typically devolved into a mess of <Emph color="var(--orange)">spaghetti</Emph> like mutations that were both hard to predict and keep track of if you weren't careful.

What jQuery needed was something that encouraged a little more structure. Something that gave a _backbone_ 😎 to our applications.

Backbone.js invented the Model-View-Controller pattern. That's a joke, but it was the first popular JavaScript framework that embraced the traditional software design pattern and brought it to building for the web.

In just 2,000 lines of code, Backbone allowed you to decouple your application's state from the DOM. Instead of living in the DOM, Backbone state lived inside of its "Models". From there, whenever a Model changed, all the Views that cared about that Model's state would re-render.

<Backbone />

That was it. Backbone's entire philosophy was to be as minimal and as unopinionated as possible. So much so, that the default implementation of Backbone's method responsible for rendering the View was a no-op. Meaning it was entirely up to you to implement your own View and templating strategy.

From the backbone [source code](https://github.com/jashkenas/backbone/blob/master/backbone.js#L1372).

```js
/*
  render is the core function that your view
  should override, in order to populate its
  element (`this.el`), with the appropriate HTML.
*/

render: function() {
  return this;
}
```

But you know what wasn't minimal and unopinionated? Angular.js

The idea was simple. What if HTML was... more powerful.

With Angular.js, you got everything you'd ever want - and more, much more - out of the box. <Emph color="var(--yellow)">Two way data binding</Emph>, <Emph color="var(--purple)">data filters</Emph>, <Emph color="var(--green)">routing</Emph>, <Emph color="var(--red)">controllers</Emph>, <Emph color="var(--pink)">dependency injection</Emph>, <Emph color="var(--orange)">templates</Emph>, literally a <Sparkle>mini version of jQuery</Sparkle>.

Angular.js changed the game because it was a true, opinionated, all in one framework for building web applications.

You need to remember the environment we were in here too. This was 2011. Being a pure "Front end developer" was much more uncommon than it is today. The highly opinionated nature of Angular.js was convenient for back-end developers who were given the unfortunate task of working on the front-end. This wasn't as uncommon as you might expect and it fueled Angular.js's popularity.

The problem, among other things, was that Angular.js loved two-way data binding. It was Angular's way of updating the view whenever the model changed, and updating the model, whenever the view changed.

<Angular />

In theory, this was nice because you didn't have to worry about doing manual DOM manipulation yourself. In practice, well, implicit state changes usually lead to code that is both hard to follow _and_ hard to debug. It also led to performance issues since Angular.js had to constantly scan your app looking for state changes.

Now, though they were the most popular, building for the web consisted of more than just jQuery, Backbone, and Angular. But regardless, the majority of these post jQuery frameworks had one thing in common, Models. These Models were essentially just observable objects that synced with the View - as we saw with Backbone, and in some cases - Views that could sync back with Models - as we saw with Angular.js.

The problem was this pattern encouraged mutation, and naturally, mutation tends to increase complexity. But what if you could avoid this problem entirely? Now obviously you can't completely avoid mutations, but could you create an abstraction which minimized its negative effects?

This is at the heart of what React tries to do.

One of the core innovations of React was that they made the View a function of your application's State. Often represented as `v = f(s)`.

<ReactViewEquation />

All you have to do is worry about how the state in your application changes, and React handles the rest.

But this was really only half the picture. The real innovation happened when you encapsulated this idea into a proper component based API. By doing so, the same intuition you have about creating and composing together functions can directly apply to creating and composing components. However, instead of composing functions together to get some value, you can compose components together to get some UI.

<ReactView />

To truly embrace a component based API, React needed a way to allow you to describe what the UI for a component would look like from inside the component itself. This is where most of the initial hate for React came from and it had to do with React's interpretation of the "Separation of Concern's" principle.

If you're not familiar, "Separation of Concerns" is a software design principle for "separating a computer program into distinct sections". Historically the way you adhered to this on the web was to have your HTML separate from your CSS which was separate from your JavaScript.

<SeparationOfConcerns />

But React had a... different interpretation.

In React's opinion, separating your HTML from your CSS from your JavaScript got you no where closer to true "separation of concerns". Instead, it was more just a separation of technology - which wasn't particularly valuable.

In React's opinion, anything that had to do with rendering the View - whether that be state, UI, and in some cases, even styling, was part of its concern.

<ReactConcerns />

To accomplish this, React needed a way to allow you to describe what the UI for a component would look like from inside the component itself. Well, describing UI is already a solved problem - that's what HTML is really good at. But you can't mix HTML and JavaScript, right?

<Sparkle>Why not?</Sparkle> This thinking led to the creation of JSX - a wonderful lovechild of HTML and JavaScript that allows you to write HTML-ish looking syntax directly inside of JavaScript.

```jsx
function Profile({ user }) {
  return (
    <div className="profile">
      <Avatar username={user.avatar} />
      <Bio text={user.bio} />
      <ul>
        {user.preferences.map((preference) => (
          <li>
            <Setting
              key={preference.id}
              preference={preference}
            />
          </li>
        ))}
      </ul>
    </div>
  );
}
```

What made JSX different was it combined the power and expressiveness of JavaScript with the readability and accessibility of HTML. If you were already comfortable with both JavaScript and HTML (which you probably were, if you were building web apps), then you could get up to speed with JSX in a matter of minutes.

Yes, it was weird, and different, and most people hated it at first, but once you used it in an actual app, it became clear that React was onto something with their interpretation of the Separation of Concerns principle.

Not only that, but by embracing both JSX and React's component based API, all of a sudden what used to require imperative, operational like code, could be abstracted behind a declarative API. This not only enabled a better developer experience, but also a vibrant ecosystem of [third party components](https://github.com/brillout/awesome-react-components).

So that was React in 2013. What's different today?

From a philosophical perspective, honestly not much. You still create components which contain or receive everything they need to render the UI, then you compose those components together to get your application. Though the API for doing this has changed over the years as JavaScript has matured, fundamentally, things are still the same.

What has changed though, is _how_ React is used. From about 2014 - 2020, React was used (in conjunction with React Router), to primarily create single page applications. More recently, React has taken on a different role – that of a UI primitive.

I know it seems strange, but "metaframeworks" like [Next.js](https://nextjs.org/), [Remix](https://remix.run), and [Astro](https://astro.build/) have gained popularity by treating React as a sort of UI primitive and building on top of it with new features like server side rendering, intelligent bundling, route pre-fetching, and more.

But regardless of _how_ you use React, this course was designed to teach you React from first principles, so you'll be able to use it in any context.

Why React?

# What problems was React designed to solve?

---

- [x] Complexity caused by implicit state changes

- [ ] HTML not being powerful enough

- [x] Unpredictable DOM mutations

- [x] Lack of reusable components

---

The goal of React was to make updating the DOM simple and predictable. They accomplished this by moving state out of the DOM and into reusable components. 

# What are the advantages of using React? 

---

- [ ] Smaller bundle sizes

- [x] Rich ecosystem of 3rd party components

- [x] Declarative API

- [x] Your view becomes a function of your application's state

---

While it doesn't tout the smallest bundle size, the benefits usually outweigh the cost.

# What does `view = f(state)` mean? 

---

- [x] The view will always reflect the current state

- [x] The view can be updated by changing the state

- [ ] The view holds the application state

- [ ] The view modifies the state

---

In React, when you update the state, the DOM is automatically updated, which ensures that the view (aka the DOM) always reflects the current state of your function.

# How does React separate concerns?

---

- [ ] By separating style, markup, and behavior

- [x] By separating behavior into reusable components

- [ ] By separating DOM from HTML

- [ ] By separating code into smaller bundles

---

Rather than adhering to the traditional separation of concerns (style, markup and behavior), a React component contains everything necessary to render a piece of UI.

You won't get very far into learning React until you hear it – _React is <Sparkle>declarative</Sparkle>_. But, what does that even mean? If you try to dive deeper, you inevitably come across a definition that looks something like this, comparing it to imperative programming.

<Definition header="Imperative vs Declarative Programming" description={<p>Imperative programming is <b>how</b> you do something, and declarative programming is more like <b>what</b> you do.</p>} />

That definition makes perfect sense... once you actually know the difference between imperative and declarative programming — but there's a good chance you don't, which is why you're reading this.

It’s like trying to answer _What came first, the chicken or the egg?_ except everyone seems to think the chicken did, but you don’t even like eggs, and you’re confused. Combine this frustration with the bastardization of the actual word “declarative” to basically just mean [good](https://twitter.com/jergason/status/699379381127368704) and all of a sudden your imposter syndrome is tap dancing on your confidence, and you realize you don’t even like programming that much.

The hard part about this topic is, as my friend [Merrick](https://twitter.com/iammerrick/status/699373002249498624) has observed, it's one of those things you have an intuition about, but can’t seem to explain. Vibe driven development, if you will.

So now, after years of teaching this topic, I've found that the most effective way to explain it seems to be with a combination of metaphors and code samples.

First, let’s go back to the initial definition we made fun of.

<Definition header="Imperative vs Declarative Programming" description={<p>Imperative programming is <b>how</b> you do something, and declarative programming is more like <b>what</b> you do.</p>} />

There’s actually _some_ good information hidden in here. Let’s first see the merit in this definition by taking it out of the context of programming and look at a <Sparkle>real life</Sparkle> example.

You decide that you’ve been spending too much time arguing about *JavaScript Fatigue*™ and your husband deserves a nice date. You choose to go to Red Lobster since you’ve been listening to a lot of Beyoncé lately. You arrive at Red Lobster, approach the front desk and say…

<Definition
  header={"IMPERATIVE (HOW)"}
  description="I see that table located under the Gone Fishin’ sign is empty. My husband and I are going to walk over there and sit down."
/>

<Definition
  header={"DECLARATIVE (WHAT)"}
  description="Table for two, please."
/>

The imperative approach is concerned with <Emph color="var(--pink)">how</Emph> you’re actually going to get a seat. You need to list out the steps to be able to show <Emph color="var(--pink)">how</Emph> you’re going to get a table. The declarative approach is more concerned with <Emph color="var(--green)">what</Emph> you want, a table for two.

<CenterHeading>
  <span aria-label="confused emoji" role="img">🤨</span>
</CenterHeading>

...ok let's try another metaphor.

I’m going to ask you a question. I want you to think of both an __imperative__ response and a __declarative__ response.

“I’m right next to Wal-Mart. How do I get to your house from here?”

<Definition
  header={"IMPERATIVE"}
  description="Go out of the north exit of the parking lot and take a left. Get on I-15 going North until you get to the 12th street exit. Take a right off the exit like you’re going to Ikea. Go straight and take a right at the first light. Continue through the next light then take your next left. My house is #298."
/>

<Definition
  header={"DECLARATIVE"}
  description="My address is 298 West Immutable Alley, Eden, Utah 84310"
/>

Regardless of how I get to your house, what really matters is the car I drive. Am I going to drive an _imperative_ stick shift car or a _declarative_ automatic car? Enough metaphors?

Before we dive into the code, it’s important to realize that many declarative approaches have some sort of imperative abstraction layer.

Look at all of our examples:

<List
  items={[`The declarative response to the Red Lobster employee ("table for two, please") is assuming that the Red Lobster employee knows all of the imperative steps to get us to the table.`, "Knowing the address assumes you have some sort of GPS that knows the imperative steps of how to get to your house.", "An automatic car has some sort of abstraction layer over shifting gears."]}
/>

Now, we’re going to attempt to take the leap from metaphorical happy land to real-world code land. To make the jump more graceful, let’s look at some programming languages that are inherently declarative versus those which are more imperative by nature.

<List
  header="IMPERATIVE"
  items={[`C`, "C++", "Java"]}
  unordered
/>

<List
  header="DECLARATIVE"
  items={[`HTML`, "SQL"]}
  unordered
/>

<List
  header="~BOTH"
  items={[`JavaScript`, "C#", "Python"]}
  unordered
/>

Think about your typical SQL or HTML code,

```sql
SELECT * FROM Users WHERE Country='Mexico';
```

<p className="my-6" />

```html
<article>
  <header>
    <h1>Declarative Programming</h1>
    <p>Sprinkle Declarative in your verbiage to sound smart</p>
  </header>
</article>
```

<p className="mb-6" />

By glancing at both examples, you have a clear understanding of what is going on. They’re both declarative. They’re concerned with <Emph color="var(--green)">what</Emph> you want to be done, rather than <Emph color="var(--pink)">how</Emph> you want it done.

You’re describing what you’re trying to achieve, without instructing how to do it. The implementation of selecting all of the users who live in Mexico has been abstracted from you. You’re not concerned with how the web browser is parsing your `article` element and displaying it to the screen.

Your <Emph color="var(--green)">what</Emph> is _Mexican users_ or a _new header_ and _paragraph_ on your website.

So far, so good. Let’s dive into some more practical JavaScript examples now.

Here are 3 interview type questions. We're going to answer them <Emph color="var(--pink)">imperatively</Emph>, as if we're focused on <Emph color="var(--pink)">how</Emph>.

<CenterHeading>1.</CenterHeading>

Write a function called `double` which takes in an array of numbers and returns a new array after doubling every item in that array – `double([1,2,3]) // [2,4,6]`.

```js
function double(arr) {
  let results = [];
  for (let i = 0; i < arr.length; i++) {
    results.push(arr[i] * 2);
  }
  return results;
}
```

<CenterHeading>2.</CenterHeading>

Write a function called `add` which takes in an array and returns the result of adding up every item in the array – `add([1,2,3]) // 6`

```js
function add(arr) {
  let result = 0;
  for (let i = 0; i < arr.length; i++) {
    result += arr[i];
  }
  return result;
}
```

<CenterHeading>3.</CenterHeading>

Using jQuery (or vanilla JavaScript), add a `click` event handler to the element which has an `id` of `btn`. When clicked, toggle (add or remove) the `highlight` class as well as change the text to `Add Highlight` or `Remove Highlight` depending on the current state of the element.

```js
$("#btn").click(function () {
  $(this).toggleClass("highlight");
  $(this).text() === "Add Highlight"
    ? $(this).text("Remove Highlight")
    : $(this).text("Add Highlight");
});
```

<div className="mb-16" />

By examining what all three of these imperative examples have in common, we’ll be able to better identify what actually makes them imperative.

<List
items={[
`The most obvious commonality is that they’re describing <b>HOW</b> to do something. In each example, we’re either explicitly iterating over an array or explicitly laying out steps for how to implement the functionality we want.`,
`This one might not be as obvious if you’re not used to thinking in the <i>declarative</i> or even more specifically <i>functional</i> way. In each example, we’re mutating some piece of state.`,
`This one is a bit subjective, but to me, the code above isn’t very readable. I can’t just glance at the code and understand what’s going on. My brain needs to step through the code just as an interpreter would while also taking into account the context in which the code lives (another negativity of mutable data).`,
]}
/>

Now, let's take a look at some <Emph color="var(--green)">declarative</Emph> examples. The goal is to fix all the problems from above. So each example needs to describe <Emph color="var(--green)">what</Emph> is happening, can’t mutate state, and should be readable at a glance.

<CenterHeading>1.</CenterHeading>

Write a function called `double` which takes in an array of numbers and returns a new array after doubling every item in that array – `double([1,2,3]) // [2,4,6]`.

```js
function double(arr) {
  return arr.map((item) => item * 2);
}
```

<CenterHeading>2.</CenterHeading>

Write a function called `add` which takes in an array and returns the result of adding up every item in the array – `add([1,2,3]) // 6`

```js
function add(arr) {
  return arr.reduce((prev, current) => prev + current, 0);
}
```

<CenterHeading>3.</CenterHeading>

Add a `click` event handler to the element which has an `id` of `btn`. When clicked, toggle (add or remove) the `highlight` class as well as change the text to `Add Highlight` or `Remove Highlight` depending on the current state of the element.

```jsx
<Btn
  onToggleHighlight={handleToggle}
  highlight={highlight}>
    {buttonText}
</Btn>
```

Notice that in the first two examples we’re leveraging JavaScript’s built-in `map` and `reduce` methods. This goes back to what we saw earlier – most declarative solutions are an abstraction over some imperative implementation.

In every example we’re describing <Emph color="var(--green)">what</Emph> we want to happen rather than <Emph color="var(--pink)">how</Emph> (we don’t know how map and reduce are implemented, we also probably don’t care). We’re not mutating any state. All of the mutations are abstracted inside of `map` and `reduce`. It’s also more readable (once you get used to `map` and `reduce`, of course).

Now, what about the last example?

Well, I cheated a little bit and am using React — but note that all three imperative mistakes are still fixed. The real beauty of React is that you can create <Emph color="var(--green)">declarative</Emph> user interfaces – simply by describing <Emph color="var(--green)">what</Emph> you want your UI to look like based on your state.

Another less-spoken-of benefit to declarative code is that your program can be context-independent. This means that because your code is concerned with what the ultimate goal is— rather than the steps it takes to accomplish that goal — the same code can be used in different programs, and work just fine.

Look at all three of our examples above. We can consume both functions and component in any program we want. They’re program agnostic. This is hard to do with imperative code because often times, by definition, imperative code relies on the context of the current state.

<Aside title="Functional Programming" emoji="🫶" label="eyeball" accentColor="var(--pink)">

One thing that I didn’t go too far into is how functional programming is a
subset of declarative programming.

If you haven’t already, I highly recommend getting more familiar with functional programming techniques in JavaScript. Start with `.map`, `.reduce`, `.filter` and work your way up from there. Odds are there isn’t a lower hanging fruit to improve your codebase than making it more functional.

</Aside>

Before we end, here are some other definitions that I've found from around the web regarding Imperative vs Declarative programming that may be helpful.

<Aside emoji="📢" label="eyeball" accentColor="var(--blue)">
  Declarative programming is “the act of programming in languages that conform
  to the mental model of the developer rather than the operational model of the
  machine.”
</Aside>

<Aside emoji="📢" label="eyeball" accentColor="var(--green)">
  Declarative Programming is programming with declarations, i.e., declarative
  sentences.
</Aside>

<Aside emoji="📢" label="eyeball" accentColor="var(--brand-orange)">
  The declarative property is where there can exist only one possible set of
  statements that can express each specific modular semantic. The imperative
  property is the dual, where semantics are inconsistent under composition
  and/or can be expressed with variations of sets of statements.
</Aside>

<Aside emoji="📢" label="eyeball" accentColor="var(--brand-red)">
  Declarative languages contrast with imperative languages which specify
  explicit manipulation of the computer’s internal state; or procedural
  languages which specify an explicit sequence of steps to follow.
</Aside>

<Aside emoji="📢" label="eyeball" accentColor="var(--brand-purple)">
  In computer science, declarative programming is a programming paradigm that
  expresses the logic of a computation without describing its control flow.
</Aside>

<Aside emoji="📢" label="eyeball" accentColor="var(--brand-beige)">
  I draw the line between declarative and non-declarative at whether you can
  trace the code as it runs. Regex is 100% declarative, as it’s untraceable
  while the pattern is being executed.
</Aside>

Imperative vs Declarative Programming

# Imperative programming is focused on _what_ you do, and declarative programming is focused on _how_ you do it.

---

- [] true

- [x] false

---

It's the opposite! Declarative programming is focused on _what_ you do, and imperative programming is focused on _how_ you do it.

# Code that is declarative:

---

- [x] Is often an abstraction over imperative code

- [x] Is typically context independent

- [x] Is written primarily for humans, not computers

- [ ] Emphasizes _how_ code executes

---

Code that is declarative is often a (human readable) abstraction over imperative code, where its context is passed in so it only mutates internal state rather than changing the outside world.

# Code that is imperative:

---

- [x] Relies on context making it difficult to reuse

- [x] Gives procedural instructions on how to do something

- [ ] Is usually easily understood at a glance

- [x] Is explicit about the changes it wants to make

---

Because imperative code gives very explicit procedural instructions based on a specific context, it tends to be harder to reuse.

# What makes React Declarative? 

---

- [ ] It's easy to manipulate the DOM

- [x] It describes what the UI is based on state

- [ ] It allows you to trace the code as it runs

- [x] It is an abstraction over imperative code

---

React abstracts away the manual DOM updates allowing users to declaratively describe their UI based on the application's state.


# Would this code be considered imperative or declarative?

```js
const container = document.getElementById("container")
const btn = document.createElement("button")

btn.className = "btn active"
btn.onclick = () => {
  if (this.classList.contains("active")) {
    this.classList.remove("active")
    this.classList.add("inactive")
  } else {
    this.classList.remove("inactive")
    this.classList.add("active")
  }
}

container.appendChild(btn)
```

---

- [x] imperative

- [ ] declarative

---

It's a scale, of course, but this code would be closer to the imperative side of the scale since we're focused on _how_ (through explicit instructions) we add and remove the `active` class.

It may seem basic, but as a software developer, your primary job is to maximize the predictability of your program.

Think about it. The root cause of any bug you've ever experienced was because the expectations of the developer diverged from the reality of the program – i.e. the program was unpredictable.

<SoftwareBug />

Assuming this is true, it's not unreasonable to think that we should spend at least some time thinking of how we can make our programs more predictable. After all, a world in which our applications are entirely predictable is also a world in which bugs cease to exist.

To better figure this out, I think it would be beneficial to narrow our scope. _Make apps more predictable_ is too broad of a goal to be of any practical use. Instead, I think it's safe to assume that we can make our apps more predictable by making the individual pieces that make up our app more predictable – and what are those pieces? Usually they're functions.

A function is a process which takes some input, an argument, and calculates some output, a return value. Functions, by definition, are simple. The problem, as you're well aware, is nothing screws up the simplicity of a definition quite like the complexity of reality.

In reality, functions are often the junk drawer of your application. What often starts off as a simple, composable function, can, if you're not careful, transform into an unpredictable mess as your application grows.

In the real world, we can solve these sort of "eventually chaotic" scenarios by having a strict set of rules and then diligently adhering to them. What if we took the same approach here? Are there a set of rules we can make to keep our functions from becoming unpredictable over time?

To better answer that, let me ask a different question – what makes a function unpredictable? If we can answer this question, then we can create a set of rules to avoid those scenarios.

In my opinion, there are two big offenders – <Sparkle>side effects</Sparkle> and <Sparkle>inconsistent outputs.</Sparkle>

### Side Effects

Earlier we defined a function as _a process which takes some input, an argument, and calculates some output, a return value._

Any time a function does __anything__ other than this, whether through relying on state other than the input value it receives or creating an observable change to the program itself, it's said to have a side effect.

Take this simple function.

```js id="todos"
function addTodo(todo) {
  todos.push(todo);
}
```

It both <Hover id="todos" highlight="todos">relies on state</Hover> other than the input value <Hover id="todos" highlight="todo">it receives</Hover>, and it creates an observable change to the program itself (by mutating `todos`) – therefore, it has a side effect.

What about this function?

```js id="fetch"
function getGithubProfile(username) {
  return fetch(
    `https://api.github.com/users/${username}`
  ).then((res) => res.json());
}
```

It doesn't create an observable change to the program, but it does rely on <Hover id="fetch" highlight="res">state</Hover> other than the <Hover id="fetch" highlight="username">input value</Hover> it receives (state from an external API still counts). Therefore, this function has a side effect.

Now what about this one?

```js id="document"
function updateDocumentTitle(title) {
  document.title = title;
}
```

You probably get the idea by now. We're not relying on state other than the input value it receives, but we are creating an <Hover id="document" highlight="=">observable change</Hover> to the program itself. Therefore, another side effect.

So why are side effects bad? Well, they're not _bad_ – they're just unpredictable.

One problem is, because they depend on the context outside of their local environments, they're contextual to the current state of the application. If the state of the application changes, they'll behave differently.

Take this function for example.

```js
function calculateFinalPrice (price, qty) {
  const total = price * qty
  return total * (1 + TAX_RATE)
}
```

This function will only work in a program where `TAX_RATE` is both a variable and that variable is a decimal. If `TAX_RATE` gets mutated, or worse, deleted, `calculateFinalPrice` will behave differently – which by definition makes it unpredictable.

And with that, we have our first rule.

<Definition header="Rule #1" description="No Side Effects" />

### Inconsistent Outputs

The next culprit in making functions unpredictable are inconsistent (or a lack of) outputs.

If a function doesn't have a return value, it's unpredictable.

```js
thisIsUnpredictable()
soIsThis()
```

In this scenario, you can assume the function is either doing nothing (unlikely), or it has a side effect (breaking Rule #1).

Similarly, if a function, given the same input, doesn't consistently return the same output, it's also unpredictable.

```js
const friends = ["Ben", "Lynn", "Alex"]

friends.splice(0, 1) // ["Ben"]
friends.splice(0, 1) // ["Lynn"]
friends.splice(0, 1) // ["Alex"]
```

Given the same input (`0` and `1`), `splice` returns a different output each time – making it unpredictable.

<Aside emoji="🍎" title="For Comparison">

Unlike `.splice`, `.slice` is a similar array method that would be considered predictable.

```js
const friends = ["Ben", "Lynn", "Alex"]

friends.slice(0, 1) // ["Ben"]
friends.slice(0, 1) // ["Ben"]
friends.slice(0, 1) // ["Ben"]
```

Notice `.slice`, given the same input, always returns the same output. It also doesn't mutate the original array (no side effects), so it passes both our rules and is considered predictable.

</Aside>

There are a variety of built-in methods you probably use regularly that are unpredictable for this exact reason.

```js
Math.random() // 0.9511513628376609
Math.random() // 0.6547771399705873

Date.now() // 1665072516384
Date.now() // 1665072525093

const friends = ["Ben", "Lynn", "Alex"]
friends.push("Jeff") // 4
friends.push("Jeff") // 5
```

And it's not just built in methods that have this problem. Take the function for example. 

```js
function getGithubProfile(username) {
  return fetch(
    `https://api.github.com/users/${username}`
  ).then((res) => res.json());
}
```

We already know it's unpredictable because it breaks Rule #1. But beyond that, it's even more unpredictable because, given the same input, it will return an inconsistent output. Even if everything goes right, the promise we get back from `getGithubProfile` is different for each invocation.

```js
const p1 = getGithubProfile("tylermcginnis")
const p2 = getGithubProfile("tylermcginnis")

p1 === p2 // false
```

And worse, if something does go wrong, there are a variety of other things that _aren't_ the user's profile that might get returned.

So now we have our second rule.

<Definition header="Rule #2" description="Consistent Outputs" />

### The Benefits

It's obvious that writing functions that follow our rules will make them more predictable, and therefore, less susceptible to bugs. However, in doing so, there are some other non-obvious benefits as well.

<Emph color="currentColor">Composable</Emph>

Because these functions don't depend on the context of the application and instead receive their inputs via explicit arguments, they're entirely program agnostic and therefore, extremely composable and reusable.

You can take these functions and compose them into or reuse them in any application, and they'll Just Work™.

<Emph color="currentColor">Cacheable</Emph>

Because these functions always return the same output given a certain input, the results can be cached. There's no use in calling these functions more than once given the same input, since the output will always be the same.

Say we had an expensive `isPrime` function that calculated if a given number (`n`) was a [prime number](https://en.wikipedia.org/wiki/Prime_number).

```js
const isPrime = (n) => {
  if (n === 1) {
    return false
  }

  for (let i = 2; i <= Math.sqrt(n); i++) {
    if (n % i === 0) {
      return false
    }
  }

  return true
}
```

This function is entirely predictable. It doesn't contain any side effects and given the same input, it'll always return the same output.

In this scenario, it doesn't make sense to invoke `isPrime` more than once for a given number. `isPrime(997)` is always going to return `true` no matter how many times we run it. Because it's predictable, we can cache and reuse the result.

```js
let primeCache = {
  1: false
}

const isPrime = (n) => {
  if (typeof primeCache[n] === 'boolean') {
    return primeCache[n]
  }

  for (let i = 2; i <= Math.sqrt(n); i++) {
    if (n % i === 0) {
      primeCache[n] = false
      return false
    }
  }

  primeCache[n] = true
  return true
}

export default isPrime
```

```js
import isPrime from "./isPrime"

isPrime(997) // true
isPrime(997) // true (from cache)
isPrime(997) // true (from cache)
```

<Aside emoji="🤨" title="Wait a minute...">

For the observant reader, you may have noticed that `isPrime` is now technically an impure function since it depends on the context of the application – specifically, `primeCache`. This is a good example of how, in the real world, you can't always write pure functions.

With that said, notice that we've encapsulated `isPrime` and `primeCache` into their own module. The only way to modify `primeCache` is via `isPrime` and no other function in our application has access to or depends on `primeCache`. 

Even though `isPrime` is technically impure, it's about the purest impure function we can write and I'd still consider it (pragmatically) predictable.

</Aside>

<Emph color="currentColor">Testable</Emph>

Because these functions are free of side effects and don't depend on the context of the application, they're optimized for testing. You can simply test that, given a certain input, the output is consistent with what you'd expect.

<Emph color="currentColor">Readable</Emph>

Because these functions don't depend on the context of the application and are free of side effects, they're optimized for readability. The inputs are explicit, the outputs are explicit, and there are no surprises in between.

<Aside emoji="🌎" title="Pragmatic Predictability">

In an ideal world, we'd always write entirely predictable functions. The problem, of course, is we don't live in an ideal world. Here's how I think about maximizing predictability in an unpredictable world.

Whenever you have to write code that breaks one of our two rules, abstract it to its own function, then create clear rules for interacting with that function (similar to what we did earlier with our `isPrime` function).

Network requests are the perfect example of this. At face value, network requests are simple. You request some resource, wait a little bit, then you get it. In reality, it's not so simple. Race conditions, slow networks, outages, and opaque errors are just a few of the possible things that can go wrong.

However, if you're able to create a clear abstraction over that complexity, you can minimize the possible complications that it can have on your application as a whole.

</Aside>

### The Big Reveal

If it's not already obvious, this idea isn't a new concept that we've invented. Instead, we've essentially re-created the functional programming principle of <Sparkle>Pure Functions</Sparkle>. A function is considered pure if it contains no side effects and if, given the same input, it always returns the same output.

By embracing and striving to keep your functions pure, you'll naturally increase the predictability of your program while minimizing the amount of bugs it has.

So what does this have to do with React? Let's find out.

Pure Functions

# Is this a pure function?

```js
function getGameProgress(gameId) {
  return localStorage.getItem(gameId);
}
```

---

- [ ] yes

- [x] no

---

Among a few other reasons, if we call this function multiple times, we could get a different result each time – making it an impure function.

# Why isn't this a pure function?

```js
function upperCaseName(name) {
  return name.toUpperCase();
}
```

---

- [ ] Because it does string manipulation

- [ ] Because the output is not guaranteed to be the same for the same input

- [ ] Because `name` isn't guaranteed to be a string

- [x] It is a pure function

---

While it's true that we can't be sure that name is a string, that alone does not make it an impure function. It will still return the same result given the same input, and does not rely on external state.

---

# A pure function:

---

- [x] Always returns the same output for a given input

- [ ] Has side effects

- [x] Is composable

- [ ] Depends on external context

---

Since a pure function will always return the same output for a given input, they are predictable and easy to compose together. Impure functions with side effects, in contrast, are less predictable.

# Pure functions are:

---

- [x] Composable

- [x] Cacheable

- [x] Testable

- [x] (Usually More) Readable

---

By embracing and striving to keep your functions pure, you'll naturally increase the predictability of your program while minimizing the amount of bugs it has.


The Big Picture

One thing I love about React is that it feels like it's the answer to the question, _What would HTML look like if it were invented today?_

The primary benefit of HTML is that it allows us to create rich, structured markup in a declarative way. In contrast, the primary benefit of JavaScript is that it gives us a set of tools for managing the complexity of building an application – namely through features like the module system, scopes, closures, and anything else you'd expect from an actual programming language.

React, of course, is a lovechild of the two – giving you the declarative-ness of HTML with the feature set of JavaScript. But, what does that _actually_ look like.

Let's say we had some HTML.

```html
<aside>
  <h2>Authors</h2>
  <ul>
    <li>Tyler McGinnis</li>
    <li>Ben Adam</li>
    <li>Lynn Fisher</li>
  </ul>
</aside>
```

Now, say we wanted to re-use this HTML on multiple pages. How would we go about doing that? The most common way is with this neat trick.

<Aside emoji="🥲" title="How to Reuse HTML">

<Sparkle>"CMD + C" then "CMD + V"</Sparkle>

</Aside>

The ole' copypasta. It works, but... it's not ideal. In JavaScript, this is already a solved problem. We can put this code in a function, then put that function in a module, then import that function anywhere we want to use it.

If we were able to take those JavaScript features and apply them to our HTML, that might look something like this.

```jsx
export default function authors () {
  return <aside>
    <h2>Authors</h2>
    <ul>
      <li>Tyler McGinnis</li>
      <li>Ben Adam</li>
      <li>Lynn Fisher</li>
    </ul>
  </aside>
}
```

Believe it or not, this is essentially React.

I wasn't joking when I said React is the lovechild of HTML and JavaScript. If you've never seen a React component before, there's a good chance you're mildly horrified right now.

The first thing you'll notice is that a React component is just a function. Again, React loves JavaScript. The same mental model you have about functions can be directly applied to React components because, in the literal sense, they're just functions.

The _only_ change we need to make it a true React component is to capitalize the first letter of our function.

<CodePreview hideStrictModeToggle template="react">

```jsx App.jsx active
export default function Authors () {
  return <aside>
    <h2>Authors</h2>
    <ul>
      <li>Tyler McGinnis</li>
      <li>Ben Adam</li>
      <li>Lynn Fisher</li>
    </ul>
  </aside>
}
```

</CodePreview>

<Aside emoji="🚨" title="React Components vs DOM Elements">

The reason you need to capitalize the first letter of your component is so React knows it's a React component and not a normal DOM `element` – i.e. <InlineCode className="text-brand-blue">Footer</InlineCode> vs <InlineCode className="text-brand-green">footer</InlineCode>.

<span style={{marginRight: 3, display: "inline-block", height: 13, width: 13, background: "var(--blue)"}} /> React Component

<span style={{marginRight: 3, display: "inline-block", height: 13, width: 13, background: "var(--brand-green)"}} /> HTML Element

</Aside>

And now, because we've encapsulated this component inside its own module, anywhere where we want to re-use it we can just import it.

<CodePreview hideStrictModeToggle template="react" previewHeight="350px">

```jsx App.jsx active mark=1,7
import Authors from './Authors'

export default function About () {
  return <main>
    <h1>About Us</h1>
    <p>We write JavaScript and words about JavaScript.</p>
    <Authors />
  </main>
}
```

```jsx Authors.jsx
export default function Authors () {
  return <aside>
    <h2>Authors</h2>
    <ul>
      <li>Tyler McGinnis</li>
      <li>Ben Adam</li>
      <li>Lynn Fisher</li>
    </ul>
  </aside>
}
```

</CodePreview>

<Aside emoji="🧱" title="Using a Component">

Notice that we don't invoke `Authors` as if it's a normal function – i.e. `Authors()`. Instead, we treat it as if it were an HTML element, wrapping it in angle brackets – i.e. `<Authors />`.

</Aside>

There's a lot happening under the hood between when JavaScript reads the component and when the browser paints the UI to the screen, but know that the final output is probably what you'd expect – where React replaces the component with the description of the UI the component returns.

```html
<main>
  <h1>About Us</h1>
  <p>We write JavaScript and words about JavaScript.</p>
  <aside>
    <h2>Authors</h2>
    <ul>
      <li>Tyler McGinnis</li>
      <li>Ben Adam</li>
      <li>Lynn Fisher</li>
    </ul>
  </aside>
</main>
```

This is true regardless of how many components there are, or how deeply they're nested.

And since components are just functions, again, the same intuition you have about organizing functions and when to abstract logic to its own function can be directly applied to components.

If you don't yet have that intuition, following the [single responsibility principle](https://en.wikipedia.org/wiki/Single-responsibility_principle) is a decent barometer for when and where to create components. Namely, components (and functions) should do just one thing.

When you follow the Single Responsibility Principle, you're likely to end up with a lot of smaller components. Just like with functions, this isn't a bad thing. However, it can overwhelm your component directory if you're not careful.

Take this component for example.

```jsx
import Sidebar from './Sidebar'
import Timeline from './Timeline'
import Search from './Search'
import Trending from './Trending'
import Follow from './Follow'
import Footer from './Footer'

export default function Home () {
  return <main>
    <Sidebar />
    <Timeline />
    <Search />
    <Trending />
    <Follow />
    <Footer />
  </main>
}
```

It follows the single responsibility, but since we're creating a new file for each component, it's a bit messy.

Instead, here's a good rule of thumb you can follow. If you have a component that's being reused somewhere else, make it its own file. If not, just create it inside of whatever file you need it.

For example, we can refactor the code above like so – assuming `Timeline`, `Trending`, and `Follow` are only used inside of this `Home` component.

```jsx
import Sidebar from './Sidebar'
import Search from './Search'
import Footer from './Footer'

function Timeline () {
  ...
}

function Trending () {
  ...
}

function Follow () {
  ...
}

export default function Home () {
  return <main>
    <Sidebar />
    <Timeline />
    <Search />
    <Trending />
    <Follow />
    <Footer />
  </main>
}
```

***

<Aside emoji="🕊" title="React and Pure Functions">

A function is considered pure if it contains no side effects and if, given the same input, it always returns the same output.

By embracing and striving to keep your functions pure, you'll naturally increase the predictability of your program while minimizing the amount of bugs it has.

For this reason, React embraces pure functions and, as a rule, you need to make sure your components are always pure.

We'll learn all about strategies for this later on in the course, but as a sneak peek, just know that any side effects your component has should be wrapped inside of event handlers.

</Aside>

Components

# Which of the following are benefits of HTML?

---

- [x] It is declarative

- [x] It has semantic structure

- [ ] It gives us tools for managing application complexity

- [ ] It has a robust module system

---

HTML is great for declaratively structuring a document, but it lacks the power and expressivity of JavaScript. React components bring these together to give us a "more powerful HTML".

# Is this a valid React component? 

```jsx
export default function search() {
  return <div>
    <label htmlFor="search">Search</label>
    <input id="search" placeholder="Enter some text" />
  </div>
}
```

---

- [ ] yes

- [x] no

---

No, it is not. The function (component) name needs to be capitalized in order for React (JSX) to understand the difference between an HTML element and a component. 


# As a rule, every React component must follow the Single Responsibility Principle.

---

- [ ] true

- [x] false

---

There is no rule stating that every React component must follow the single responsibility principle. However, it is a good guideline to follow.

# What's wrong with this React component?

```jsx
import Authors from "./Authors"

export default function About () {
  localStorage.setItem('viewed_about', true)

  return <main>
    <h1>About Us</h1>
    <p>We write JavaScript and words about JavaScript.</p>
    <Authors />
  </main>
}
```

---

- [] nothing

- [] `main` should be capitalized

- [x] React components must be pure functions

--- 

React embraces pure functions and, as a rule, you need to make sure your components are always pure – `localStorage.setItem` makes it impure. 

We'll learn how to handle these situations later in the course, but for now, remember that ["_React’s rendering process must always be pure._"](https://react.dev/learn/keeping-components-pure#side-effects-unintended-consequences)

If I were to ask you "What is a React Component?", it wouldn't be unreasonable for you to say something like __a function that returns some UI__. And if that were your answer, though directionally correct, technically you'd be wrong.

The more accurate description would be a function that returns <Sparkle>a description of</Sparkle> the UI. Though that seems pedantic, it's an important distinction.

For the former to be true, we'd have to be returning literal HTML. Clearly that's not the case because we can't _literally_ have HTML inside of a JavaScript file. But if we're not returning HTML, what exactly are we returning?

<Definition
  header="Meet JSX"
  description="The magic behind having HTML-ish looking syntax directly inside of your JavaScript files"
/>

<CodePreview hideStrictModeToggle template="react" previewHeight="300px">

```jsx App.jsx active 
export default function WhatIsJSX () {
  return <main>
    <h1>This is JSX</h1>
    <h2>JSX <i>looks</i> like HTML</h2>
    <h4>(but it's not)</h4>
    <p>
      JSX is inspired by HTML and allows you to
      write HTML-ish looking syntax inside your
      React Components.
    </p>
  </main>
}
```

</CodePreview>

For the most part, writing JSX should feel pretty natural. It's *mostly* just like HTML, but there are a few things to be aware of. We'll spend the rest of this post exploring some of those gotchas as well as some tips and tricks when it comes to JSX.

First, let's talk about having multi-line JSX.

Up until this point, whenever we've had multiple elements in our JSX, we've done something like this – where the <Hover id="first" highlight="main" index={0}>first element</Hover> immediately follow the `return` and the rest are indented normally on new lines.

```jsx id="first"
export default function WhatIsJSX () {
  return <main>
    <h1>This is JSX</h1>
    <h2>JSX <i>looks</i> like HTML</h2>
    <h4>(but it's not)</h4>
    <p>
      JSX is inspired by HTML and allows you to
      write HTML-ish looking syntax inside your
      React Components.
    </p>
  </main>
}
```

Though that works, admittedly it's a little weird. Specifically, it's the first `<main>` that feels off. We would never write HTML with the first element indented more than its children elements, so why do it here?

To fix this, you might be tempted to do something like this (which feels more natural).

<CodePreview hideStrictModeToggle template="react" previewHeight="100px">

```jsx App.jsx active 
export default function WhatIsJSX () {
  return 
    <main>
      <h1>This is JSX</h1>
      <h2>JSX <i>looks</i> like HTML</h2>
      <h4>(but it's not)</h4>
      <p>
        JSX is inspired by HTML and allows you to
        write HTML-ish looking syntax inside your
        React Components.
      </p>
    </main>
}
```

</CodePreview>

Unfortunately, as you can see, that won't work. It's a fun quirk of the JavaScript specification. When the JavaScript interpreter runs this code, because of [automatic semicolon insertion](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Lexical_grammar#automatic_semicolon_insertion) (ASI), it'll insert a semicolon right after our `return` statement – ending the function and returning nothing, like this.

```jsx
export default function WhatIsJSX () {
  return;
    // <main>
    //   <h1>This is JSX</h1>
    //   <h2>JSX <i>looks</i> like HTML</h2>
    //   <h4>(but it's not)</h4>
    //   <p>
    //     JSX is inspired by HTML and allows you to
    //     write HTML-ish looking syntax inside your
    //     React Components.
    //   </p>
    // </main>
}
```

The standard way to fix this is to wrap your JSX inside of parens `()`, which allows us to have our JSX indented as you'd expect, while avoiding ASI issues.

<CodePreview hideStrictModeToggle template="react" previewHeight="300px">

```jsx App.jsx active mark=2[9:10],13[2:3]
export default function WhatIsJSX () {
  return (
    <main>
      <h1>This is JSX</h1>
      <h2>JSX <i>looks</i> like HTML</h2>
      <h4>(but it's not)</h4>
      <p>
        JSX is inspired by HTML and allows you to
        write HTML-ish looking syntax inside your
        React Components.
      </p>
    </main>
  )
}
```

</CodePreview>

So far so good, but here's a question I want you to think through. Can you spot any issues with this component?

```jsx App.jsx active
export default function Authors () {
  return (
    <h2>Authors</h2>
    <ul>
      <li>Tyler McGinnis</li>
      <li>Ben Adam</li>
      <li>Alex Brown</li>
    </ul>
  )
}
```

It looks fine, right? Unfortunately, it'll throw an error as seen below.

<CodePreview hideStrictModeToggle template="react" previewHeight="200px">

```jsx App.jsx active 
export default function Authors () {
  return (
    <h2>Authors</h2>
    <ul>
      <li>Tyler McGinnis</li>
      <li>Ben Adam</li>
      <li>Alex Brown</li>
    </ul>
  )
}
```

</CodePreview>

That's a fancy way to say that you can only ever return one top-level element from a component. In our example, we're trying to return 2 (`h2`, and `ul`). 

To fix this, as the error says, we want to return one, which we can do by wrapping everything in a `div`.

<CodePreview hideStrictModeToggle template="react" previewHeight="200px">

```jsx App.jsx active mark=3,10
export default function Authors () {
  return (
    <div>
      <h2>Authors</h2>
      <ul>
        <li>Tyler McGinnis</li>
        <li>Ben Adam</li>
        <li>Alex Brown</li>
      </ul>
    </div>
  )
}
```

</CodePreview>

That fixes the issue, but now we have a semantic problem. 

Now we're unnecessarily creating an extra `div`. This is the exact use case that `React.Fragment` was created for. If you want to return adjacent elements but don't want to change your markup, wrap them in `<React.Fragment>`.

<CodePreview hideStrictModeToggle template="react" previewHeight="200px">

```jsx App.jsx active mark=5,12
import * as React from "react"

export default function Authors () {
  return (
    <React.Fragment>
      <h2>Authors</h2>
      <ul>
        <li>Tyler McGinnis</li>
        <li>Ben Adam</li>
        <li>Alex Brown</li>
      </ul>
    </React.Fragment>
  )
}
```

</CodePreview>

Much better.

There also exists a shorthand syntax for React Fragment (`<>`), but it feels a little _too_ magical to me, so I don't use it much.

<CodePreview hideStrictModeToggle template="react" previewHeight="200px">

```jsx App.jsx active mark=3,10
export default function Authors () {
  return (
    <>
      <h2>Authors</h2>
      <ul>
        <li>Tyler McGinnis</li>
        <li>Ben Adam</li>
        <li>Alex Brown</li>
      </ul>
    </>
  )
}
```

</CodePreview>

Let's do another one. Can you spot what's wrong with this JSX?

```jsx
function Form () {
  return (
    <form method="get" action="/search">
      <img src="search.png" alt="search icon">
      <br>
      <label>
        Search
        <input name="term" type="text">
      </label>
      <button type="submit">Search</button>
    </form>
  )
}
```

If you're familiar with HTML but new to React, your answer is probably "...nothing?" This is another case where JSX is slightly different than the HTML spec. Whenever you have a "Self-closing tag" (the most popular being `input`, `br`, and `img`), you need to make sure that you explicitly close them.

```jsx
<input> 👎
<input /> 👍

<br> 👎
<br /> 👍

<img> 👎
<img /> 👍
```

So with that, our `Form` component will now have valid JSX if we explicitly close all our self-closing elements.

```jsx
function Form () {
  return (
    <form method="get" action="/search">
      <img src="search.png" alt="search icon" />
      <br />
      <label>
        Search
        <input name="term" type="text" />
      </label>
      <button type="submit">Search</button>
    </form>
  )
}
```

How about this one? Can you spot what's wrong with this JSX?

```jsx
function Avatar () {
  return (
    <img
      src="avatar.png"
      alt="Avatar"
      class="avatar"
    />
  )
}
```

I know, this is a weird one. The error is that `class` should be `className`.

```jsx
function Avatar () {
  return (
    <img
      src="avatar.png"
      alt="Avatar"
      className="avatar"
    />
  )
}
```

The reason for this is because, as you know, eventually this JSX gets converted into JavaScript, and in JavaScript, there are particular keywords that are reserved (meaning you can't use them). `class` just happens to be one of those.

<Aside emoji="🤨">

<i>"WTF I thought you said JSX was just like HTML?"</i>

<Mono className="text-[18px] pt-4 block">- You, probably.</Mono>

</Aside>

A similar thing to look out for is that you can't have variable names that have a `-` in them. So any normal HTML attributes that have a `-` in them (like `stroke-width`) you need to convert to camelCase.

```jsx {11}
function Icon () {
  return (
    <svg width="200" height="200">
      <rect
        x="10"
        y="10"
        width="180"
        height="180"
        fill="none"
        stroke="black"
        strokeWidth="5"
      />
    </svg>
  )
}
```

Whenever you want to use an expression (something that produces a value) in JSX, you need to wrap the expression in single curly braces, `{}`.

```jsx
function Welcome() {
  const name = 'Tyler'

  return (
    <div>
      <h1>Hello, {name}</h1>
      <p>
        Today is {new Date().toLocaleDateString()}
      </p>
      <p>What is 2 + 2? {2 + 2}</p>
    </div>
  )
}
```

If you want a React component to show nothing, as sometimes is the case when data is still loading, return `null` from your component.

```jsx
if (isLoading() === true) {
  return null
}

return (
  <main>
    <h1>This is JSX</h1>
    <h2>JSX <i>looks</i> like HTML</h2>
  </main>
)
```

Next is conditional rendering.

The ability to conditionally show UI based on a piece of state is pretty foundational to any front-end framework. Typically, this functionality is built natively into the framework.

```html
// Angular
<h1 *ngIf="authed; else elseBlock">Welcome back!</h1>
<ng-template #elseBlock>
  <h1>Login to see your dashboard</h1>
</ng-template>

// Vue
<h1 v-if="authed">Welcome back!</h1>
<h1 v-else>Login to see your dashboard</h1>
```

With React, it's a bit different. Instead of increasing the API surface layer, because JSX is <Sparkle>Just JavaScript</Sparkle>, React can leverage native JavaScript features to accomplish the same task. There are pros and cons to this approach, but if you're already familiar with conditional rendering in JavaScript, you'll feel pretty comfortable.

The most basic example is just using a simple `if/else` statement.

```jsx
function Dashboard () {
  const authed = isAuthed()

  if (authed === true) {
    return <h1>Welcome back!</h1>
  } else {
    return <h1>Login to see your dashboard</h1>
  }
}
```

Again, because we're just writing JavaScript, if we had another condition, we'd just add an `else if` case.

```jsx
function Dashboard () {
  const authed = isAuthed()
  const firstLogin = isNew()

  if (firstLogin === true) {
    return <h1>👋 Welcome!</h1>
  } else if (authed === true) {
    return <h1>Welcome back!</h1>
  } else {
    return  <h1>Login to see your dashboard</h1>
  }
}
```

If you're rendering different UI based on a single condition, typically you'd use JavaScript's [ternary operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator).

```jsx
function Dashboard () {
  return isAuthed() === true
    ? <h1>Welcome back!</h1>
    : <h1>Login to see your dashboard</h1>
}
```

We learned earlier that any expression needs to be wrapped in `{}`. We can use that knowledge to render a ternary inside of JSX.

```jsx
function Dashboard () {
  return (
    <React.Fragment>
      <Logo />
      {isAuthed() === true
        ? <h1>Welcome back!</h1>
        : <h1>Login to see your dashboard</h1>}
    </React.Fragment>
  )
}
```

Earlier we also learned that we can return `null` if we want React to render nothing. This is a common pattern when using ternaries.

```jsx
function Dashboard () {
  return (
    <React.Fragment>
      <Logo />
      {showWarning() === true
        ? <Warning />
        : null}
    </React.Fragment>
  )
}
```

Another common use case of conditional rendering is using JavaScript's logical `&&` operator. If you're not already familiar with it, typically it's used in conditionals as an "AND" statement.

```js
if (user && authed) {
  // runs if user and authed are truthy
}
```

In the example above, it's important to note that `authed` won't be checked if `user` isn't truthy. Using that logic, we can use the `&&` operator as a more concise ternary that renders `null`.

```jsx
function Dashboard () {
  return (
    <React.Fragment>
      <Logo />
      {showWarning() === true && <Warning />}
    </React.Fragment>
  )
}
```

Now one question you may have had is how does React know the difference between a custom React component like `<User />` and a native HTML element like `<span>`? The answer is probably simpler than you'd expect, it's based on the capitalization.

Whenever you create a React component, you need to capitalize it. Otherwise, React will think it's a native HTML element.

At this point we're almost done, but there's one more thing about JSX we need to cover.

Eventually you come to accept that as an app developer, your primary job is to render lists. It's so fundamental, that most frameworks come with a special API to accomplish it.

```html
// Vue
<ul id="tweets">
  <li v-for="tweet in tweets">
    {{ tweet.text }}
  </li>
</ul>
```

```html
// Angular
<ul id="tweets">
  <li *ngFor="let tweet of tweets">
    {{ tweet.text }}
  </li>
</ul>
```

React takes a different approach. When possible, React tries to keep the API surface to a minimum. To do that, it relies heavily on features that JavaScript provides out of the box.

When rendering a list, the end goal, as seen in the Vue and Angular examples above, is to create a list of `<li>` elements that we can then show to the UI. Can you think of anything built into JavaScript itself that would help us accomplish this? What about `.map`?

Typically you use `.map` when you need to create a new array, based on a previous array. Something like this.

```js
const tweets = [
  {
    id: 1,
    stars: 13,
    text: 'Turns out git reset --hard HEAD^ was a terrible idea',
  },
  {
    id: 3,
    stars: 51,
    text: "Clean code is subjective. Optimize for deletion",
  },
  {
    id: 4,
    stars: 19,
    text: "What even is a jQuery?",
  },
]

const stars = tweets.map((tweet) =>
  tweet.stars
) // [13,51,19]
```

Except now, instead of creating a new array of `stars`, we want to create a new array of `<li>`s. Using the same `.map` method, let's throw in some JSX.

<CodePreview hideStrictModeToggle template="react" previewHeight="200px">

```jsx App.jsx active mark=6:8
import tweets from "./tweets"

export default function Tweets () {
  return (
    <ul id="tweets">
      {tweets.map((tweet) => (
        <li>{tweet.text}</li>
      ))}
    </ul>
  )
}
```

```js tweets.js
const tweets = [
  {
    id: 1,
    stars: 13,
    text: 'Turns out git reset --hard HEAD^ was a terrible idea',
  },
  {
    id: 3,
    stars: 51,
    text: "Clean code is subjective. Optimize for deletion",
  },
  {
    id: 4,
    stars: 19,
    text: "What even is a jQuery?",
  },
]

export default tweets
```

</CodePreview>

Notice there's no new API you need to remember. If you can remember how `.map` works, you can remember how to create a list in React.



Unfortunately, we're not quite done yet. There's just one small addition we need to make to our code. Whenever you use `.map` to create a list in React, you need to make sure that you add a **unique** `key` prop to each list item.

```jsx
<ul id="tweets">
  {tweets.map((tweet) => (
    <li key={tweet.id}>{tweet.text}</li>
  ))}
</ul>
```

It's React's job to make rendering the list as fast as possible. When you give each list item a **unique** `key` prop, it helps React know which items, if any, change throughout different renders of that component.

<Aside title="WTF is JSX *actually*?" emoji="🧐">

For the curious amongst you, you're probably wondering how JSX *actually* works. We have an entire bonus section later on dedicated to this question, but here's a quick teaser.

Like most magic, the answer is more simple than you might expect.

In order to use React, at build time, you need a tool to transform JSX into normal JavaScript the browser can understand.

So for example, a component like this

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

at build time will be compiled to regular JavaScript like this

```js
import { jsx as _jsx } from "react/jsx-runtime"

function Hello() {
  return _jsx("h1", {
    children: "Hello World"
  })
}

```

so the browser only ever sees JavaScript.

tl;dr – JSX is just JavaScript*

*eventually

</Aside>

# What is a React component?

---

- [] a function that returns some UI

- [x] a function that returns a description of the UI

---

In order to return some UI, we'd have to be returning literal HTML. Instead, we return JSX which allows us to describe the UI.

# How do you use variables in JSX?

---

- [ ] Wrap them in `{{}}`

- [x] Wrap them in `{}`

- [ ] Wrap them in `[]`

- [ ] Wrap them in `🥴🥴`

# To render no UI, you return a falsy value from a React component.

---

- [ ] true

- [x] false

---

That statement is `false`. To render no UI in React, you should return `null` or `false`. Just because both of those are falsy values, doesn't mean *all* falsy values will render no UI. For example, if you returned `0` from a React component, even though it's a falsy value, it would still render `0`.

# JSX has its own directive for conditional rendering, `r-if`/`r-else`

---

- [ ] true

- [x] false

---

Instead of increasing the API surface layer, because JSX is “Just JavaScript”, React can leverage native JavaScript features to accomplish the same task. You can use an if/else statement, ternary operator, or the logical `&&` operator.

# What's wrong with this code?

```jsx
function home () {
  return (
    <Header />
    <content />
    <Footer />
  )
}
```

---

- [ ] Nothing

- [x] You can't render adjacent parent elements in JSX

- [ ] The browser will throw an error when it sees the opening `(`

- [x] You need to wrap the `return` value in `<React.Fragment>`

- [x] You can't have lowercase component names

---

Here's the correct code.

```jsx
function Home () {
  return (
    <React.Fragment>
      <Header />
      <Content />
      <Footer />
    </React.Fragment>
  )
}
```

# Which code is correct?

---

- [x]

```jsx
<ul id="tweets">
  {tweets.map((tweet) => (
    <li key={tweet.id}>{tweet.text}</li>
  ))}
</ul>
```

- [ ]

```jsx
<ul id="tweets">
  {tweets.map((tweet) => (
    <li>{tweet.text}</li>
  ))}
</ul>
```

- [ ]

```jsx
<ul id="tweets">
  {tweets.forEach((tweet) => (
    <li>{tweet.text}</li>
  ))}
</ul>
```

- [ ]

```jsx
<ul id="tweets">
  <li r-for="tweet in tweets">
    {{ tweet.text }}
  </li>
</ul>
```

---

Don't forget each item needs its own unique `key` prop so React can identify which items have changed between renders.

# What's wrong with this code?

```jsx
export default function Authors () {
  return 
    <aside>
      <h3>Authors</h3>
      <ul>
        <li>Tyler McGinnis
        <li>Ben Adam
        <li>Alex Brown
      </ul>
    </aside>
}
```

---

- [ ] We need to wrap our JSX inside of `React.Fragment`

- [x] We need to wrap our JSX in parens `()` if the element we want to return is not on the same line as the `return` statement

- [x] We need to close our list items with `</li>`

- [ ] nothing

---

Here's the correct version.

```jsx
export default function Authors () {
  return (
    <aside>
      <h3>Authors</h3>
      <ul>
        <li>Tyler McGinnis</li>
        <li>Ben Adam</li>
        <li>Alex Brown</li>
      </ul>
    </aside>
  )
}
```

# What's wrong with this code?

```jsx
function Image() {
  return (
    <img src="https://bytes.dev/images/logo.svg" class="fluid-img">
  )
}
```

---

- [ ] Nothing
- [x] The `class` attribute should be `className`
- [ ] The `src` attribute should be `source`
- [x] The `img` tag is not closed

---

There are a few "gotchas" in JSX that you need to be aware of. The `class` attribute is a reserved word in JavaScript, so you need to use `className` instead. The `img` tag is not closed, so you need to add a closing `/>` at the end.

```jsx
function Image() {
  return (
    <img 
      src="https://bytes.dev/images/logo.svg" 
      className="fluid-img" 
    />
  )
}
```

We have a `Badge` component with variables for `name`, `handle` and `img` that are unassigned. Your job is to assign those variables in the JSX so that the component renders correctly.

#### Tasks

1. Give the image a proper `alt` tag using the author's name
2. Make sure the badge displays the profile `image` correctly
3. Display the author's `name` in the badge's heading
4. Display the author's `handle` below the heading

#### The Result

The final UI for your solution should look like this.

<CodePreview
  hideEditor
  sandboxId="badge-variables-solution-rugm2l"
  previewHeight="400px"
/>

Badge Variables

Using JavaScript, replace the static date with today's date (we made a helper function that returns today's date to help you out). 

#### Tasks

1. Use the `getTodaysDate` function to render today's date

#### The Result

The final UI for your solution should look like this.

<CodePreview
  hideEditor
  sandboxId="dynamic-date-solution-l5xwek"
  previewHeight="100px"
/>


Dynamic Date

There's a problem with our `Layout` component which is preventing it from rendering correctly.

#### Tasks

1. Fix the error so the component renders correctly

#### The Result

The final UI for your solution should look like this.

<CodePreview
  hideEditor
  sandboxId="adjacent-elements-solution-zwjxv7"
  previewHeight="400px"
/>


Adjacent Elements

Using an `if statement`, update the code to conditionally render the correct component based on the value of `isLactoseTolerant`.

#### Tasks

1. If the user is lactose intolerant, render the `LactoseIntolerant` component
2. If the user is lactose tolerant, render the `LactoseTolerant` component

#### The Result

The final UI for your solution should look something like this, depending on the result of `getIsLactoseTolerant`.

<CodePreview
  hideEditor
  sandboxId="conditional-rendering-solution-rex8vb"
  previewHeight="150px"
/>


Conditional Rendering

Given the solution code to the previous challenge, refactor this code to use a ternary operator to conditionally render the UI rather than an if statement.

#### Tasks

1. If the user is lactose intolerant, render the `LactoseIntolerant` component
2. If the user is lactose tolerant, render the `LactoseTolerant` component

#### The Result

The final UI for your solution should look something like this, depending on the result of `getIsLactoseTolerant`.

<CodePreview
  hideEditor
  sandboxId="ternary-rendering-solution-mcwzlz"
  previewHeight="150px"
/>


Ternary Rendering

Given an array of `friends`, update our `ul` to include a `li` for every friend. The list item should display all the friend's names.

#### Tasks

1. Render an unordered list with all of the friends
2. Each list item should display the correct name
3. Each list item should be given a unique key

#### The Result

The final UI for your solution should look like this.

<CodePreview
  hideEditor
  sandboxId="rendering-lists-solution-cgq4tk"
  previewHeight="200px"
/>


Rendering Lists

Given an array of friends, create a list item for every friend inside of our unordered list. Note: The items in our `friends` array don't have their own unique keys. You need to improvise.

#### Tasks

1. Render an unordered list with all of the friends
2. Each list item should display the correct name
3. Each list item should be given a unique key

#### The Result

The final UI for your solution should look like this.

<CodePreview
  hideEditor
  sandboxId="rendering-lists-no-keys-solution-m7vvzn"
  previewHeight="400px"
/>


Rendering Lists No Keys

Whenever you have a system that is reliant upon composition, it's critical that each piece of that system has an interface for accepting data from outside of itself. You can see this clearly illustrated by looking at something you're already familiar with, functions.

```js id="hover"
function getProfilePic(username) {
  return "https://photo.fb.com/" + username
}

function getProfileLink(username) {
  return "https://www.fb.com/" + username
}

function getAvatarInfo(username) {
  return {
    pic: getProfilePic(username),
    link: getProfileLink(username),
  }
}

getAvatarInfo("tylermcginnis")
```

Without the ability to pass data, in this case <Hover id='hover' highlight={["username", '"tylermcginnis"']}>`username`</Hover>, to each of our of functions, our composition would break down.

Similarly, because React relies heavily on composition, there needs to exist a way to pass data **into** components. This brings us to our next important React concept, `props`.

<Definition header="What are props?" description="Props are to components what arguments are to functions." />

<Props />

The same intuition you have about functions and passing arguments to functions can be directly applied to components and passing props to components.

There are two parts to understanding how props work.

<List
  items={["How to pass data into components", "Accessing the data once it's been passed in"]}
/>

### Passing data to a component

This one should feel natural because you've been doing something similar ever since you learned HTML. You pass data to a React component the same way you'd set an attribute on an HTML element.

```jsx
<img src='' />

<Hello name='Tyler' />
```

In this example, we're passing in a `name` prop to the `Hello` component.

It's important to note that we're not limited to just passing strings as props. Just like we can pass functions or any other value as arguments, so too can we pass any value as props.

```jsx id="props"
<Profile
  username="tylermcginnis"
  authed={true}
  logout={handleLogout}
  header={<h1>👋</h1>}
/>
```

One thing you may have noticed is that sometimes we have to wrap what we're passing in inside of <Hover id="props" highlight={["{", "}"]}>curly braces</Hover>, `{}`. Can you spot why that is?

The easy to remember rule is that any time you're passing a prop that isn't a string, you must wrap it inside of a curly brace. The reason for that is curly braces give you a "window into the JavaScript world" – that is they allow you to use JavaScript inside of your markup.

Following that rule, though this looks a little weird, you can even pass object literals to components as props.

```jsx
<DatePicker settings={{
  format: "yy-mm-dd",
  animate: false,
  days: "abbreviate"
}} />
```

Notice we use two sets of curly braces, `{{}}`. If you think about it, that makes sense. We have an object `{}` which we want to pass as a prop, and since it's not a string, we wrap it in another set of curly braces, getting `{{}}`.

<Aside emoji="💎" title="Boolean Shortcut">

One thing to note is that if you pass a prop without a value, that value will be set to `true`. These are equivalent.

```js
<Profile authed={true} />
<Profile authed />
```

</Aside>


### Accessing props

Now that we know how to pass props to components, the next question is how do you get access to those props from inside of the component?

Since components are just functions, it's pretty simple. React will put all of the props on an object, and pass that object as the first argument to the function.

So going back to our first example, here's what passing a prop and accessing that prop would look like.

<CodePreview hideStrictModeToggle template="react" previewHeight="100px">

```jsx App.jsx active mark=1[16:21],2[21:31],6[16:28]
function Hello (props) {
  return <h1>Hello, {props.name}</h1>
}

export default function App () {
  return <Hello name='Tyler' />
}
```

</CodePreview>

Regardless of how many props you pass to a component, each prop is added as a key on the `props` object.

<CodePreview hideStrictModeToggle template="react" previewHeight="100px">

```jsx App.jsx active
function Hello (props) {
  return (
    <h1>
      Hello, {props.first} {props.last}
    </h1>
  )
}

export default function App () {
  return <Hello first="Tyler" last="McGinnis" />
}
```

</CodePreview>

And because props is just an object, you can also destructure it if you'd like.

```jsx
function Hello ({ first, last }) {
  return (
    <h1>
      Hello, {first} {last}
    </h1>
  )
}
```

***

So at this point, you should be comfortable with props. As you've seen, props are how you pass data into components. You pass data to components just like you'd set attributes on regular HTML elements.

```jsx
<a href='/' class='link'>Home</a>

<Clock time='12:49' period='AM' />
```

Now thinking more about regular HTML elements (`span`, `div`, etc), is there any other way that we're able to pass information to the element?

What about the text `Home` in our `a` tag above? As part of the API for almost every HTML element, you can pass data via the opening and closing tag of the element.

```html
<h1>You can have text between tags.</h1>

<div>
  <h1>You can also have</h1>
  <p>elements between tags</p>
</div>
```

Now, what if instead of those being regular HTML elements, they were React components?

```jsx
<Header>You can have text between tags.</Header>

<Layout>
  <h1>You can also have</h1>
  <p>elements between tags</p>
</Layout>
```

Now, instead of passing data (props) into the component via setting attributes as we usually would, we're passing data into the components via the opening and closing tags. How would we go about implementing those? And more specifically, how would we get access to the data inside of the opening and closing tag of the element? React makes this simple.

Whatever is between the opening and closing tag of an element will be accessible inside of the component via `props.children`.

```jsx
function Header (props) {
  return <h1 className="header">{props.children}</h1>
}

function Layout (props) {
  return (
    <div className="layout">
      <Sidebar />
      {props.children}
      <Footer />
    </div>
  )
}
```

You can think of a component with a `children` prop as having a placeholder that can be filled by its parent component. 

<PropsChildren /> 

Because of this, it's common to utilize `children` to create `Layout` type components that encapsulate styling and logic, but leave the content to the consumer of the component. 

A common example of this is a `Modal` component.

<CodePreview 
  hideStrictModeToggle 
  template="react" 
  previewHeight="330px" 
  lineLimit="23"
>

```jsx App.jsx active mark=15:17
import * as React from "react"
import Modal from "./Modal"

export default function App () {
  const [isOpen, setIsOpen] = React.useState(false)

  const handleOpen = () => setIsOpen(true)
  const handleClose = () => setIsOpen(false)
  
  return (
    <main>
      <button onClick={handleOpen}>Open Modal</button>
      {isOpen && (
        <Modal onClose={handleClose}>
          <h1>Modal is Customizable</h1>
          <p><i>children</i> can be whatever we want.</p>
          <p>(and it can be different each time we use Modal)</p>
        </Modal>
      )}
    </main>
  )
}
```

```jsx Modal.jsx
import closeIcon from "./closeIcon"

export default function Modal ({ children, onClose }) {
  return (
    <dialog>
      <button onClick={onClose}>{closeIcon}</button>
      { children }
    </dialog>
  )
}
```

```css styles.css
section {
  text-align: center;
}

dialog {
  position: fixed;
  top: 40px;
  background: var(--purple);
  width: 75vw;
  margin: auto;
  display: block;
  animation: expand 0.3s cubic-bezier(0.075, 0.82, 0.165, 1);
  border-radius: 8px;
  padding: 32px;
}

dialog button {
  position: absolute;
  top: 16px;
  right: 16px;
  appearance: none;
  background: rgba(255, 255, 255, 0.05);
  padding: 0;
  color: var(--charcoal);
  width: 32px;
  height: 32px;
  border-radius: 50%;
  display: flex;
  align-items: center;
  justify-content: center;
}

@keyframes expand {
  0% {
    transform: scale(0.75);
  }
  100% {
    transform: scale(1);
  }
}
```

```jsx closeIcon.jsx hidden
const closeIcon = (
  <svg
    stroke="currentColor"
    fill="currentColor"
    strokeWidth="0"
    viewBox="0 0 24 24"
    height="1em"
    width="1em"
    xmlns="http://www.w3.org/2000/svg"
  >
    <path fill="none" d="M0 0h24v24H0z"></path>
    <path d="M19 6.41L17.59 5 12 10.59 6.41 5 5 6.41 10.59 12 5 17.59 6.41 19 12 13.41 17.59 19 19 17.59 13.41 12z"></path>
  </svg>
)

export default closeIcon
```

</CodePreview>

Notice that we encapsulate the styling and logic of the modal into the `Modal` component, but we can specify what the contents of `Modal` are when we create the `Modal` element.

Props

# If this is our element, what is `props` inside of `Pokemon`?

```jsx
<Pokemon id="bulbasaur" starter />
```

---

- [] `{ id: "bulbasaur", starter: undefined }`

- [] `{ id: "bulbasaur", starter: "starter" }`

- [] `["bulbasaur", true]`

- [x] `{ id: "bulbasaur", starter: true }`

---

`props` is always an object and if you pass a prop without a value (like `starter`), that'll be `true` in the component.


# What's wrong with this code?

```jsx
<Profile
  username="tylermcginnis"
  authed={true}
  logout={() => handleLogout()}
  header={<h1>👋</h1>}
  friend={{
    name: "Mikenzi",
  }}
/>
```

---

- [x] Nothing

- [ ] `friend` has an extra `{}`

- [ ] You can't pass HTML elements as props (`header`)


# Inside of `Profile` what does `props.authed` equate to?

```jsx
<Profile authed />
```

---

- [ ] `undefined`

- [x] `true`

- [ ] `authed`

- [ ] `null`

---

# What is wrong with this code?

```jsx
<DatePicker
  eventName={`${event} - ${date}`}
  renderFooter={() => (
    <button onClick={handleClose}>
      Close
    </button>
  )}
  settings={
    format: "yy-mm-dd",
    animate: false,
    days: "abbreviate"
  }
/>
```

---

- [ ] Nothing

- [ ] `eventName` is not a valid prop

- [x] `settings` is not a valid prop

- [ ] `renderFooter` is not a valid prop

---

The `settings` prop is invalid syntax. Remember, JSX evaluates what is in `{}` as JavaScript. So, if you want to pass an object as a prop, you need to wrap it in `{}`. The other props use valid JavaScript or JSX. 

```jsx
<DatePicker
  eventName={`${event} - ${date}`}
  renderFooter={() => (
    <button onClick={handleClose}>
      Close
    </button>
  )}
  settings={{
    format: "yy-mm-dd",
    animate: false,
    days: "abbreviate"
  }}
/>
```

# In the code below, what is `children`? 

```jsx
const Layout = ({ children }) => {
  return (
    <div className="layout">
      <Header />
      {children}
      <Footer />
    </div>
  )
}
```

---

- [ ] An object

- [ ] A React element

- [x] We don't know

- [ ] `undefined`

---

Like any other prop, we don't know the value of `children` just by looking at the component. Instead, we'll need to look at where we create the `Layout` element.

# You can think of a component with a `children` prop as having a placeholder that can be filled by its parent component.

---

- [x] true

- [ ] false

---

Currently, our `Badge` component is displaying hardcoded values. Instead of rendering the static values, we want to pass them in as props. In this challenge, your goal is to apply the props being passed to the `Badge` component (`name`, `handle`, and `img`) so that it renders correctly.

#### Tasks

1. Give the image a proper `alt` tag using the author's name
2. Make sure the badge displays the profile `image` correctly
3. Display the author's `name` in the badge's heading
4. Display the author's `handle` below the heading

#### The Result

The final UI for your solution should look like this.

<CodePreview
  hideEditor
  sandboxId="string-props-solution-s1jbmz"
  previewHeight="400px"
/>

String Props

Although this challenge looks similar to the previous one, there are some subtle differences. As before, apply the new props to the `Badge` component so that it renders properly.

#### Tasks

1. Give the image a proper `alt` tag using the author's name
2. Make sure the badge displays the profile `image` correctly
3. Display the author's `name` in the badge's heading
4. Display the author's `handle` below the heading
5. Apply the correct styles to the outer div

#### The Result

The final UI for your solution should look like this.

<CodePreview
  hideEditor
  sandboxId="object-props-solution-rcxk1j"
  previewHeight="400px"
/>

Object props

Often times, we want to split our UI into smaller, more focused components to make our code easier to read and test. In this challenge, take the props being passed to the `Badge` component and use them in order to render the proper UI.

#### Tasks

1. Give the image a proper `alt` tag using the author's name
2. Make sure the badge displays the profile `image` correctly
3. Display the author's `name` in the badge's heading
4. Display the author's `handle` below the heading
5. Pass the click handler to the button so that it opens an alert when clicked

#### The Result

The final UI for your solution should look like this.

<CodePreview
  hideEditor
  sandboxId="function-props-solution-oo53ep"
  previewHeight="400px"
/>

Function Props

Finish the Badge component so that it utilizes *all* the props passed to it.

#### Tasks

1. Give the image a proper `alt` tag using the author's name
2. Make sure the badge displays the profile `image` correctly
3. Display the author's `name` in the badge's heading
4. Display the author's `handle` below the heading
5. Display the bio text under the headings
6. Pass the click handler to the button so that it opens an alert when clicked

#### The Result

The final UI for your solution should look like this.

<CodePreview
  hideEditor
  sandboxId="children-props-solution-xx28ml"
  previewHeight="500px"
/>

Children Props

Here's a question for you. If this is called a _function definition_,

```js
function add(x, y) {
  return x + y;
}
```

this is called a _function invocation_.

```js
add(1, 2)
```

If this is called a _component definition_,

```jsx
function Icon () {
  return <svg />
}
```

what is this called?

```jsx
<Icon />
```

Here are some of the most common answers, all of which are incorrect.

<List items={[
  `Creating an instance/instantiation`,
  `Rendering a component`,
  `Evaluating a component`,
  `Component invocation`,
  `Using it 😅`
]} />

The primary reason for the confusion is because there's an important but subtle step between when React evaluates your code, and the browser sees it. This makes sense. The browser can only understand JavaScript – and though JSX is a syntax _extension_ to JavaScript, it's still not browser compatible JavaScript.

This problem isn't anything new. We've been <Popover content={<p>or technically, <i>transpiling</i> for the pedantic among you 🫶.</p>}>compiling</Popover> non-browser-compatible syntax (Elm, TypeScript, CoffeeScript, etc.) to JavaScript for years.

So how exactly do we go from `<Icon />`, to JavaScript the browser can understand?

The answer lies in what React calls an **element**.

<Definition 
  header="What is a React Element?" 
  description="An object representation of a DOM node" 
/>

This definition gives us some interesting insight into how React works under the hood. An element *isn't* a DOM node, instead it's an object representation of it.

Here's an example of what one looks like.

```js
{
  type: "h1",
  props: {
    children: "Profile",
    className: "header"
  }
}
```

This, of course, is an object representation of a DOM node that looks like this.

```html
<h1 class="header">
  Profile
</h1>
```

The way React works is it'll keep references to all of the elements in your application. If one of those references changes, React will then know where exactly in the DOM it needs to update.

In order to create a React element, you have a few options – one of them being React's `jsx-runtime` package.

```js
import { jsx } from "react/jsx-runtime"

const element = jsx("h1", {
  className: "header",
  children: "Profile"
})
```

`jsx` takes in two arguments. The first is a tag name string (`div`, `span`, etc.) and the second is an object of attributes you want the element to have. In our case, a `className` of `header` with the text `Profile` as its contents.

What it returns is a React element as shown above. We can see this in action with the following code.

<CodePreview strictMode={false} disableStrictModeToggle previewHeight="150px">

```js App.jsx active
import { jsx } from "react/jsx-runtime"

export default function App () {
  return jsx("h1", {
    className: "header",
    children: "Profile"
  })
}
```

</CodePreview>

Notice there's no JSX – it's <Sparkle>Just JavaScript™</Sparkle>.

What’s interesting about learning React is that typically one of the first things you're taught are components and that _components are the building blocks of React_. As we can see, that's not true – elements are the true building blocks of React. Components, by definition, are just functions that optionally accept input via props, and return a React element.

In our example above, `App` is a component and what it returns (the invocation of `jsx`) is a React element.

```js
import { jsx } from "react/jsx-runtime"

const Component = () => {
  const element = jsx("h1", {
    className: "header",
    children: "Profile"
  })

  return element
}

export default Component
```

And you're not only limited to creating React elements from native HTML elements (`span`, `div`, etc.). You can also pass in other React components as the first argument to `jsx` as well.

```js
const element = jsx(Badge, {
  name: "Tyler McGinnis",
  handle: "tylermcginnis",
  img: "https://avatars0.githubusercontent.com/u/2933430"
})
```

When React sees a component as the first argument, it will recursively render that component as well as all of its children components in order to get all the React elements and the final description of the UI.

Remember the `Badge` component from the props lesson? Here's what it looks like using the `jsx-runtime` package.

<CodePreview strictMode={false} hideStrictModeToggle previewHeight="400px" lineLimit={33}>

```jsx App.jsx active
import { jsx } from "react/jsx-runtime"

function Badge({ name, handle, img }) {
  return jsx("div", {
    className: "badge",
    children: [
      jsx("img", {
        alt: name,
        src: img
      }),
      jsx("div", {
        children: [
          jsx("h4", {
            children: name
          }),
          jsx("p", {
            children: ["@", handle]
          })
        ]
      })
    ]
  });
}

export default function App() {
  return jsx(Badge, {
    name: "Tyler McGinnis",
    handle: "tylermcginnis",
    img: "https://avatars0.githubusercontent.com/u/2933430"
  });
}

```

```css styles.css
img {
  width: 200px;
  border-radius: 50%;
}

h4 {
  margin: 5px;
}

p {
  margin: 5px;
}

.badge {
  width: 300px;
  margin: 0 auto;
  border-radius: 8px;
  background-color: var(--charcoal);
  padding: 24px;
  display: flex;
  flex-direction: column;
  align-items: center;
  gap: 16px;
  text-align: center;
}
```

</CodePreview>

So now the big question you've probably been wondering, what's the difference between writing JSX and using the `jsx` transform?

As far as the browser is concerned, nothing. 

As you can imagine, creating a description of your UI with `jsx` function invocations isn't terribly ergonomic – which is why we have JSX. At build time, all the JSX in your app gets compiled to Javascript via `jsx` invocations that the browser can understand.

So now that we have some context, let's go back to our original question.

If this is called a _function definition_,

```js
function add(x, y) {
  return x + y;
}
```

this is called a _function invocation_.

```js
add(1, 2)
```

If this is called a _component definition_,

```jsx
function Icon () {
  return <svg />
}
```

what is this called?

```jsx
<Icon />
```

We call it _creating an element_, because after the JSX is compiled and `jsx` is invoked, that’s what we get back – an element.

In fact, all of these examples are showing different ways to create React elements, regardless of if we're using JSX or the `jsx` transform API.

```jsx
<Hello />

<div className="container">
  Hello!
</div>

jsx(Badge, {
  name: "Tyler McGinnis",
  handle: "tylermcginnis",
  img: "https://avatars0.githubusercontent.com/u/2933430"
})
```

Elements vs Components

# What is this called?

```jsx
<Icon />
```

---

- [ ] A component

- [x] An element 

- [ ] A function invocation

- [ ] A component instance

---

The value that is returned by a React Component is called a React Element.

# Why does React use an object representation of the DOM?

---

- [x] Objects are lightweight and easy to create and destroy

- [x] To easily compare the current element with the previously rendered element

- [x] In order to only update the DOM nodes that have changed

- [x] To avoid wiping out and recreating the entire DOM tree

---

The object representation of the DOM that React builds is lightweight and easy to create and destroy. It is also easy to compare the current element with the previously rendered element. This allows React to only update the DOM nodes that have changed.

# What does `jsx()` from the `react/jsx-runtime` do?

---

- [ ] It creates a React Component instance
- [ ] It creates a React Component class
- [x] It creates a React Element

---

Why is this good to know? Because it both gives us an idea of how React works under the hood as well as a better vocabulary when talking about React.

# What is a React Component?

---

- [x] A function that can accept input and returns a React Element
- [ ] A function that can accept input and returns a React Component
- [ ] A function that can accept input and returns a React Component instance
- [ ] A function that can accept input and returns a React Component class

---

React Components are just functions that can accept input and return a React Element.

Describing UI

To build a modern, interactive application, you’re going to need the ability to listen to and respond to events – obviously. Thankfully, the API to do this in React is fairly simple and it involves two things you’re already familiar with – props and functions.

Let's start off with the most basic example, alerting <Sparkle>OUCH</Sparkle> whenever a user clicks on a button.

First, we'll start with a button element.

<CodePreview hideStrictModeToggle template="react" lineLimit="8" previewHeight="100px">

```jsx App.jsx active
export default function AlertButton() {
  return (
    <button>
      Alert
    </button>
  )
}
```

</CodePreview>

Now let's create a function which will encapsulate the logic for what happens when a user clicks on the button. We'll call it `handleClick`.

<CodePreview hideStrictModeToggle template="react" previewHeight="100px">

```jsx App.jsx active
export default function AlertButton() {
  const handleClick = () => alert("OUCH")

  return (
    <button>
      Alert
    </button>
  )
}
```

</CodePreview>

Finally, we want to tell React to invoke our `handleClick` function whenever a user clicks on our `button` element. To do that, we can pass `button` an `onClick` prop, which will be set to our `handleClick` function.

<CodePreview hideStrictModeToggle template="react" previewHeight="100px">

```jsx App.jsx active
export default function AlertButton() {
  const handleClick = () => alert("OUCH")

  return (
    <button onClick={handleClick}>
      Alert
    </button>
  )
}
```

</CodePreview>

Now, whenever our `button` is clicked, React will invoke `handleClick`.

Basic, yes – but this example demonstrates some important concepts and patterns that are consistent regardless of the complexity of the event you're listening for.

First, it's a good idea to encapsulate the event handler into its own function, and it's common practice to name the function `handle` + the event name – in our case `handleClick`.

```js
const handleClick = () => {}

const handleFocus = () => {}

const handleChange = () => {}
```

Next, you'll notice that we're passing our event handler as a _reference_ to `onClick`, not as an _invocation_. Note the difference between these two `onClick` props.

```jsx
<button onClick={handleClick}>
  Passing a Reference
</button>

<button onClick={handleClick()}>
  Passing an Invocation
</button>
```

For the record, this is true for passing any function as a prop and not just event handlers.

If we pass `onClick` an _invocation_, à la `handleClick()`, as soon as the JavaScript engine encounters the invocation, it will invoke the function and pass the return value to `onClick`. This is obviously not what we want.

Instead, we want to pass `onClick` a _reference_ to the function, so that it can invoke the function when the event occurs.

Next, you'll notice that we created our event handler _inside_ the component, not outside of it. This is also a common pattern, but it may feel unintuitive at first. Can you think of why we do this?

To see why, let's adjust our example a bit. Instead of alerting `OUCH`, let's alert whatever is passed in as a `message` prop to our `AlertButton` component.

```jsx
export default function AlertButton({ message }) {
  const handleClick = () => alert(message)

  return (
    <button onClick={handleClick}>
      Alert
    </button>
  )
}
```

By declaring our `handleClick` function inside of our component, we automatically have access to the `message` prop via JavaScript's normal lexical scoping rules.

Notice what happens when we move `handleClick` outside of the component.

<CodePreview hideStrictModeToggle template="react" previewHeight="100px">

```jsx App.jsx
import AlertButton from './AlertButton'

export default function App () {
  return (
    <AlertButton message="OOOOO YEAH!" />
  )
}
```

```jsx AlertButton.js active
const handleClick = (msg) => alert(msg)

export default function AlertButton({ message }) {
  return (
    <button onClick={() => handleClick(message)}>
      Alert
    </button>
  )
}
```

</CodePreview>

We no longer have access to `message` via scope. Instead, we have to pass it as an argument to `handleClick`, which forces us to create _another_ function that we pass to `onClick`. This indirection is unnecessary and is a good indication that we should move `handleClick` back inside of our component so we can take advantage of lexical scoping.

<CodePreview hideStrictModeToggle template="react" previewHeight="100px">

```jsx App.jsx
import AlertButton from './AlertButton'

export default function App () {
  return (
    <AlertButton message="OOOOO YEAH!" />
  )
}
```

```jsx AlertButton.js active
export default function AlertButton({ message }) {
  const handleClick = () => alert(message)

  return (
    <button onClick={handleClick}>
      Alert
    </button>
  )
}
```

</CodePreview>

One reason why your intuition might be telling you to move `handleClick` outside of the component is because you're worried about performance. After all, if it's inside the component, then JavaScript will have to create a new function every time the component renders, right?

Correct, and that's (mostly) fine.

Turns out, JavaScript is _really_ good at creating and destroying functions. To the point where it's usually a non-issue. For the _very few_ edge cases where this isn't true, we have some options we'll learn about later in the course.

So at this point you know how to add a click handler to a `button` (which is <Emph color="var(--blue)">cool</Emph>), but let's look at a scenario that isn't straight out of a generic React tutorial.

Say we wanted to build something like this, a little game where the user has a certain amount of time to copy the main emoji from a list of smaller emojis below.

<CodePreview 
  hideStrictModeToggle 
  template="react"
  previewHeight="300px"
  hideEditor
>

```jsx App.jsx hidden
import * as React from "react"

const emojis = [
  {
    id: "frown",
    emoji: "🙁",
  },
  {
    id: "mid",
    emoji: "😐",
  },
  {
    id: "smile",
    emoji: "🙂",
  },
]

const selectRandomElement = (arr) => {
  return arr[Math.floor(Math.random() * arr.length)]
}

export default function App () {
  const selected = selectRandomElement(emojis)

  const handleCopy = (e) => {
    if (e.target.innerText !== selected.emoji) {
      alert("Wrong emoji")
    } else if (e.timeStamp > 5000) {
      alert("Too slow. Reset and try again.")
    } else {
      alert("🎉 Winner!")
    }
  }

  const handleReset = () => {
    window.location.reload()
  }

  return (
    <div>
      <h1>{selected.emoji}</h1>
      <p>copy this emoji</p>
      <ul>
        {emojis.map(({ id, emoji}) => {
          return (
            <li key={id} onCopy={handleCopy} >
              {emoji}
            </li>
          )
        })}
      </ul>
      <button onClick={handleReset}>Reset</button>
    </div>
  )
}
```

```css styles.css hidden
body {
  display: flex;
  justify-content: center;
  align-items: center;
}

body h1 {
  text-align: center;
  font-size: 65px;
  margin: 0;
  line-height: 75px;
}

body p {
  text-align: center;
  margin: 0;
  font-size: 16px;
}

body ul {
  display: flex;
  justify-content: center;
  align-items: center;
  padding: 0;
  margin-bottom: 5px;
}

body li {
  list-style-type: none;
  font-size: 35px;
  margin: 0 5px;
}

body button {
  margin: 0px auto 0 auto;
  background: transparent;
  color: var(--yellow);
  text-decoration: underline;
  display: block;
}
```

</CodePreview>

Try it for yourself. Hit `RESET` then copy (using your keyboard or mouse) whatever the highlighted emoji is.

Fun. Let's start off with the easy parts, just the UI. 

We'll have an array of emojis, a function for selecting a random emoji, and some JSX.

<CodePreview 
  hideStrictModeToggle 
  template="react"
  previewHeight="300px"
>

```jsx App.jsx active
import emojis from "./emojis"

const selectRandomElement = (arr) => {
  return arr[Math.floor(Math.random() * arr.length)]
}

export default function App () {
  const selected = selectRandomElement(emojis)

  return (
    <div>
      <h1>{selected.emoji}</h1>
      <p>copy this emoji</p>
      <ul>
        {emojis.map(({ id, emoji}) => {
          return (
            <li key={id}>
              {emoji}
            </li>
          )
        })}
      </ul>
      <button>Reset</button>
    </div>
  )
}
```

```js emojis.js
const emojis = [
  {
    id: "frown",
    emoji: "🙁",
  },
  {
    id: "mid",
    emoji: "😐",
  },
  {
    id: "smile",
    emoji: "🙂",
  },
]

export default emojis
```

```css styles.css hidden
body {
  display: flex;
  justify-content: center;
  align-items: center;
}

body h1 {
  text-align: center;
  font-size: 65px;
  margin: 0;
  line-height: 75px;
}

body p {
  text-align: center;
  margin: 0;
  font-size: 16px;
}

body ul {
  display: flex;
  justify-content: center;
  align-items: center;
  padding: 0;
  margin-bottom: 5px;
}

body li {
  list-style-type: none;
  font-size: 35px;
  margin: 0 5px;
}

body button {
  margin: 0px auto 0 auto;
  background: transparent;
  color: var(--yellow);
  text-decoration: underline;
  display: block;
}
```

</CodePreview>

Now let's work on our event handler that we'll pass as an <Popover content={<p>Naturally, React will invoke this event handler whenever the user copies one of the emojis.</p>}>`onCopy`</Popover> prop to each of our three emojis.

This event handler will need to check both if the user copied the right emoji, as well as if they did it in under 5 seconds. If both of those conditions are true, we'll `alert` the user that they won. If not, we'll tell them why they lost.

This does bring up a new scenario though. We now need to know some specific information about the event that was triggered. Specifically, we need to know *which* emoji was copied so we can see if it was the right one.

This brings us to the last piece of knowledge you need for managing events in React. Whenever an event handler is called by React, React will pass an object as the first argument to the event handler that contains all the information about the event that was triggered.

In our example, that event object will look something like this.

```js
SyntheticBaseEvent {
  bubbles: true,
  cancelable: true,
  clipboardData: DataTransfer {},
  currentTarget: null,
  defaultPrevented: false,
  eventPhase: 3,
  target: li,
  timeStamp: 52607.59999999404,
  type: "copy",
}
```

Though there's a lot of extraneous data here, there are a few things that'll be helpful to us – namely the `target` and `timeStamp` properties.

`target` is the element that triggered the event (which we'll be able to use to figure out which emoji was copied) and `timeStamp` tells us how long it's been since the document finished loading and the event occurred (which we'll be able to use to figure out if the user was fast enough).

With that knowledge, building out our event handler is trivial. We'll compare `e.target.innerText` to the `selected` emoji to see if the user selected the right one and we'll check if `e.timeStamp` is less than `5000` to see if the user selected the emoji in time.

<CodePreview 
  hideStrictModeToggle 
  template="react"
  previewHeight="300px"
  lineLimit={22}
>

```jsx App.jsx active mark=10:18,27[16:35]
import emojis from "./emojis"

const selectRandomElement = (arr) => {
  return arr[Math.floor(Math.random() * arr.length)]
}

export default function App () {
  const selected = selectRandomElement(emojis)

  const handleCopy = (e) => {
    if (e.target.innerText !== selected.emoji) {
      alert("Wrong emoji")
    } else if (e.timeStamp > 5000) {
      alert("Too slow. Reset and try again.")
    } else {
      alert("🎉 Winner!")
    }
  }

  return (
    <div>
      <h1>{selected.emoji}</h1>
      <p>copy this emoji</p>
      <ul>
        {emojis.map(({ id, emoji}) => {
          return (
            <li onCopy={handleCopy} key={id}>
              {emoji}
            </li>
          )
        })}
      </ul>
      <button>Reset</button>
    </div>
  )
}
```

```js emojis.js
const emojis = [
  {
    id: "frown",
    emoji: "🙁",
  },
  {
    id: "mid",
    emoji: "😐",
  },
  {
    id: "smile",
    emoji: "🙂",
  },
]

export default emojis
```

```css styles.css hidden
body {
  display: flex;
  justify-content: center;
  align-items: center;
}

body h1 {
  text-align: center;
  font-size: 65px;
  margin: 0;
  line-height: 75px;
}

body p {
  text-align: center;
  margin: 0;
  font-size: 16px;
}

body ul {
  display: flex;
  justify-content: center;
  align-items: center;
  padding: 0;
  margin-bottom: 5px;
}

body li {
  list-style-type: none;
  font-size: 35px;
  margin: 0 5px;
}

body button {
  margin: 0px auto 0 auto;
  background: transparent;
  color: var(--yellow);
  text-decoration: underline;
  display: block;
}
```

</CodePreview>

Now the only thing left to do is create our event handler for our `reset` button. 

This one is simple, we'll just call `location.reload()` to reload the page.

<CodePreview 
  hideStrictModeToggle 
  template="react"
  previewHeight="300px"
  lineLimit={26}
>

```jsx App.jsx active mark=20:22,37
import emojis from "./emojis"

const selectRandomElement = (arr) => {
  return arr[Math.floor(Math.random() * arr.length)]
}

export default function App () {
  const selected = selectRandomElement(emojis)

  const handleCopy = (e) => {
    if (e.target.innerText !== selected.emoji) {
      alert("Wrong emoji")
    } else if (e.timeStamp > 5000) {
      alert("Too slow. Reset and try again.")
    } else {
      alert("🎉 Winner!")
    }
  }

  const handleReset = () => {
    window.location.reload()
  }

  return (
    <div>
      <h1>{selected.emoji}</h1>
      <p>copy this emoji</p>
      <ul>
        {emojis.map(({ id, emoji}) => {
          return (
            <li onCopy={handleCopy} key={id}>
              {emoji}
            </li>
          )
        })}
      </ul>
      <button onClick={handleReset}>Reset</button>
    </div>
  )
}
```

```js emojis.js
const emojis = [
  {
    id: "frown",
    emoji: "🙁",
  },
  {
    id: "mid",
    emoji: "😐",
  },
  {
    id: "smile",
    emoji: "🙂",
  },
]

export default emojis
```

```css styles.css hidden
body {
  display: flex;
  justify-content: center;
  align-items: center;
}

body h1 {
  text-align: center;
  font-size: 65px;
  margin: 0;
  line-height: 75px;
}

body p {
  text-align: center;
  margin: 0;
  font-size: 16px;
}

body ul {
  display: flex;
  justify-content: center;
  align-items: center;
  padding: 0;
  margin-bottom: 5px;
}

body li {
  list-style-type: none;
  font-size: 35px;
  margin: 0 5px;
}

body button {
  margin: 0px auto 0 auto;
  background: transparent;
  color: var(--yellow);
  text-decoration: underline;
  display: block;
}
```

</CodePreview>

And that's it. Now, if the user copies the right emoji in under 5 seconds, they'll get a winner alert.

Before we end, if you're an experienced web developer, you're probably aware that there are a lot more events you'll eventually want to listen for other than just `onClick` and `onCopy`. 

For your future reference, here's every event you can listen for in React including what they do (if you click on them).

<ReactEventsList />

Handling Events

# How can we add our `handleClick` event handler to our button?

```jsx
function Btn () {
  const handleClick = () => {
    console.log('clicked')
  }

  return (
    <button>
      Submit
    </button>
  )
}
```

---

- [ ]

```jsx
<button handleClick={handleClick}>
  Submit
</button>
```

- [x]

```jsx
<button onClick={handleClick}>
  Submit
</button>
```

- [ ]

```jsx
<button @click={handleClick}>
  Submit
</button>
```

- [ ]

```jsx
<button [click]={handleClick}>
  Submit
</button>
```

---

To add a click handler to an element, you use the `onClick` prop.

# What's wrong with this code?

```jsx
function Btn () {
  const handleClick = () => {
    console.log('clicked')
  }

  return (
    <button onClick={handleClick()}>
      Submit
    </button>
  )
}
```

---

- [ ] Nothing

- [ ] `onClick` accepts a string, "handleClick()", not a function

- [x] `onClick` accepts a function, not the result of invoking a function

- [ ] `onClick` accepts a string, "handleClick", not a function

---

There's no indirection with React. If you want to add a click handler to a button, give `onClick` a reference to the click handler, not a string or anything else.

```jsx
function Btn () {
  const handleClick = () => {
    console.log('clicked')
  }

  return (
    <button onClick={handleClick}>
      Submit
    </button>
  )
}
```

# What gets alerted when the button is clicked?

```jsx
const handleClick = () => alert(message)

function AlertButton({ message }) {
  return (
    <button onClick={handleClick}>
      Click Me
    </button>
  )
}

export default function App () {
  return (
    <AlertButton message="Hello, world!" />
  )
}
```

---

- [ ] "Hello, world!"

- [ ] `undefined`

- [x] Nothing, you get a [`ReferenceError`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ReferenceError)

- [ ] A synthetic event

---

The reason we keep event handlers inside of the component is so they'll have access to any state or props via closures.

```jsx
function AlertButton({ message }) {
  const handleClick = () => alert(message)

  return (
    <button onClick={handleClick}>
      Click Me
    </button>
  )
}

export default function App () {
  return (
    <AlertButton message="Hello, world!" />
  )
}
```

# Putting event handler functions inside the component will lead to performance issues since React will have to re-create them on every render?

---

- [ ] true

- [x] false

---

React will have to re-create the function on every render, but it's unlikely to be a performance issue since the cost of creating functions is negligible.

Whenever we're dealing with events in React, we can extract the logic for those events into their own event handlers. 

The goal with this challenge is to make it so when the user types __more than 10 characters__ into the input field, they'll get an alert that says "Character limit exceeded".

#### Tasks

1. Don't show an alert if the input is under the character limit
2. Show an alert if the input exceeds the character limit

#### The Result

The final version of your app should behave like this.

<CodePreview
  hideEditor
  sandboxId="character-limit-solution-oldjm1"
  previewHeight="250px"
/>

---

#### Need some help?

<Accordion heading="Hint #1">

Because we're dealing with events, you'll first want to create an event handler that you can pass as an `onChange` prop to your `input` field.

```jsx
function handleChange() {}

...

<input onChange={handleChange}>
```

</Accordion>

<Accordion heading="Hint #2">

When you pass a function as an `onChange` prop, when the event occurs, React will invoke that function passing it information about the event as the first argument. You can use that first argument to get the text in the input field using `event.target.value`.

```jsx
function handleChange(event) {
  const text = event.target.value;
}
```

</Accordion>

<Accordion heading="Hint #3">

To check how many characters are in the input field, you can use `event.target.value.length`.

```jsx
if (event.target.value.length > 10) {

}
```

</Accordion>

#### Solution

<Accordion heading="Show me the code">

```jsx
export default function App() {
  const handleChange = (event) => {
    if (event.target.value.length > 10) {
      alert("Character limit exceeded");
    }
  };

  return (
    <section>
      <h1>Character Limit</h1>
      <input onChange={handleChange} placeholder="Enter some text" />
    </section>
  );
}
```

</Accordion>

Character Limit

You'll notice that this challenge looks similar to the last one. However, instead of hard coding the character limit as we did before, we now want to make our component a little more flexible and pass it in via a prop. Fix up the code so it works as before, but with the new `characterLimit` prop.

#### Tasks

1. Don't show an alert if the input length is within character limit
2. Show an alert if the input length exceeds the character limit

#### The Result

The final version of your app should behave like this.

<CodePreview
  hideEditor
  sandboxId="character-limit-props-solution-voyn4c"
  previewHeight="400px"
/>

Character Limit – Props

React, in its purest form, is a library for building user interfaces. It's so simple that the entire mental model can be represented as a formula.

<ReactViewEquation />

If we break it down, we've seen how you create your <Emph color="var(--yellow)">View</Emph> with JSX, and how you encapsulate that View inside of a <Emph color="var(--green)">function</Emph> to get your component. But there's still one piece of the formula we need to talk about, <Emph color="var(--blue)">state</Emph>.

State, and specifically the ability for individual components to own and manage their own state, is what makes React so powerful, and it's what allows you to build complex user interfaces out of simple, isolated components.

So what does adding state to a component look like? Let's say we were building a simple __counter__ app that keeps track of how many times a user has clicked a button.

Your first assumption might be to do something like this.

<CodePreview hideStrictModeToggle template="react" previewHeight="100px">

```css styles.css hidden
.container {
  display: grid;
  justify-items: center;
  align-items: start;
  height: 100%;
}

.container button {
  font-size: 30px;
  padding: 15px 30px;
}
```

```jsx App.jsx active
export default function Counter() {
  let count = 0

  const handleClick = () => count++

  return (
    <button onClick={handleClick}>
      {count}
    </button>
  )
}
```

</CodePreview>

After all, React is <Sparkle>just JavaScript</Sparkle>, right? And the way you add state to a function is by creating a variable. Unfortunately, this won't work. Can you spot why?

Ironically, it won't work for the same reason, because React _is_ just JavaScript – and that's not how JavaScript works.

This is clearer if we take React out of the picture entirely. Here's a normal JavaScript function.

<CodePreview template="javascript">

```jsx index.js active
function counter() {
  let count = 0
  count++
  return count
}

console.log(counter())
console.log(counter()) 
console.log(counter()) 
```

</CodePreview>

Without React, you wouldn't expect the `count` variable to persist across different function invocations. Each invocation is its own isolated environment with its own scope and context. With React, it's no different.

So how do we get around this?

Well, we need some help from React. Specifically, we need a way to tell React to preserve the value of `count` between different invocations of our `Counter` function (React refers to these function component invocations as _renders_).

Lucky for us, React comes with a <Emph color="var(--brand-orange)">hook</Emph> that does exactly this called `useState`.

<Aside accentColor="var(--brand-orange)" emoji={"🪝"} title="Hook 'Em">

`useState` is the first of many hooks that you'll learn in this course. You can think of hooks as special functions that allow you to get help from React.

The reason they're special is because they have a few limitations. Namely that they must be prepended with `use` and you can’t call hooks inside conditions, loops, or other nested functions.

We'll go deeper into hooks throughout the course, but here's a simple mental model you can use for them.

"Hooks are functions, but it’s helpful to think of them as unconditional declarations about your component’s needs. You _use_ React features at the top of your component similar to how you _import_ modules at the top of your file." - React docs

</Aside>

### useState

`useState` is the blessed way to preserve a value across component renders. It comes built-in with React and can be accessed via `React.useState`. It takes in a single argument, the initial value for that piece of state, and returns an array with the first item being the state value and the second item being a way to update that state.

```js
const stateArray = React.useState("initial state value")
const state = stateArray[0]
const setState = stateArray[1]

console.log(state) // "initial state value"
setState('new state value')
```

<Aside emoji="⛏" title="Array Destructuring">

You may notice that the code above feels a little clunky. This stems from the fact that `useState` returns an array. We can clean this up by using array destructuring.

If you're not familiar, array destructuring allows you to pluck multiple items from an array and assign them to variables in bulk.

```js
const scores = [86, 91, 82]
const [firstGame, secondGame, thirdGame] = scores
```

Because `useState` returns an array, we can use array destructuring to clean up our `useState` invocation by assigning the first item to `state` and the second item to `setState`.

```js
const [state, setState] = React.useState(
  "initial state value"
)
```

</Aside>

Now that we know the purpose of `useState` as well as how it works, let's update our `Counter` example from earlier to _use_ it.

<CodePreview hideStrictModeToggle template="react" previewHeight="150px">

```css styles.css hidden
.container {
  display: grid;
  justify-items: center;
  align-items: start;
  height: 100%;
}

.container button {
  font-size: 30px;
  padding: 15px 30px;
}
```

```jsx App.jsx active
import * as React from "react"

export default function Counter() {
  const [count, setCount] = React.useState(0)

  const handleClick = () => setCount(count + 1)

  return (
    <button onClick={handleClick}>
      {count}
    </button>
  )
}
```

</CodePreview>

Now, regardless of how many times React renders our `Counter` component, the value of `count` will persist across all of those renders. But this brings up an interesting question, when _does_ React render our components exactly?

We have a whole lesson dedicated to that question later in the course, but here's a sneak preview. The answer is surprisingly simple. React re-renders a component whenever its state changes. 

<ManagingState />

So in our example, whenever the user clicks our `button`, React will increment `count` by 1, re-render our `Counter` component getting a description of the UI based on the current state of `count`, then update the DOM where appropriate.

Preserving Values with useState

# What are Hooks in React?

---

- [ ] A collection of pre-built components in React that can be easily customized and reused across multiple projects

- [ ] A way to persist values between renders

- [x] unconditional declarations about your component’s needs

- [x] Special functions that allow you to get help from React

---

"Hooks are functions, but it’s helpful to think of them as unconditional declarations about your component’s needs. You use React features at the top of your component similar to how you import modules at the top of your file." - React docs

# What limitations do Hooks have?

---

- [x] You can't call them inside conditions, loops, or other nested functions

- [ ] They can't access browser specific APIs like `setInterval` or `window`.

- [x] They must start with `use`

- [ ] They cannot access props

---

# What's wrong with this code?

```jsx
export default function ToggleMessage() {
  let visible = false;

  const toggleVisibility = () => {
    visible = !visible;
  };

  return (
    <div>
      <button onClick={toggleVisibility}>Toggle Message</button>
      {visible && <p>The message is now visible!</p>}
    </div>
  );
}
```

---

- [ ] Nothing

- [ ] The `visible` variable is not being used

- [x] The UI won't update when `visible` changes

- [x] `visible` won't persist between renders

---

In order to persist a value between renders and have React update the UI when that value changes, you need to use the `useState` hook.

```jsx
import * as React from "react";

export default function ToggleMessage() {
  const [visible, setVisible] = React.useState(false);

  const toggleVisibility = () => {
    setVisible(!visible)
  };

  return (
    <div>
      <button onClick={toggleVisibility}>Toggle Message</button>
      {visible && <p>The message is now visible!</p>}
    </div>
  );
}
```

# What does the `useState` Hook allow you to do?

---

- [x] Trigger a re-render of the component

- [ ] Pass data to child components

- [x] Add state to a component

- [x] Preserve a value between renders

---

`useState` is the blessed way to preserve a value across component renders and it also comes with a way to trigger a re-render when that state value changes. It comes built-in with React and can be accessed via `React.useState`.

```js
const stateArray = React.useState("initial state value")
const state = stateArray[0]
const setState = stateArray[1]
```

# What's wrong with this code?

```jsx
import * as React from "react";

export default function ThemeSwitcher() {
  const [setTheme, theme] = React.useState("light")

  const handleClick = () => {
    setTheme(theme === "dark" ? "light" : "dark");
  };

  return (
    <button onClick={handleClick} className={theme}>
      Switch Theme
    </button>
  );
}
```

---

- [ ] Nothing

- [x] Our state destructuring is backwards

- [ ] We can't use dynamic state values as `className`

- [ ] `useState` returns an object, not an array

---

The first item returned from `useState` is the state value itself, while the second is the updater function.

```jsx
import * as React from "react"

export default function ThemeSwitcher() {
  const [theme, setTheme] = React.useState("light")

  const handleClick = () => {
    setTheme(theme === "dark" ? "light" : "dark");
  };

  return (
    <button onClick={handleClick} className={theme}>
      Switch Theme
    </button>
  );
}
```

In order to persist a value across renders and update the UI when that value changes, we need to use React's `useState` hook. In this challenge, you'll need to create a button that toggles the `mode` state between `light` and `dark`.

#### Tasks

1. The app renders without crashing
2. `mode` defaults to `dark`
3. `mode` toggles between `dark` and `light` when the button is clicked

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="light-switch-solution-ochngq"
  previewHeight="200px"
/>

Light Switch

You may have noticed that in our last "Light Switch" example, we had some wasted keystrokes. Specifically, depending on how you set it up, you may have written two methods (`handleDarkMode` and `handleLightMode`) for updating our `mode` state like in our current starting code. Also, we rendered two buttons, one for each event handler. 

In this challenge, consolidate our logic into a *single* event handler and a *single* button element.

#### Tasks

1. The app renders without crashing
2. `mode` defaults to `dark`
3. `mode` toggles between `dark` and `light` when the button is clicked

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="light-switch-concise-solution-utd9hg"
  previewHeight="200px"
/>

Light Switch - Concise

This challenge is pretty straightforward. Increment or decrement `count` whenever the user clicks on the corresponding button.

#### Tasks

1. Render the initial state correctly
2. Increment `count` when the user clicks the "+" button
3. Decrement `count` when the user clicks the "-" button
4. Render the correct count after multiple button clicks

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="counter-solution-qof09e"
  previewHeight="300px"
/>

Counter

Using useState

# You can only have one `useState` per component

---

- [] true

- [x] false

---

Of course not. You can have as many as you want.

# What's wrong with this code?

```jsx
...

const [state, setState] = React.useState({
  loading: true,
  authed: false,
  repos: []
})

const handleAuthComplete = () => {
  setState({ authed: true })
}

...
```

---

- [ ] Nothing

- [ ] `setState` is not a function

- [ ] You can't have objects as state

- [x] `setState` replaces the state, so we're getting rid of `loading` and `repos`

---

To fix this, we can spread the existing state into the new state.

```jsx
const handleAuthComplete = () => {
  setState({
    ...state,
    authed: true
  })
}
```

# What's the rule of thumb for "lifting state up" in React?

---

- [ ] Whenever you have state that only one component depends on, you should lift that state up to the nearest parent component

- [ ] Whenever you have an object as state, you should lift that object up so you don't override properties on it

- [x] Whenever you have state that multiple components depend on, you'll want to lift that state up to the nearest parent component and then pass it down via props

- [ ] If you're having performance issues, lift your state up as high as possible to prevent extra re-renders

---

# When lifting state up, you decouple where the state lives from the event handlers that update that state. To solve this,

---

- [x] Create an updater function in the parent component where the state lives and, via `props`, invoke that function from the child component(s) where the event handler(s) live

- [ ] Pass the entire state object as a prop to the child component and let the child component directly modify the state object

- [ ] Create separate state variables in both parent and child components, and manually keep them in sync

- [ ] Create an updater function in the child component and, via `props`, pass it up to the parent component that owns the state

---

# What's wrong with this code?

```jsx
const handleRemoveItem = (index) => {
  items.splice(index, 1)
  setItems(items)
}
```

---

- [ ] Nothing

- [ ] Instead of mutating the state directly, we should use `slice`

- [x] Instead of mutating the state directly, we should use `filter`

- [ ] We should use `setItems` updater function instead of mutating the state directly

---

The canonical way to remove an element from an array is to use JavaScript's `filter` method to create a new array, filtering out the element that should be removed.

```jsx
const handleRemoveItem = (index) => {
  const newItems = items.filter((item, i) => i !== index)
  setItems(newItems)
}
```

# What's wrong with this code?

```jsx
const handleNewItem = (item) => {
  const newItems = [...items, item]
  setItems(newItems)
}
```

---

- [x] Nothing

- [ ] To add an item to our array, we should use `.push`

- [ ] To add an item to our array, we should use `.add`

- [ ] To add an item to our array, we should use `React.push`

# What's wrong with this code?

```jsx
const handleUpdateItem = (index, item) => {
  const newItems = items
  newItems[index] = item
  setItems(newItems)
}
```

---

- [ ] Nothing

- [ ] To update an item in our array, we should use `splice`

- [x] To update an item in our array, we should use `map`

- [ ] To update an item in our array, we should use `slice`

---

To update an element, use JavaScript's `map` method to create a new array, updating the specific element where appropriate.

```jsx
const handleUpdateItem = (index, updatedItem) => {
  const newItems = items.map((item, i) => 
    i === index ? updatedItem : item
  )
  setItems(newItems)
}
```

Now that you know how to add state in React, let's revisit our Character Limit challenge from earlier in the course and make it a little more sophisticated.

The goal of this app is to get some input from the user, but only "submit" that input if its length is less than or equal to `characterLimit` (20 characters, by default). Unlike our other "Character Limit" challenges, this one shows the user how many characters they have left before they hit the limit.

#### Tasks

1. `LimitedTextInput` renders an input and submit button
2. Update the remaining characters count when the user types
3. Add an `error` class to the "Characters remaining:" `span` element when the user exceeds the character limit and a `no-error` when they haven't
4. alert "The input exceeds the character limit. Please shorten your text." when the user submits a form with too many characters
5. alert "Thanks for your submission" when the user submits a form with an acceptable number of characters
6. Reset the input back to an empty string when the form is successfully submitted

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="smart-character-limit-solution-9pvc05"
  previewHeight="300px"
/>

Smart Character Limit

In this challenge, you're going to implement the logic for an input field that accepts a password. However, instead of a boring input field, this one is like... slightly less boring. 

What makes it less boring is it gives the user the option to toggle the visibility of the password by giving them a button with some cute emojis, 🙊 or 🙈 depending on if the password is visible.

All the JSX is in place, all you need to do is properly handle the different states of the component and update `handleChange` and `handleToggleVisibility` so that the component behaves as expected.

#### Tasks

1. Update the password length count when the input changes
2. Update the text style based on the password length threshold
3. Allow users to toggle the password visibility
4. Show an alert with a success message when the password length is equal to or above the threshold on form submission
5. Show an alert with an error message when the password length is below the threshold on form submission

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="password-toggle-solution-6jyf2c"
  previewHeight="250px"
/>

Password Toggle

In this challenge you're given a multistep form for getting data from the user. With the JSX already in place, update the component's state and functions in order to allow the user to progress through the form, updating the state as necessary.

#### Tasks

1. Allow the user to transition to the next step
2. Allow the user to return to the previous step
3. Update the `formData` as the user progresses through the form
4. When finished, submit the form and reset the component's state

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="multistep-form-solution-8nmccq"
  previewHeight="415px"
/>

Multistep Form

In this challenge we're going to get meta and build a form builder. It looks complex, but with the JSX already in place, your primary job is to manage the `formFields` array. The user will need to be able to add items to it, update items in it, and remove items from it.

All of the functions with their parameters are in place, you'll just need to examine the JSX and update each accordingly.

#### Tasks

1. Allow users to add a form field
2. Allow users to delete form fields
3. Allow users to update form field values
4. Allow users to submit the dynamic form with the new values

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="form-builder-solution-o4zyd0"
  previewHeight="750px"
/>


Form Builder

Why React Renders

# What is rendering in React?

---

- [ ] The process of converting JSX into regular JavaScript the browser can understand

- [ ] The process of evaluating the state of your component tree

- [ ] The process of creating a new instance of a React component

- [x] A fancy way of saying that React calls your function component with the intent of eventually updating the View

# What happens when React renders a component?

---

- [x] React creates a snapshot of your component

- [ ] React attaches event listeners and other interactivity to the HTML

- [ ] React replaces the entire DOM with the new snapshot UI

- [x] React takes the snapshot and uses it to update the view

---

When React renders a component, two things happen.

First, React creates a snapshot of your component which captures everything React needs to update the view at that particular moment in time. `props`, `state`, event handlers, and a description of the UI (based on those props and state) are all captured in this snapshot.

From there, React takes that description of the UI and uses it to update the View.

# How do you create the `root` of your application?

---

- [ ]

```jsx
import { createRoot } from "react"

import App from "./App"

const rootElement = document.getElementById("root")
const root = createRoot(rootElement)

root.render(<App />)

```

- [ ]

```jsx
import { createRoot } from "react-dom/client"

import App from "./App"

const rootElement = document.getElementById("root")
const root = createRoot(rootElement)

root.render(App)

```

- [ ]

```jsx
import { createRoot } from "react"

import App from "./App"

const rootElement = document.getElementById("root")
const root = createRoot(rootElement)

root.render(App)

```

- [x]

```jsx
import { createRoot } from "react-dom/client"

import App from "./App"

const rootElement = document.getElementById("root")
const root = createRoot(rootElement)

root.render(<App />)

```

# When does React re-render?

---

- [ ] When the props of a component change

- [ ] When an event handler executes

- [x] When the state of a component changes

- [ ] When `useState`s updater function executes

---

This may be surprising, but it's true. The only thing that can trigger a re-render of a component in React is a state change. If you call `setState` but React sees that the new state is the same as the state in the snapshot, it won't re-render.

# What gets alerted the first time the button is clicked?

```jsx
import * as React from "react"

function LightSwitch() {
  const [state, setState] = React.useState("on")

  const handleClick = () => {
    setState(state === "on" ? "off" : "on")
    alert(`The switch is ${state}`)
  }

  return (
    <button onClick={handleClick}>
      {state}
    </button>
  )
}
```

---

- [x] The switch is on

- [ ] The switch is off

---

When our `handleClick` event handler runs, it has access to the props and state as they were in the moment in time when the snapshot was created – in that moment, `state` was `on`. Therefore, when we alert `state`, we get `on`.

# What happens when the button is clicked?

```jsx
import * as React from "react"

function BrokenLightSwitch() {
  const [state, setState] = React.useState("on")

  const handleClick = () => {
    setState("on")
  }

  return (
    <button onClick={handleClick}>
      {state}
    </button>
  )
}
```

---

- [x] Nothing

- [] React re-renders with the same state

- [] React re-renders with new state

---

React will only re-render if the event handler contains an invocation of `useState`'s updater function (✅) and React sees that the new state is different than the state in the snapshot (❌) – in this case it's not so it will bail out of re-rendering.

# What happens when the `Add 3` button is clicked?

```jsx
import * as React from "react";

export default function Score() {
  const [score, setScore] = React.useState(0);

  const incrementScore = () => {
    setScore(score + 1)
  }

  const handleFreeThrow = () => {
    incrementScore()
  }

  const handleTwoPointer = () => {
    incrementScore()
    incrementScore()
  };

  const handleThreePointer = () => {
    incrementScore()
    incrementScore()
    incrementScore()
  };

  return (
    <main>
      <h1>{score}</h1>
      <button onClick={handleFreeThrow}>Add 1</button>
      <button onClick={handleTwoPointer}>Add 2</button>
      <button onClick={handleThreePointer}>Add 3</button>
    </main>
  );
}
```

---

- [x] `score` gets incremented by 1

- [ ] `score` gets incremented by 2

- [ ] `score` gets incremented by 3

- [ ] `score` doesn't change

---

When the event handler runs, it has access to the props and state as they were in the moment in time when the snapshot was created. In that moment, `score` was `0`.

```js
const incrementScore = () => {
  setScore(0 + 1)
}
```

So it's as if we called this function three times, which, regardless of how many times it was called, would always set `score` to `1`.

# What will the `count` state be updated to when this event handler runs?

```js
const handleClick = () => {
  setCount(10)
  setCount((c) => c + 30)
  setCount(70)
  setCount((c) => c + 100)
}
```

---

- [] 10

- [] 40

- [] 70

- [x] 170

# Is this statement true or false?

Whenever state changes, React will re-render the component that owns that state and all of its child components – regardless of whether or not those child components accept any props.

---

- [x] true

- [] false

# In order to opt-out of React's default behavior of re-rendering all child components when state changes, you use – 

---

- [ ] `React.useCallback`

- [ ] `React.useMemo`

- [ ] `React.memoize`

- [x] `React.memo`

---

`React.memo` is a function that takes in a React component as an argument and returns a new component that will only re-render if its props change.

```js
export default React.memo(Component)
```

# When enabled, StrictMode will...

---

- [x] re-render your components an extra time.

- [ ] run in production

- [x] verify your app is resilient to re-renders

- [x] verify your renders are pure

Bringing React to Life

Up until this point, we've seen how beautifully simple React is in its purest form. You encapsulate UI, state, and event handlers into components, compose those components together, passing data down the component tree as needed via props.

The problem, of course, is nothing muddies the simplicity of a mental model quite like the complexities of reality. 

In the real world, it's not uncommon to need to do things *outside* of React. Fetching data from a server, interacting directly with the DOM, or even using native browser APIs like `setTimeout` or `localStorage` are all examples of real world use cases that don't fit neatly into the React's model.

For React to be of any practical use and not just a theoretical tool we learn about in Computer Science programs, it needs to handle these _outside world_ use cases – and do so in a way that doesn't completely destroy the simplicity of the mental model.

That's what this section is dedicated to, specifically learning how get React to play nicely with the outside world.

Let's dive in.

Reality Check

Managing Effects

# What is Rule #0 for managing side effects in React?

---

- [ ] If a side effect is triggered by an event, put that side effect in an event handler

- [x] When a component renders, it should do so without running into any side effects

- [ ] If a side effect is synchronizing your component with some outside system, put that side effect inside useEffect

- [ ] Don't put side effects inside React components

# What's wrong with this code?

```jsx
import * as React from "react"

export default function App() {
  const [theme, setTheme] = React.useState("light")

  const handleClick = () => {
    switch (theme) {
      case "light":
        setTheme("dark")
        break
      case "dark":
        setTheme("solarized")
        break
      default :
        setTheme("light")
        break
    }
  }

  localStorage.setItem("uidotdev_theme", theme)

  return (
    <div>
      <span>
        {theme}
      </span>
      <button onClick={handleClick}>Next Theme</button>
    </div>
  )
}
```

---

- [ ] Nothing

- [x] Our component's render isn't pure

- [x] Our side effect should be moved into the event handler

- [ ] Our side effect should be moved into useEffect

--- 

The code violates both rule #0 and rule #1. We need to keep our renders pure and if a side effect is triggered by an event, put that side effect in an event handler.

# When should you use `useEffect`?

---

- [ ] When you need to keep your component's state in sync with your component's props

- [ ] When you need to execute logic when a value changes

- [x] When you need to synchronize your component with some outside system

- [x] When you need to remove a side effect from React's rendering flow

# When does `useEffect` run?

---

- [ ] Before render

- [x] After render

- [ ] When a component mounts

- [ ] When a component unmounts


# How would you update the `document`'s title whenever a `timeLeft` variable changes?

---

- [ ]

```js
React.useEffect(() => {
  document.title = `Time Left: ${timeLeft}`
}, ["onUpdate"])
```

- [ ]

```js
React.useEffect(() => {
  document.title = `Time Left: ${timeLeft}`
}, ["onInitialRender", "onUpdate"])
```

- [ ]

```js
React.useEffect(() => {
  document.title = `Time Left: ${timeLeft}`
})
```

- [x]

```js
React.useEffect(() => {
  document.title = `Time Left: ${timeLeft}`
}, [timeLeft])
```

--- 

Instead of telling React when to invoke the effect, you give React all the reactive dependencies that effect needs to run – in our case, just `timeLeft`.

In this challenge, you're given an app that uses `useEffect` as a way to react to changes in the search term. That's not ideal – `useEffect` should be used for synchronizing, not for reacting to changes in a value. Refactor the app to get rid of `useEffect` but keep the same functionality.

#### Tasks

1. Render the list of items
2. Filter the list of items based on search term
3. Don't use `useEffect`

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="search-filter-solution-m51lpd"
  previewHeight="600px"
/>


Search Filter

Managing Effects – Part 2

# In the code below, which values are "reactive"?

```jsx
const greetings = ['Hello', "Hola", "Bonjour"]

function Greeting ({ name }) {
  const [index, setIndex] = React.useState(0)

  const handleClick = () => {
    const nextIndex = index === greetings.length - 1
      ? 0
      : index + 1
    setIndex(nextIndex)

    localStorage.setItem("index", nextIndex)
  }

  React.useEffect(() => {
    const item = localStorage.getItem("index")

    if (item) {
      setIndex(Number(item))
    }
  }, [])

  return (
    <main>
      <h1>{greetings[index]}, {name}</h1>
      <button onClick={handleClick}>Next Greeting</button>
    </main>
  )
}
```

---

- [ ] `greetings`, `name`, `index`

- [ ] `greetings`, `name`, `index`, `handleClick`

- [ ] `name`, `index`

- [x] `name`, `index`, `handleClick`
 
--- 

A reactive value is any value that can change between re-renders. Props, state, or any variables defined inside of a component are all reactive values.

# In what order will our logs run? Assume we're *not* in StrictMode

```jsx
import * as React from "react"

function Logger () {
  const [count, setCount] = React.useState(0)

  React.useEffect(() => {
    console.log("effect")

    window.setTimeout(() => {
      console.log('timeout')
      setCount((c) => c + 1)
    }, 5000)
  }, [ ])

  console.log("rendering")

  return (
    <p>{count}</p>
  )
}
```

---

- [x] "rendering", "effect", "timeout", "rendering"

- [ ] "effect", "rendering", "timeout", "rendering"

- [ ] "rendering", "effect", "timeout", "rendering", "effect"

- [ ] "rendering", "effect", "rendering", "timeout", "rendering"

---

`useEffect` runs *after* render. So we'll get "rendering", then our effect will run logging "effect". Then ~5 seconds later our timeout will run which logs "timeout" and updates `count` which causes a re-render. The next re-render will log "rendering" and then the execution of our code will be finished since the effect doesn't run again because it has no dependencies.

# What's wrong with this code?

```jsx
import * as React from "react";

export default function WindowDimensions() {
  const [width, setWidth] = React.useState(0)
  const [height, setHeight] = React.useState(0)

  React.useEffect(() => {
    const handleResize = () => {
      setWidth(window.innerWidth)
      setHeight(window.innerHeight)
    };

    window.addEventListener("resize", handleResize)
  }, []);

  return (
    <p>
      The current window dimensions are <strong>{width} by {height}</strong>.
    </p>
  );
}
```

---

- [ ] Nothing

- [x] We're not cleaning up our effect which will cause a memory leak when our component is removed from the DOM

- [ ] Our current logic causes an infinite loops since we're setting state inside of `useEffect`

- [ ] We can't access `window` inside of `useEffect`

---

You always need to make sure that if you set up any event listeners or timers, you clean them up when the component is removed from the DOM. Otherwise, you'll have a memory leak.

```jsx
React.useEffect(() => {
  const handleResize = () => {
    setWidth(window.innerWidth)
    setHeight(window.innerHeight)
  };

  window.addEventListener("resize", handleResize)

  return () => {
    window.removeEventListener("resize", handleResize)
  }
}, []);
```

# What's wrong with this effect?

```jsx
React.useEffect(() => {
  let ignore = false

  const handleFetchPokemon = async () => {
    setLoading(true)
    setError(null)

    const { error, response } = await fetchPokemon(id)

    if (ignore) {
      return
    } else if (error) {
      setError(error.message)
    } else {
      setPokemon(response)
    }

    setLoading(false)
  }

  handleFetchPokemon()
}, [id])
```

---

- [ ] Nothing

- [ ] We should fetch the Pokémom in an event handler

- [x] We're not ignoring the result of stale requests

- [ ] We can't use async/await inside of an effect

---

If `useEffect` runs and makes a request to the Pokémon API, and then, before that request resolves, `id` changes, re-running the effect and making *another* request, we need to make sure that when the first stale request resolves, we ignore it.

To do that, we can flip a boolean variable inside the effect's cleanup function.

```jsx
React.useEffect(() => {
  let ignore = false

  const handleFetchPokemon = async () => {
    setLoading(true)
    setError(null)

    const { error, response } = await fetchPokemon(id)

    if (ignore) {
      return
    } else if (error) {
      setError(error.message)
    } else {
      setPokemon(response)
    }

    setLoading(false)
  }

  handleFetchPokemon()

  return () => {
    ignore = true
  }
}, [id])
```

In this challenge, you'll be synchronizing the current time with your component's state by updating the UI every second with the new time. To do that, you'll need the right combination of `useEffect`, component state, and the browser's `setInterval` method.

#### Tasks

1. Update the time every second
2. Clear the timer when unmounted

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="clock-solution-3g1k9h"
  previewHeight="300px"
/>

Clock

In this challenge, you'll be synchronizing the result of fetching  country data from an external API (the `url` below) with your component's state. 

The JSX is finished, so all you need to do is `fetch` the data from the following URL and update the component's state with the result.

```js
const url = `https://restcountries.com/v2/alpha/${countryCode}`;
```

You'll update `data` with the exact JSON response returned from the given `url`.

#### Tasks

1. Display a loading state when fetching data
2. Fetch new data based on the user's input
3. Render an error message if fetch fails

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="country-info-solution-qqlu1r"
  previewHeight="450px"
/>

Country Info

In this challenge, we'll be fetching data from the Hacker News API. However, unlike the other effects challenges, the state and event handlers for this one don't need updating. Instead, given the `fetchData` function, you'll need to synchronize your component with the Hacker News API and then update the JSX appropriately.

This one is tricky so take your time and think it through. Anywhere in the JSX you see `null` or `TODO` you'll need to update it.

#### Tasks

1. Fetch data based on the search query
2. Display the loading state while fetching
3. Fetch new results when the tag filter changes
4. Allow the user to navigate to the next and previous pages
5. Disable the Next and Previous buttons based on the number of pages
6. Display the results in a numbered list, with each page showing the correct position of each post

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="hacker-news-solution-ctj7n0"
  previewHeight="800px"
/>

Hacker News

Preserving Values with useRef

# What does `useRef` allow you to do?

---

- [ ] Persist a value across renders and trigger a re-render when it changes

- [x] Persist a value across renders without triggering a re-render when it changes

- [ ] Transport data anywhere in the component tree

- [ ] Synchronize your component with some outside system

# What's wrong with this code?

```jsx
import * as React from "react"

function Counter() {
  const [count, setCount] = React.useState(0)

  let id

  const clear = () => {
    window.clearInterval(id)
  }

  React.useEffect(() => {
    id = window.setInterval(() => {
      setCount((c) => c + 1)
    }, 1000)

    return clear
  }, [])

  return (
    <div>
      <h1>{count}</h1>
      <button onClick={clear}>Stop</button>
    </div>
  )
}
```

---

- [ ] Nothing

- [ ] `clear` will cause performance issues since it's being redeclared on every render

- [ ] `count` will be redeclared and set to `undefined` whenever `Counter` re-renders

- [x] `id` will be redeclared and set to `undefined` whenever `Counter` re-renders

---

To fix this, we want to make `id` a ref.

```jsx
import * as React from "react"

function Counter() {
  const [count, setCount] = React.useState(0)
  const id = React.useRef()

  const clear = () => {
    window.clearInterval(id.current)
  }

  React.useEffect(() => {
    id.current = window.setInterval(() => {
      setCount((c) => c + 1)
    }, 1000)

    return clear
  }, [])

  return (
    <div>
      <h1>{count}</h1>
      <button onClick={clear}>Stop</button>
    </div>
  )
}
```

# What's wrong with the code below?

```jsx
import * as React from "react"
import { formatTime } from "./utils"

export default function Stopwatch () {
  const [seconds, setSeconds] = React.useState(0)
  const [running, setRunning] = React.useState(false)
  const ref = React.useRef(null)

  const handleClick = () => {
    if (running === false) {
      ref = window.setInterval(() => {
        setSeconds(s => s + 1) 
      }, 1000)
      setRunning(true)
    } else {
      window.clearInterval(ref)
      setRunning(false)
    }
  }

  return (
    <main>
      <h1>{formatTime(seconds)}</h1>
      <button
        style={{background: running === true ? 'var(--red)' : 'var(--green)'}}
        onClick={handleClick}>
          {running === true ? 'Stop' : 'Start'}
      </button>
    </main>
  )
}
```

---

- [ ] Nothing

- [ ] We can't pass `null` as the initial value to `useRef`

- [ ] We should `useState` instead of `useRef` to keep track of the interval ID

- [x] We're mutating `ref` instead of `ref.current`

---

This is an easy one to forget. Remember, `ref` comes with a `current` property where you preserve your value – not on the `ref` itself.

```jsx
const handleClick = () => {
  if (running === false) {
    ref.current = window.setInterval(() => {
      setSeconds(s => s + 1) 
    }, 1000)
    setRunning(true)
  } else {
    window.clearInterval(ref.current)
    setRunning(false)
  }
}
```

# What will `bar` be?

```jsx
import * as React from "react"

function Foo() {
  const bar = React.useRef()

  return <button ref={bar}>Submit</button>
}
```

---

- [ ] `undefined`

- [ ] An empty object

- [ ] A reference to the `button` DOM node

- [x] An object with a `current` property which references the `button` DOM node

In this challenge you're given a ref and a simple `input` element. Your job is to autofocus the input when the component first renders.

#### Tasks

1. Autofocus the input when the component renders

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="autofocus-solution-r6k5iy"
  previewHeight="300px"
/>

Autofocus

In this challenge, you'll give the user the ability to play and pause the video. To do so, you'll need to invoke the `play` or `pause` methods on the video element itself. You'll also want to update the UI to reflect the current state of the video.

#### Tasks

1. Toggle the play state when the button is clicked
2. Play and pause the video when the button is clicked

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="video-player-solution-hi4pn4"
  previewHeight="550px"
/>


Video Player

In this challenge you're tasked with completing an app that collects new notes from the user and displays them in a list. Whenever a new note is added, you'll need to scroll it into view.

#### Tasks

1. Add a new note when the user submits the form
2. Scroll the new note into view
3. Clear the input field when the user submits a valid note
4. Prevent empty notes from being added

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="field-notes-solution-kfrjft"
  previewHeight="500px"
/>


Field Notes

In this challenge you'll be adding a modal experience to the app. The user needs to be able to open the modal and then close it either by clicking the close icon in the modal itself, or by clicking anywhere *outside* of the modal.

You'll need both component state and a reference to the modal to make it work properly. You'll also want to reference the [`pointerdown`](https://developer.mozilla.org/en-US/docs/Web/API/Element/pointerdown_event) event if you're not familiar with it.

#### Tasks

1. Don't render the modal by default
2. Clicking the 'Open Modal' button should open the modal
3. Don't close the modal when the dialog is clicked
4. Close modal by clicking close icon
5. Close the modal when the user clicks outside of the modal

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="click-outside-solution-u0dxiv"
  previewHeight="300px"
/>

Click Outside

In this challenge you'll need to add functionality to the app so that the user can type into the textarea and it will expand to fit the content as they type.

#### Tasks

1. Update the value for the textarea when typing
2. Set the textarea's height based on its scroll height

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="expanding-textarea-solution-cjlnpn"
  previewHeight="300px"
/>


Expanding Textarea

The concept is simple, animate the center of the box to the coordinates that the user clicks.

To do this, you'll need to update the `position` array to include the new `x` and `y` positions of where the box should `transform` to.

#### Tasks

1. Animate the box to the coordinates that the user clicks

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="follow-the-leader-solution-5j2zjy"
  previewHeight="300px"
/>

Follow the Leader

Teleportation with Context

# When would you use Context?

---

- [ ] When you want to pass data to a component

- [x] When you need to bypass props and pass data anywhere in your component tree

- [ ] When you need to declaratively update the state in your application

- [ ] When you want to avoid duplication and reuse component logic

# Context is a more robust alternative to useState for managing state in React

---

- [ ] true

- [x] false

---

Context has nothing to do with managing state. All it does is give you the ability to teleport data anywhere in your component tree, without needing to pass props. 

# What would be good use cases for using Context?

---

- [x] When you're a library that needs to get information to any component that needs it

- [x] When you want to add theming to your app and that data needs to be able to be passed anywhere

- [ ] When you want to avoid passing props to a nested component because it's annoying

- [x] When your app is international and you need to pass locale data anywhere in the component tree

---

Don't overuse context. Trust me on this one.

# How do you create a Context?

---

- [ ]

```js
React.useTeleporter()
```

- [ ]

```js
React.createTeleporter()
```

- [x]

```js
React.createContext()
```

- [ ]

```js
React.useContext()
```

---

This is usually done in its own module, then you can import the context anywhere you need to use it.

# `context.Provider` accepts a `value` prop which is the data that you want to teleport to any component in `Provider`'s subtree.

---

- [x] true

- [ ] false

---

```js
<context.Provider value={data}>
  <ChildrenThatCanAccessData />
</context.Provider>
```

# If there's no `Provider` component above where you use `useContext` in the component tree, what will be the value returned from `useContext`?

---

- [ ] `undefined`

- [ ] React will throw an error

- [x] Whatever was passed in as the first argument when the context was created

- [ ] Whatever was set as the initial state of the component

---

If there's no `Provider` above where you use `useContext` in the component tree, the value returned from `useContext` will default to whatever was passed in as the first argument when the context was created.

```js
React.createContext("defaultValue")
```

# Given the following code snippet, what will be displayed when the `ChildComponent` is rendered?

```jsx
import * as React from "react"
const themeContext = React.createContext("light")

function ParentComponent() {
  return (
    <themeContext.Provider value="dark">
      <ChildComponent />
    </themeContext.Provider>
  )
}

function ChildComponent() {
  const theme = React.useContext(themeContext)
  return <div>{theme}</div>
}
```

---

- [ ] light

- [x] dark

- [ ] React will throw a ReferenceError

---

The `theme` in the `ChildComponent` will be `dark` because the closest `themeContext.Provider` above it in the component tree has a `value` of `dark`.

# One more time for those in the back, you should use Context sparingly?

---

- [x] true

- [] false

---

You've been warned 🫡.

(Quiz) Teleportation with Context

In this challenge our goal is to make the user's authentication state (as well as a way to update that state) available to anywhere in our component tree that needs it.

You're given an `authContext` with the expected shape of the user's auth state – `isAuthenticated: boolean`, `login: function`, `logout: function`. 

Your challenge is to finish the `AuthProvider` component – making `isAuthenticated`, `login`, and `logout` available anywhere in the component tree – and then to use those values in any component that needs them.

#### Tasks

1. Render a login form when the user is not authenticated
2. Display the Dashboard component after the user logs in
3. Display the login screen if the user logs out

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="auth-solution-rg705p"
  previewHeight="550px"
/>

Auth

In this challenge your goal is to make translation state (as well as a way to update that state) available anywhere in the component tree.

You're given a `languageContext` with the expected shape of the translation data – `language: string`, `changeLanguage: function`, and `translation: function`.

Your challenge is to finish the `LanguageProvider` component – making `language`, `changeLanguage`, and `translation` available anywhere in the component tree – and then to use those values in any component that needs them.

#### Tasks

1. Update the language based on the user's selection
2. Apply the correct translation when the language is changed

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="translations-solution-394965"
  previewHeight="300px"
/>

Translations

Given the completed JSX, finish the app so that the correct tab content is shown when a tab is clicked.

This challenge is deliberately vague. You'll need to carefully examine the final app as well as each component and what props it receives to figure out how to complete the challenge.

Once finished, you should have a working tabs implementation that is hyper flexible and not coupled at all to the current layout of the app.

#### Tasks

1. Show the correct tab content when a tab is clicked

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="tabs-solution-vmx9nk"
  previewHeight="300px"
/>

Tabs

In this challenge you're given a news feed with different videos. To improve the UX of your feed, the challenge is to make sure only one video can play at a time.

Specifically you'll probably want to tackle the following steps.

1. Finish the `NewsFeed` component by rendering a `VideoItem` component for every `video` in the `videos` array.

2. Finish the `VideoPlaybackProvider` component so that `playingVideoId` and `setPlayingVideoId` are available throughout the component tree.

3. Finish `VideoItem` so that the user can play and pause a video, but that when they do, any other video that is currently playing is paused.

In my opinion this is the hardest challenge we've had throughout the course so far, so keep that in mind as you wrestle with imposter syndrome and self-doubt 🫶. 

#### Tasks

1. Allow only one video to play at a time

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="news-feed-solution-kvf3de"
  previewHeight="800px"
/>

News Feed

Escaping React

Complex State with useReducer

# The Reducer Pattern is  functional programming pattern that takes a collection as input and returns a single value as output

---

- [x] true 

- [ ] false

# How is `.reduce` different from `.forEach`?

---

- [ ] `.forEach` is a pure function, `.reduce` is impure

- [x] `.reduce` is a pure function, `.forEach` is impure

- [x] `.reduce` can keep track of state internally

- [ ] `.forEach` can keep track of state internally

# What does the second element in the array that `useReducer` returns do?

---

- [ ] There is no second element

- [x] Invokes the reducer function passing whatever was passed to it as the second argument

- [ ] It's the state value

- [ ] Accumulates the state value

---

```js
const [state, dispatch] = useReducer(reducer, initialState);
```

# `useState` and `useReducer` both allow you to \_.

---

- [ ] Add side effects to function components

- [x] Trigger re-renders to the component

- [x] Add state to function components

- [x] Persist values across re-renders

# What are the benefits of useReducer over useState?

---

- [x] Declarative state updates

- [x] Decouple how the state is updated from the action that triggered it

- [x] Easier to update one piece of state based on another piece of state

- [x] Minimize the dependencies in the `useEffect` array

# If different pieces of state update independently from one another, use \_.

---

- [x] `useState`

- [ ] `useReducer`

# If your state tends to be updated together or if updating one piece of state is based on another piece of state, use \_.

---

- [ ] `useState`

- [x] `useReducer`


Complex State with useReducer Quiz

Given the solution code to the previous "Multistep Form" challenge you encountered earlier in the course, your job is to refactor the app to use `useReducer` to manage state instead of `useState`.

#### Tasks

1. Enable a user to transition to the next step
2. Enable a user to return to the previous Step
3. Keep track of the step and form state correctly
4. Reset the form when the user submits it
5. Use the useReducer hook to manage the component's state

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="multistep-form-reducer-solution-92y61e"
  previewHeight="500px"
/>

Multistep Form with useReducer

Given the completed `TaskManager` component, your challenge is to finish implementing the `reducer` function so that the user can `add`, `update`, and `delete` tasks.

#### Tasks

1. The user should be able to add a new task
2. The user should be able to update the status of a task
3. The user should be able to delete a task

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="task-manager-solution-ib5gv1"
  previewHeight="500px"
/>


Task Manager

Given the final `ShoppingCart` component (including all the JSX and event handlers), your job is to finish implementing both the `reducer` function as well as the `calculateTotal` function. 

`calculateTotal` takes in the `cart` and should return a single numeric value representing the total cost of all the items in the cart.

For the `reducer`, look at the component to figure out which action types are being dispatched as well as the shape of the action objects.

#### Tasks

1. Render the appropriate UI if there are no items in the cart
2. Give the user the ability to add items to the shopping cart
3. Give the user the ability to remove items from the shopping cart
4. Appropriately update the quantity of items in the shopping cart
5. Appropriately calculate the total cost of all items in the shopping cart

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="add-to-cart-solution-ezv0f2"
  previewHeight="600px"
/>

Add To Cart

The goal of this challenge is, using `useReducer`, add `increment`, `decrement`, `undo`, and `redo` functionality to your application. Unlike the other challenges, you'll need to wire up `useReducer`, the event handlers, and the `reducer` function yourself – you won't need to touch the JSX though.

#### Tasks

1. Clicking increment should increment the counter
2. Clicking decrement should decrement the counter
3. Clicking undo and redo should undo or redo the previous action

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="undo-redo-solution-fnfg4f"
  previewHeight="200px"
/>

Undo Redo

Referential Equality and Why It Matters

# Select all the primitive values

---

- [ ] `[]`

- [x] `2`

- [x] `null`

- [x] `"Hello"`

- [x] `true`

- [x] `undefined`

- [ ] `{}`

- [ ] `const fn = () => ({})`

--- 

If the value is a `number`, `string`, `boolean`, `undefined`, `null`, or `symbol`, it's a primitive value. If it's anything else, it's a reference value.

# When you look at the in-memory value of a reference type, you'd see \_.

---

- [ ] The literal value

- [x] A memory address

---

If you looked at the in-memory value of a primitive, you'd see the actual value itself. If you looked at the in-memory value of a reference type, you'd see a reference to a spot in memory. Or more specifically, you'd see a memory address which pointed to a spot in memory where the value was stored.

# What gets logged?

```js
const playerOne = {}
const playerTwo = playerOne

console.log(playerOne === playerTwo)
```

---

- [x] `true`

- [ ] `false`

---

`playerOne === playerTwo` evaluates to `true` since both `playerOne` and `playerTwo` point to the same spot in memory. When comparing reference values, the identity operator compares the memory address of the value, not the value itself.

# What gets logged?

```js
console.log([] === [])
```

---

- [ ] `true`

- [x] `false`

---

`[] === []` evaluates to `false` since two different arrays are being compared. When comparing reference values, the identity operator compares the memory address of the value, not the value itself.

# What gets logged?

```js
const add = (a, b) => a + b
const multiple = (x, y) => x * y

console.log(add(5, 1) === multiple(3, 2))
```

---

- [x] `true`

- [ ] `false`

---

`add(5, 1) === multiple(3, 2)` evaluates to `true` since both return a primitive value and that primitive value is the same, `6`. When comparing primitive values, the identity operator compares the value itself.

# What is the purpose of `React.memo`?

---

- [ ] To cache a function between renders

- [ ] To cache the result of a calculation between renders

- [x] To opt out of React's default rendering behavior

- [ ] To preserve a value between renders

---

If you do have an expensive component and you want that component to opt out of this default behavior by only re-rendering when its `props` change, you can use React's `React.memo` higher-order component.

# Assuming `Graph` returns a component wrapped in `React.memo`, what's wrong with this element?

```jsx
<Graph title="Q1-203" options={{
  type: "line",
  theme: "dark",
  animate: true
}} />
```

---

- [ ] Nothing

- [ ] `title` needs to be inside the `options` object

- [x] `React.memo` is worthless since we're passing a new options object to `Graph` on every render

- [x] We need to memoize the `options` object or make it a non-reactive value

---

In this case, because all the properties on `options` are static, we can move it out of the component entirely so it won't get re-created on every render.

# What is the purpose of `React.useMemo`?

---

- [ ] To cache a function between renders

- [x] To cache the result of a calculation between renders

- [ ] To opt out of React's default rendering behavior

- [ ] To preserve a value between renders

---

# The primary purpose of `React.useMemo` is to increase the performance of a React app

---

- [ ] true

- [x] false

---

Increasing the performance of a React application is a potential byproduct of `React.useMemo`. The primary purpose is to cache the result of a calculation between renders.

# How can we improve this code?

```js
const handleAdd = React.useMemo(() => {
  return (item) => {
    setItems((items) => [...items, item])
  }
}, [])
```

---

- [ ] We can't, it's fine

- [ ] We should use `React.memo` instead of `React.useMemo`

- [x] We should use `useCallback` instead of `useMemo`

- [ ] We need to include `item` in the dependency array

---

Whenever you need to memoize a function, instead of returning a function from `useMemo`, you can use React's `useCallback` hook to make it a little easier.

```js
const handleAdd = React.useCallback((item) => {
  return setItems(() => [...items, item])
}, [])
```

Complete the app so that the user can change their locale as well as iterate through every prime number. Take special care to only re-calculate the prime number when the user clicks `NEXT PRIME`.

#### Tasks

1. Increment the prime number count when the button is clicked
2. Change the language when the select option is changed
3. Memoize `nthprime` so that it's only re-calculated when `count` changes

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="localized-primes-solution-0wycwm"
  previewHeight="200px"
/>

Localized Primes

Given an application that already has the completed JSX and event handlers for deciding *how* you should filter and sort the data (`searchTerm`, `sortColumn`, and `sortOrder`), your job is to fetch the data (using the `fetchData` function), and then, in the most performant way possible, using `searchTerm`, `sortColumn`, and `sortOrder`, update the `filteredData` and `sortedData` variables.

`filteredData` should be a memoized array of data that has been filtered based on the `searchTerm`.

`sortedData` should be a memoized array of `filteredData` that has been sorted based on the `sortColumn` and `sortOrder`.

#### Tasks

1. The user can search Pokémon
2. The user can sort Pokémon
3. The Pokémon data is correctly memoized

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="data-table-solution-pzxf9k"
  previewHeight="600px"
/>

Data Table

In this challenge you're given two components, `ParentComponent` and `ChildComponent`. The goal is to make it so whenever the button in `ChildComponent` is clicked, you increment `count` in the `ParentComponent`. The caveat is that `ChildComponent` should only ever render once, when the app first loads.

#### Tasks

1. Increment count when the button is clicked
2. `ChildComponent` should only render once, when the app first loads

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="optimizing-renders-solution-stigpr"
  previewHeight="200px"
/>

Optimizing Renders

Managing Advanced Effects

# When does `useEffect` run? 

---

- [x] Asynchronously after render

- [ ] Synchronously before React shows anything to the user

- [ ] Asynchronously after render, but before React shows anything to the user

- [ ] Asynchronously after render, but before React updates the DOM

# When does `useLayoutEffect` run?

---

- [ ] Asynchronously after render, but before React shows anything to the user

- [x] Synchronously after render, but before React shows anything to the user

- [ ] Asynchronously after render, but before React updates the DOM

- [ ] Synchronously after render, after React updates the DOM

# React guarantees the code inside `useLayoutEffect` and any state updates scheduled inside it will be processed before the browser repaints the screen.

---

- [x] true

- [ ] false

# The API for `useLayoutEffect` is identical to `useEffect` except `useLayoutEffect` doesn't have a dependency array

---

- [ ] true

- [x] false

---

The APIs are identical.

# The purpose of `useSyncExternalStore` is to \_.

---

- [x] Subscribe a component to external state without having to duplicate it as React state

- [x] Avoid using `useEffect` with `useState`

- [ ] Avoid using `useLayoutEffect` with `useState`

- [ ] Expose a DOM node to parent component with a ref.

---

In scenarios where a piece of non-React state is already being managed by some outside system –  whether that's the browser, another library, or even your own custom data store – you can use React's built-in useSyncExternalStore hook to subscribe a component to that state without needing to redundantly duplicate it as React state in your component.

# What's wrong with this code?

```jsx
const subscribe = (cb) => {
  window.addEventListener("resize", cb);

  return () => {
    window.removeEventListener("resize", cb);
  };
}

const getSnapshot = () => {
  return {
    width: window.innerWidth,
    height: window.innerHeight,
  }
}

function useWindowSize() {
  return useSyncExternalStore(subscribe, getSnapshot)
}
```

---

- [ ] Nothing

- [ ] `getSnapshot` is the first argument, `subscribe` is the second

- [x] It'll cause an infinite loop

- [ ] We're never removing the event addEventListener

---

If the value you return from `getSnapshot` is a reference value, like the object literal we're returning, and that reference value isn't memoized, then you'll throw React into an infinite loop scenario since `useSyncExternalStore` will re-render every time the reference value changes, and every re-render will call `getSnapshot` again. 

Using the [ResizeObserver API](https://developer.mozilla.org/en-US/docs/Web/API/ResizeObserver), synchronize the width of the ruler (the `article` element) with your component's `width` state.

#### Tasks

1. Update the `width` state when the ruler is resized
2. Clean up the `ResizeObserver` when the component is removed from the DOM

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="react-ruler-solution-qbo8xo"
  previewHeight="300px"
/>

React Ruler

You're given an app that... kind of works. The only problem is when you hover over any of the yellow underlined text, the tooltip renders in the wrong position. Your job is to fix the app so that the tooltip renders correctly – either above the text if there's room, or below it if there's not.

To do this, you'll want to utilize the browser's [`getBoundingClientRect`](https://developer.mozilla.org/en-US/docs/Web/API/Element/getBoundingClientRect) API to get position information about specific elements. 

You won't need to touch any code other than the `Tip` component.

#### Tasks

1. Position the tooltip above the hovered text if there’s enough room
2. If there's not enough room above it, and if there's more room below it than above it, position the tooltip below the hovered text
3. If there's not enough room above it, and there's less room below it, position the tooltip above the hovered text 

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="flexible-tooltip-solution-d3ckpw"
  previewHeight="300px"
/>

Flexible Tooltip

You're given a functioning app that utilizes `useEffect` with some React state to synchronize the browser's dimension with the component. This works, but it's not ideal. Instead, refactor the app to utilize React's `useSyncExternalStore` hook. 

#### Tasks

1. Refactor the app to keep the same functionality but use the `useSyncExternalStore` hook
2. Show the correct UI for larger browser dimensions
3. Show the correct UI for mobile browser dimensions
4. Subscribe and unsubscribe to the browser's dimensions using the MatchMedia API

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="match-media-solution-qtz3rw"
  previewHeight="300px"
/>

Match Media

<Aside emoji="⚠️" title="Alpha lol">

The hook we discuss in this lesson, `useEffectEvent`, is currently in alpha and isn't yet included in stable releases of React.

That said, it's been <Popover content={<p>lol</p>}>stable in alpha</Popover> for a while, it's incredibly helpful, and we rely heavily on it throughout the remainder of this course.

</Aside>

Because "Don't Repeat Yourself" (DRY) is a principle of software development and __not__ one of education, let's recap everything we know about React's `useEffect` hook one last time.

The whole purpose of `useEffect` is to encapsulate a side effect that synchronizes your component with some outside system. It works by removing the side effect from React's rendering flow and delaying its execution until it's safe to do so, __after__ the component has rendered.

<UseEffect />

`useEffect` will invoke its effect once after the initial render of the component and then again after every render in which a value in its dependency array has changed since the previous render.

Here's a simple example that is updating our analytics whenever a user visits a new page.

```jsx
React.useEffect(() => {
  pageview(url)
}, [url])
```

In almost every scenario, this is what you want. You're synchronizing your component with some outside system and as such, you want to re-synchronize whenever a dependency changes. In our case, we want to update our analytics whenever a user visits a new page.

However, what do we do in a scenario like this?

```jsx
React.useEffect(() => {
  pageview(url, state)
}, [url])
```

All we're wanting to do is pass along some `state` information for our analytics. However, because `state` is a <Popover content={<p>Meaning it can change between renders</p>}>reactive value</Popover>, we need to include it in the dependency array – if we don't, React will complain.

```jsx
React.useEffect(() => {
  pageview(url, state)
}, [url, state])
```

That gets React off our back but it's obviously not ideal since now anytime `state` changes, our effect will re-run and mess up our analytics.

What we really need in this moment is a way to tell React that we want to use a reactive value inside of `useEffect`, but that reactive value has _nothing_ to do with synchronizing the component, and therefore, shouldn't need to be included in the dependency array.

This is (kind of) what React's `useEffectEvent` hook allows us to do. However, instead of using it to tell React which reactive but non-synchronizing values we want to use inside of `useEffect`, we can use it as a way to abstract those values into their own event handler which we can then use inside of `useEffect` - without needing to include it in the dependency array.

```jsx
...

const onPageView = React.useEffectEvent((url) => {
  pageview(url, state)
})

React.useEffect(() => {
  onPageView(url)
}, [url])

...
```

Similar to how event handlers allow us to abstract our side effect logic out of React's rendering flow, `useEffectEvent` allows us to abstract our reactive but non-synchronizing values out of `useEffect`.

The biggest thing to notice is that `url` is still included in the dependency array __and__ we're passing it as an argument to `onPageView`. This is good practice as it makes it explicit which values are synchronizing (`url`) and which aren't (`state`).

Now that you've got the basic idea, let's look at a real example.

Say you were building a Counter app that counted up from 0, but allowed the user to specify the duration between increments – something like this.

<CodePreview
  hideEditor
  template="react"
  hideStrictModeToggle
  previewHeight="290px"
>

```jsx App.jsx active
import * as React from "react"
import Slider from "./Slider"

export default function App() {
  const [count, setCount] = React.useState(0)
  const [delay, setDelay] = React.useState(100)

  const handleDelayChange = (d) => setDelay(d)

  React.useEffect(() => {
    const id = window.setInterval(() => {
      setCount((c) => c + 1)
    }, delay)

    return () => window.clearInterval(id)
  }, [delay])

  return (
    <main>
      <h1>{count}</h1>
      <Slider
        min={100}
        max={2000}
        step={100}
        onChange={handleDelayChange}
        label="ms delay"
      />
    </main>
  )
}
```

```jsx Slider.jsx
import * as React from "react"

export default function Slider({ min, max, step, onChange, label }) {
  const [value, setValue] = React.useState(min)

  return (
    <div className="range">
      <div>{label}</div>
      <input
        type="range"
        min={min}
        max={max}
        value={value}
        step={step}
        onChange={(e) => {
          const value = Number(e.target.value)
          onChange(value)
          setValue(value)
        }}
      />
      <div>{value.toLocaleString()}</div>
    </div>
  )
}
```

```css styles.css hidden
body .container {
  padding: 20px;
}

main {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
}

body h1 {
  font-size: 110px;
  margin: 0;
}

body button {
  font-size: 25px;
  width: 50px;
  height: 50px;
  margin: 0 7px;
}

.range {
  margin-top: 15px;
  display: flex;
  align-items: center;
  width: 400px;
  justify-content: center;
}

.range input {
  -webkit-appearance: none;
  width: 220px;
  height: 2px;
  border-radius: 3px;
  background-color: var(--charcoal);
  outline: none;
  padding-left: 0;
  padding-right: 0;
  padding: 5px 0;
  margin: 0 10px;
}

.range input::-webkit-slider-thumb {
  -webkit-appearance: none;
  width: 20px;
  height: 20px;
  border-radius: 50%;
  background-color: var(--yellow);
}

.range div:first-child {
  width: 130px;
  text-align: right;
}

.range div:last-child {
  width: 75px;
  font-weight: 900;
  text-align: left;
}

.range div {
  border-radius: 3px;
  text-align: center;
  margin: 0;
  font-size: 18px;
  color: var(--beige);
  padding: 1px;
}
```

</CodePreview>

To accomplish this we'll have two piece of state, `count` and `delay`. Then, inside of `useEffect`, we'll use `window.setInterval` to increment `count` every `delay` milliseconds.

<CodePreview
  template="react"
  hideStrictModeToggle
  previewHeight="290px"
  lineLimit={32}
>

```jsx App.jsx active
import * as React from "react"
import Slider from "./Slider"

export default function App() {
  const [count, setCount] = React.useState(0)
  const [delay, setDelay] = React.useState(100)

  const handleDelayChange = (d) => setDelay(d)

  React.useEffect(() => {
    const id = window.setInterval(() => {
      setCount((c) => c + 1)
    }, delay)

    return () => window.clearInterval(id)
  }, [delay])

  return (
    <main>
      <h1>{count}</h1>
      <Slider
        min={100}
        max={2000}
        step={100}
        onChange={handleDelayChange}
        label="ms delay"
      />
    </main>
  )
}
```

```jsx Slider.jsx
import * as React from "react";

export default function Slider({ min, max, step, onChange, label }) {
  const [value, setValue] = React.useState(min);

  return (
    <div className="range">
      <div>{label}</div>
      <input
        type="range"
        min={min}
        max={max}
        value={value}
        step={step}
        onChange={(e) => {
          const value = Number(e.target.value);
          onChange(value);
          setValue(value);
        }}
      />
      <div>{value.toLocaleString()}</div>
    </div>
  );
}
```

```css styles.css hidden
body .container {
  padding: 20px;
}

main {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
}

body h1 {
  font-size: 110px;
  margin: 0;
}

body button {
  font-size: 25px;
  width: 50px;
  height: 50px;
  margin: 0 7px;
}

.range {
  margin-top: 15px;
  display: flex;
  align-items: center;
  width: 400px;
  justify-content: center;
}

.range input {
  -webkit-appearance: none;
  width: 220px;
  height: 2px;
  border-radius: 3px;
  background-color: var(--charcoal);
  outline: none;
  padding-left: 0;
  padding-right: 0;
  padding: 5px 0;
  margin: 0 10px;
}

.range input::-webkit-slider-thumb {
  -webkit-appearance: none;
  width: 20px;
  height: 20px;
  border-radius: 50%;
  background-color: var(--yellow);
}

.range div:first-child {
  width: 130px;
  text-align: right;
}

.range div:last-child {
  width: 75px;
  font-weight: 900;
  text-align: left;
}

.range div {
  border-radius: 3px;
  text-align: center;
  margin: 0;
  font-size: 18px;
  color: var(--beige);
  padding: 1px;
}
```

</CodePreview>

Simple enough. Every time `delay` changes, React will remove the previous interval and create a new one.

Now, how would we go about implementing something like this, where the user can decide by how much we increment `count`?

<CodePreview
  template="reactExperimental"
  hideStrictModeToggle
  previewHeight="350px"
  hideEditor
>

```jsx App.jsx active
import * as React from "react";
import Slider from "./Slider";

React.useEffectEvent = React.experimental_useEffectEvent;

export default function App() {
  const [count, setCount] = React.useState(0)
  const [delay, setDelay] = React.useState(100)
  const [step, setStep] = React.useState(1)

  const handleDelayChange = (d) => setDelay(d)
  const handleStepChange = (s) => setStep(s)

  const onInterval = React.useEffectEvent(() => {
    setCount(count + step)
  })

  React.useEffect(() => {
    const id = window.setInterval(onInterval, delay)

    return () => window.clearInterval(id)
  }, [delay])

  return (
    <main>
      <h1>{count}</h1>
      <Slider
        min={100}
        max={2000}
        step={100}
        onChange={handleDelayChange}
        label="ms delay"
      />
      <Slider
        min={1}
        max={10}
        step={1}
        onChange={handleStepChange}
        label="increment by"
      />
    </main>
  );
}
```

```jsx Slider.jsx
import * as React from "react"

export default function Slider({ min, max, step, onChange, label }) {
  const [value, setValue] = React.useState(min)

  return (
    <div className="range">
      <div>{label}</div>
      <input
        type="range"
        min={min}
        max={max}
        value={value}
        step={step}
        onChange={(e) => {
          const value = Number(e.target.value)
          onChange(value)
          setValue(value)
        }}
      />
      <div>{value.toLocaleString()}</div>
    </div>
  )
}
```

```css styles.css hidden
body .container {
  padding: 20px;
}

main {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
}

body h1 {
  font-size: 110px;
  margin: 0;
}

body button {
  font-size: 25px;
  width: 50px;
  height: 50px;
  margin: 0 7px;
}

.range {
  margin-top: 25px;
  display: flex;
  align-items: center;
  width: 400px;
  justify-content: center;
}

.range input {
  -webkit-appearance: none;
  width: 220px;
  height: 2px;
  border-radius: 3px;
  background-color: var(--charcoal);
  outline: none;
  padding-left: 0;
  padding-right: 0;
  padding: 5px 0;
  margin: 0 10px;
}

.range input::-webkit-slider-thumb {
  -webkit-appearance: none;
  width: 20px;
  height: 20px;
  border-radius: 50%;
  background-color: var(--yellow);
}

.range div:first-child {
  width: 130px;
  text-align: right;
}

.range div:last-child {
  width: 75px;
  font-weight: 900;
  text-align: left;
}

.range div {
  border-radius: 3px;
  text-align: center;
  margin: 0;
  font-size: 18px;
  color: var(--beige);
  padding: 1px;
}
```

</CodePreview>

First we'll add another piece of state for the `step`, an event handler to update that state, and a `Slider` hooked up to that event handler.

```jsx {4,7,27-33}
export default function App() {
  const [count, setCount] = React.useState(0)
  const [delay, setDelay] = React.useState(100)
  const [step, setStep] = React.useState(1)

  const handleDelayChange = (d) => setDelay(d)
  const handleStepChange = (s) => setStep(s)

  React.useEffect(() => {
    const id = window.setInterval(() => {
      setCount((c) => c + 1)
    }, delay)

    return () => window.clearInterval(id)
  }, [delay])

  return (
    <main>
      <h1>{count}</h1>
      <Slider
        min={100}
        max={2000}
        step={100}
        onChange={handleDelayChange}
        label="ms delay"
      />
      <Slider
        min={1}
        max={10}
        step={1}
        onChange={handleStepChange}
        label="increment by"
      />
    </main>
  )
}
```

Now, instead of incrementing `count` by `1` every `delay` ms, we want to increment `count` by `step` every `delay` ms.

That seems easy enough, but it puts us in a weird spot with our `useEffect`'s dependency array.

We either leave it out and have React yell at us.

```jsx
React.useEffect(() => {
  const id = window.setInterval(() => {
    setCount((c) => c + step)
  }, delay)

  return () => window.clearInterval(id)
}, [delay])
```

Or worse, we include it and unnecessarily remove and re-add our interval whenever `delay` OR `step` changes.

```jsx
React.useEffect(() => {
  const id = window.setInterval(() => {
    setCount((c) => c + step)
  }, delay)

  return () => window.clearInterval(id)
}, [delay, step])
```

This is a similar problem to what we saw earlier. We need to access the reactive `step` value from inside of `useEffect`, but we don't want to include it in the dependency array because it has nothing to do with setting and removing our interval.

This is the perfect use case for `useEffectEvent`. All we have to do is abstract our reactive but non-synchronizing logic into `useEffectEvent`, then we can use that event handler inside of `useEffect` without needing to include it as a dependency.

<CodePreview
  template="reactExperimental"
  hideStrictModeToggle
  previewHeight="350px"
  lineLimit={30}
>

```jsx App.jsx active mark=14:16,19[34:44]
import * as React from "react"
import Slider from "./Slider"

React.useEffectEvent = React.experimental_useEffectEvent;

export default function App() {
  const [count, setCount] = React.useState(0)
  const [delay, setDelay] = React.useState(100)
  const [step, setStep] = React.useState(1)

  const handleDelayChange = (d) => setDelay(d)
  const handleStepChange = (s) => setStep(s)

  const onInterval = React.useEffectEvent(() => {
    setCount(count + step)
  })

  React.useEffect(() => {
    const id = window.setInterval(onInterval, delay)

    return () => window.clearInterval(id)
  }, [delay])

  return (
    <main>
      <h1>{count}</h1>
      <Slider
        min={100}
        max={2000}
        step={100}
        onChange={handleDelayChange}
        label="ms delay"
      />
      <Slider
        min={1}
        max={10}
        step={1}
        onChange={handleStepChange}
        label="increment by"
      />
    </main>
  )
}
```

```jsx Slider.jsx
import * as React from "react"

export default function Slider({ min, max, step, onChange, label }) {
  const [value, setValue] = React.useState(min)

  return (
    <div className="range">
      <div>{label}</div>
      <input
        type="range"
        min={min}
        max={max}
        value={value}
        step={step}
        onChange={(e) => {
          const value = Number(e.target.value)
          onChange(value)
          setValue(value)
        }}
      />
      <div>{value.toLocaleString()}</div>
    </div>
  )
}

```

```css styles.css hidden
body .container {
  padding: 20px;
}

main {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
}

body h1 {
  font-size: 110px;
  margin: 0;
}

body button {
  font-size: 25px;
  width: 50px;
  height: 50px;
  margin: 0 7px;
}

.range {
  margin-top: 25px;
  display: flex;
  align-items: center;
  width: 400px;
  justify-content: center;
}

.range input {
  -webkit-appearance: none;
  width: 220px;
  height: 2px;
  border-radius: 3px;
  background-color: var(--charcoal);
  outline: none;
  padding-left: 0;
  padding-right: 0;
  padding: 5px 0;
  margin: 0 10px;
}

.range input::-webkit-slider-thumb {
  -webkit-appearance: none;
  width: 20px;
  height: 20px;
  border-radius: 50%;
  background-color: var(--yellow);
}

.range div:first-child {
  width: 130px;
  text-align: right;
}

.range div:last-child {
  width: 75px;
  font-weight: 900;
  text-align: left;
}

.range div {
  border-radius: 3px;
  text-align: center;
  margin: 0;
  font-size: 18px;
  color: var(--beige);
  padding: 1px;
}

```

</CodePreview>

To recap, whenever you need to access a reactive but non-synchronizing value inside of `useEffect`, look into abstracting that logic into `useEffectEvent`. We'll see plenty of use cases for this in the next section.

<Aside emoji="🧐" title="What about useReducer?">

You may remember back to a previous lesson where we used `useReducer` to solve a similar problem. Because `useReducer` allows us to decouple how the state is updated from the action that triggered that update, it allows us to trigger a state change from inside of an effect without needing to worry about including current state properties in the dependency array.

```jsx
const id = window.setInterval(() => {
  dispatch({type: "increment"})
}, state.delay)
```

This works, and it's still valid, but sometimes it's nice to not have to refactor your code to use a different pattern.

</Aside>

Abstracting Reactive Values with useEffectEvent

# What problem does `useEffectEvent` solve?

---

- [ ] Allows you to bypass `useEffect`'s dependency array

- [ ] Allows you to opt out of React's default rendering behavior

- [ ] Allows you to cache the result of a calculation between renders

- [x] Allows you to abstract reactive but non-synchronizing values out of `useEffect`

# What does `useEffectEvent` return?

---

- [x] a function

- [ ] a tuple

- [ ] a promise

- [ ] a boolean

---

```js
const onConnected = React.useEffectEvent(() => {
  toast('Connected!', theme);
})
```

# You need to include the function returned from `useEffectEvent` in your dependency array

---

- [ ] true

- [x] false

---

Nope. That's kind of the whole point.

# What's wrong with this code?

```jsx
...

function User({ id }) {
  const { timeOnSite } = React.useContext(UserContext);

  const onVisit = React.useEffectEvent(() => {
    logProfileVisit(id, timeOnSite)
  })

  React.useEffect(() => {
    onVisit()
  }, [id])

  ...
}
```

---

- [ ] Nothing

- [ ] `onVisit` is not included in the dependency array

- [ ] `onVisit` is called on every render

- [x] We should pass the reactive `id` value as an argument to `onVisit`

---

Don't rely on closures to capture the latest value of a reactive variable. Pass it as an argument instead.

```jsx
...

function User({ id }) {
  const { timeOnSite } = React.useContext(UserContext);

  const onVisit = React.useEffectEvent((id) => {
    logProfileVisit(id, timeOnSite)
  })

  React.useEffect(() => {
    onVisit(id)
  }, [id])

  ...
}
```

Optimizing React

Let's take a step back and do a quick review on what we know about React so far, which, admittedly, is quite a bit.

React is a library for building user interfaces. With React, your View is a function of your application's State – `v = f(s)`. All you have to do is worry about how the state in your application changes, and React handles the rest.

The primary mode of encapsulation for this concept is the component – which encapsulates both the visual representation of a particular piece of UI as well as the state and logic that goes along with it.

<ReactConcerns />

By doing so, the same intuition you have about creating and composing together functions can directly apply to creating and composing components. However, instead of composing functions together to get some value, you can compose components together to get some UI.

<ReactView />

To accomplish this, React needed a way to allow you to describe what the UI for a component would look like from inside the component itself. 

This thinking led to the creation of JSX - a wonderful lovechild of HTML and JavaScript that allows you to write HTML-ish looking syntax directly inside of JavaScript.

What made JSX different was it combined the power and expressiveness of JavaScript with the readability and accessibility of HTML. If you were already comfortable with both JavaScript and HTML (which you probably were, if you were building web apps), then you could get up to speed with JSX in a matter of minutes.

```jsx
function Profile({ user }) {
  return (
    <div className="profile">
      <Avatar username={user.avatar} />
      <Bio text={user.bio} />
      <ul>
        {user.preferences.map((preference) => (
          <li>
            <Setting
              key={preference.id}
              preference={preference}
            />
          </li>
        ))}
      </ul>
    </div>
  );
}
```

At this point, components were a beautiful solution for encapsulating and composing UI. In fact, when you think about composition in React, odds are you think in terms of UI composition. This is natural since it's what React is so good at.

The problem is in the real world, there's more to building an app than just the UI layer. It's not uncommon to need to compose and reuse _non-visual_ logic as well. However, because React couples UI to a component, historically, this was difficult.

This is the problem that hooks were created to solve. Just like a component enabled the composition and reusability of UI, hooks enabled the composition and reusability of non-visual logic.

<Definition header="" description={<ul className="p-0">
  <li className="text-[20px] mb-10 list-none font-mono">
    <div style={{color: "var(--blue)", fontSize: 25, fontWeight: 900}}>useState</div> create a value that is preserved across renders and triggers a re-render when it changes
  </li>
  <li className="text-[20px] mb-10 list-none font-mono">
    <div style={{color: "var(--orange)", fontSize: 25, fontWeight: 900}}>useEffect</div> synchronize a component with some external system
  </li>
  <li className="text-[20px] mb-10 list-none font-mono">
    <div style={{color: "var(--pink)", fontSize: 25, fontWeight: 900}}>useRef</div> create a value that is preserved across renders, but won't trigger a re-render when it changes
  </li>
  <li className="text-[20px] mb-10 list-none font-mono">
    <div style={{color: "var(--green)", fontSize: 25, fontWeight: 900}}>useContext</div> get access to what was passed to a Context's Provider
  </li>
  <li className="text-[20px] mb-10 list-none font-mono">
    <div style={{color: "var(--yellow)", fontSize: 25, fontWeight: 900}}>useReducer</div> create a value that is preserved across renders and triggers a re-render when it changes, using the reducer pattern
  </li>
  <li className="text-[20px] mb-10 list-none font-mono">
    <div style={{color: "var(--purple)", fontSize: 25, fontWeight: 900}}>useMemo</div> cache the result of a calculation between renders
  </li>
  <li className="text-[20px] mb-10 list-none font-mono">
    <div style={{color: "var(--blue)", fontSize: 25, fontWeight: 900}}>useCallback</div> cache a function between renders
  </li>
  <li className="text-[20px] mb-10 list-none font-mono">
    <div style={{color: "var(--orange)", fontSize: 25, fontWeight: 900}}>useLayoutEffect</div> synchronize a component with some external system, *before* the browser paints the screen
  </li>
  <li className="text-[20px] mb-10 list-none font-mono">
    <div style={{color: "var(--pink)", fontSize: 25, fontWeight: 900}}>useSyncExternalStore</div> subscribe to an external store
  </li>
  <li className="text-[20px] mb-10 list-none font-mono">
    <div style={{color: "var(--green)", fontSize: 25, fontWeight: 900}}>useEffectEvent</div> encapsulate a side effect that synchronizes your component with some outside system
  </li>
</ul>} />

With all that said, and with all we've covered so far, there's still one more aspect of React that I would consider fundamental and necessary knowledge. Per usual, let's discover it with an example. 

If you'll remember back to the Advanced Effects lesson, we had an app that displayed the user's current network status. We implemented it like this, using React's `useSyncExternalStore` hook.

<CodePreview 
  template="react"
  strictMode={false} 
  previewHeight="100px"
  lineLimit="30"
>

```jsx App.jsx active
import * as React from "react"

const getSnapshot = () => {
  return navigator.onLine ? "online" : "offline"
}

const subscribe = (callback) => {
  window.addEventListener("online", callback)
  window.addEventListener("offline", callback)

  return () => {
    window.removeEventListener("online", callback)
    window.removeEventListener("offline", callback)
  }
}

export default function App () {
  const networkStatus = React.useSyncExternalStore(
    subscribe, 
    getSnapshot
  )

  return (
    <div>
      <span className={networkStatus} />
      <label>{networkStatus}</label>
    </div>
  )
}
```

```css styles.css hidden
div {
  margin: 0 auto;
  display: flex;
  justify-content: center;
  align-items: center;
}

span {
  width: 18px;
  height: 18px;
  border-radius: 50%;
  background-color: var(--green);
  display: inline-flex;
  animation: pulse 1.75s infinite;

  --color1: rgb(11, 169, 91, 0);
  --color2: rgb(11, 169, 91, 0.25);
  --color3: rgb(11, 169, 91, 0.15);
}

span.offline {
  animation: none;
  background-color: var(--red);
  --color1: rgba(252, 186, 40, 0);
  --color2: rgba(252, 186, 40, 0.25);
  --color3: rgba(252, 186, 40, 0.15);
}

label {
  padding: 0;
  margin-left: 11px;
  margin-bottom: 0 !important;
  font-size: 18px !important;
}

@keyframes pulse {
  0% {
    box-shadow: 0px 0px 0px 0px var(--color1), 0px 0px 0px 0px var(--color1);
  }

  50% {
    box-shadow: 0px 0px 0px 5px var(--color2), 0px 0px 0px 10px var(--color3);
  }

  100% {
    box-shadow: 0px 0px 0px 0px var(--color1), 0px 0px 0px 0px var(--color1);
  }
}

```

</CodePreview>


Now here's a question I want you to think through. Let's say we wanted to display the user's network status in *another* part of our app. How would you go about doing that?

My guess is your first intuition would be to utilize this One Cool Trick™️.

<Aside emoji="🥲" title="How To Reuse Non-Visual Logic">

<Sparkle>"CMD + C" then "CMD + V"</Sparkle>

</Aside>

Because we've coupled the logic for determining the user's network status to the component that displays it, if we wanted to reuse that logic, we'd be forced to copy and paste it into another component.

```jsx {4-6,8-16,19-22}
import * as React from "react"
import Banner from './Banner'

const getSnapshot = () => {
  return navigator.onLine ? "online" : "offline"
}

const subscribe = (callback) => {
  window.addEventListener("online", callback)
  window.addEventListener("offline", callback)

  return () => {
    window.removeEventListener("online", callback)
    window.removeEventListener("offline", callback)
  }
}

export default function OfflineBanner () {
  const networkStatus = React.useSyncExternalStore(
    subscribe, 
    getSnapshot
  )

  if (networkStatus === "online") {
    return null
  }

  return (
    <Banner emoji="🛜" title="You're currently offline.">
      Please re-connect to the internet before continuing.
    </Banner>
  )
}
```

Isn't the whole purpose of hooks, as mentioned earlier, to enable the composition and reusability of non-visual logic? If that's the case, copy/pasting non-visual logic all over our app doesn't seem like the most elegant solution.

What if, just like React comes with its own set of hooks, we were also able to make our own _custom_ hooks? In that scenario, a custom `useNetworkStatus` hook would be awfully convenient.

```jsx
import * as React from "react"
import Banner from './Banner'
import useNetworkStatus from "./useNetworkStatus"

export default function OfflineBanner () {
  const networkStatus = useNetworkStatus()

  if (networkStatus === "online") {
    return null
  }

  return (
    <Banner emoji="🛜" title="You're currently offline.">
      Please re-connect to the internet before continuing.
    </Banner>
  )
}
```

As you probably guessed by now, not only is this possible, but it's highly encouraged whenever you want to re-use non-visual logic. 

Here's what that custom `useNetworkStatus` hook would look like.

<CodePreview 
  template="react"
  strictMode={false} 
  previewHeight="100px"
  lineLimit="30"
>

```jsx App.jsx
import * as React from "react"
import useNetworkStatus from "./useNetworkStatus"

export default function App () {
  const networkStatus = useNetworkStatus()

  return (
    <div>
      <span className={networkStatus} />
      <label>{networkStatus}</label>
    </div>
  )
}
```

```jsx useNetworkStatus.js active
import * as React from "react"

const getSnapshot = () => {
  return navigator.onLine ? "online" : "offline"
}

const subscribe = (callback) => {
  window.addEventListener("online", callback)
  window.addEventListener("offline", callback)

  return () => {
    window.removeEventListener("online", callback)
    window.removeEventListener("offline", callback)
  }
}

export default function useNetworkStatus () {
  return React.useSyncExternalStore(
    subscribe, 
    getSnapshot
  )
}
```

```css styles.css hidden
div {
  margin: 0 auto;
  display: flex;
  justify-content: center;
  align-items: center;
}

span {
  width: 18px;
  height: 18px;
  border-radius: 50%;
  background-color: var(--green);
  display: inline-flex;
  animation: pulse 1.75s infinite;

  --color1: rgb(11, 169, 91, 0);
  --color2: rgb(11, 169, 91, 0.25);
  --color3: rgb(11, 169, 91, 0.15);
}

span.offline {
  animation: none;
  background-color: var(--red);
  --color1: rgba(252, 186, 40, 0);
  --color2: rgba(252, 186, 40, 0.25);
  --color3: rgba(252, 186, 40, 0.15);
}

label {
  padding: 0;
  margin-left: 11px;
  margin-bottom: 0 !important;
  font-size: 18px !important;
}

@keyframes pulse {
  0% {
    box-shadow: 0px 0px 0px 0px var(--color1), 0px 0px 0px 0px var(--color1);
  }

  50% {
    box-shadow: 0px 0px 0px 5px var(--color2), 0px 0px 0px 10px var(--color3);
  }

  100% {
    box-shadow: 0px 0px 0px 0px var(--color1), 0px 0px 0px 0px var(--color1);
  }
}

```

</CodePreview>

Notice that `useNetworkStatus` is just a function that starts with `use` and it uses another hook (`useSyncExternalStore`) inside of it. That is (literally) the definition of a custom hook.

<Definition header="What is a Custom Hook?" description={<p>A custom hook is a function that starts with <Mono>use</Mono> and calls other hooks inside of it</p>} />

Now, anywhere inside of our app where we need the user's network status, we can use our `networkStatus` hook.

***

One question you may have is *why* exactly does a hook need to start with `use`? That seems overly restrictive.

The reason is so it's clear where the "React-y" features of the components are, whether that's state, effects, or any other hooks. If you see a function call that starts with `use`, you can be sure that it's utilizing other hooks inside of it. On the contrary, if you see a function call that doesn't start with `use`, say `getTheme`, you can be sure that it's just a normal JavaScript function and has nothing to do with React.

The second part of the definition is also important. If the function _doesn't_ call other hooks, whether those hooks are built-in React hooks like `useState` or `useEffect`, or other custom hooks, then it's not a hook – it's just a function – and doesn't need to start with `use`.

Now the only question left is __when__ is it appropriate to create a custom hook? The answer, as with most things in React, is to rely on your intuition. The same intuition you've developed about functions and when to create them can be directly applied to creating hooks. Mostly, you'll know it when you see it.

If that's too abstract, the next section will give you a few (50, to be exact) ideas for when to create them.

Creating Custom Hooks

# Just like a component enabled the composition and reusability of UI, hooks enabled the composition and reusability of \_.

---

- [ ] Stateful logic

- [ ] Side effects

- [ ] Event handlers

- [x] Non-visual logic

# What's wrong with this custom hook

```js
function useInterval(cb, ms) {
  const id = React.useRef(null);
  const onInterval = React.useEffectEvent(cb);

  const handleClearInterval = () => {
    window.clearInterval(id.current);
  };

  React.useEffect(() => {
    id.current = window.setInterval(onInterval, ms);
    return handleClearInterval;
  }, [ms]);

  return handleClearInterval;
}
```

---

- [x] Nothing

- [ ] Custom hooks can't contain other hooks

- [ ] We should use state for our interval ID

- [ ] We need to include `onInterval` to our dependency array

# Why do hooks have to start with `use`?

---

- [ ] So React's compiler can optimize them

- [x] So it's clear what parts of a component are "React-y"

- [ ] React will break if you don't

- [x] It allows Linters to enforce the rules of hooks

# What's wrong with this custom hook?

```js
function useEnvironment () {
  const isDOM =
    typeof window !== 'undefined' &&
    window.document &&
    window.document.documentElement

  return {
    isBrowser: isDOM,
    isServer: !isDOM,
  }
}
```

---

- [ ] Nothing

- [ ] We can't access `window` in custom hooks

- [x] It's not a hook. It should be called `getEnvironment`

- [ ] We need to memoize the object before we return it

---

A hook is only a hook if it consumes other hooks. If not, it's just a function and shouldn't start with `use`.

Custom Hooks

When we started working on [react.gg](https://react.gg), a primary focus of ours was figuring out how to get students comfortable working with "production" level React code, without the burden or context of needing to dive into a fully fledged project.

I'm sure you've experienced it before. In an attempt to make the course "hands-on", the instructor has you clone a *starter* project from Github, `npm install` two dozen packages, and then you spend the next 14 hours watching them glue it together.

This is the *"you don't learn how to ride a bike from reading about it in a book"* approach to developer education. That's fantastic advice, if you're a 4 year old. In reality, professional cyclists *do* learn all about riding, both the physical act and how to most efficiently train, from reading.

I know this seems controversial, but you would never tell a professional basketball player to *"just go play"* – so why is "just build things" such a common trope when it comes to learning technical topics?

My running theory is it's because it's the most generic, widely applicable advice that is certain to be true. You do get better by *"just building things"*. The problem is the most widely applicable approach is almost never the most efficient one.

If there's anything we're able to take away from how professional athletes train, it's that they've mastered how to take a scenario they'll likely see in competition, and simulate it in practice. No opponents, no score, no fans – just a hyperfocused obsession with mastering their craft.

When we built react.gg, __this__ is the experience we wanted to recreate.

At this point, you've already experienced 45 of these real-world simulated scenarios in the challenges you've done. They've allowed you to get comfortable with every aspect of React, without the burden of needing to dive into a fully fledged project. No repo, no `node_modules`, no context – just a hyperfocused environment for mastering your craft.

The tradeoff here, of course, is that a "real-world *simulated* environment" is still just that – simulated.

The course was still, despite our best effort, missing *something* that would allow you to get comfortable with the *actual* code you'll see in the *actual* projects you'll work on.

Then we had an idea. If we wanted you to get real-world experience, what better way than to have you build a real-world React library. Naturally, this led us to the creation of [useHooks](https://usehooks.com) - a library of 50 modern, real-world, production ready React hooks that as of this writing gets more than [20,000](https://npmjs.com/package/@uidotdev/usehooks) downloads a week.

What I love about useHooks, and what's impossible to do with traditional course projects, is that *everything* we've covered in the course so far is used in the library. There isn't one thing you've learned that you won't see again in one form or another in useHooks. Not only that, but by the nature of building reusable hooks, you'll also get more familiar with fundamental browser APIs like `localStorage`, `matchMedia`, and `IntersectionObserver` to name a few.

And the best part is you'll be able to use useHooks (or your own version) in your own projects.

Good luck!

Rebuilding useHooks

`useDocumentTitle` allows you to dynamically update the `title` of a webpage. 

```js
useDocumentTitle("New Title")
```

For the full documentation, see [usehooks.com/usedocumenttitle](https://usehooks.com/usedocumenttitle).

#### Tasks

1. Update the document's title with the first argument passed to `useDocumentTitle`
2. Update the document's title when the first argument passed to `useDocumentTitle` changes

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="usedocumenttitle-solution-j4n2p7"
  previewHeight="300px"
/>

useDocumentTitle

The `useDefault` hook behaves similar to `useState` but with one difference – if the state of the hook is `undefined` or `null`, `useDefault` will default the state back to a provided default value.

```js
const [state, setState] = useDefault(initialValue, defaultValue);
```

For the full documentation, see [usehooks.com/usedefault](https://usehooks.com/usedefault).

#### Tasks

1. `useDefault` should return an array
2. On the initial render, the state that `useDefault` returns should be the same as the `initialValue` given to `useDefault` when it was invoked
3. When invoked, `useDefault`'s updater function should update its state to the value passed to the updater function
4. If `useDefault`'s state becomes `undefined`, the state that `useDefault` returns should be the `defaultValue` given to `useDefault` when it was invoked
5. If `useDefault`'s state becomes `null`, the state that `useDefault` returns should be the `defaultValue` given to `useDefault` when it was invoked

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="usedefault-solution-7qftv4"
  previewHeight="300px"
/>

useDefault

`useToggle` has a similar API to `useState` in that both return an array with the first item being the state and the second item being a way to update that state. However, unlike `useState`, `useToggle`'s state value can only ever be a boolean.

```js
const [on, setOn] = useToggle(true);

setOn() // false
setOn() // true
setOn(false) // false
setOn(true) // true
setOn("state is still toggled") // false
```

For the full documentation, see [usehooks.com/usetoggle](https://usehooks.com/usetoggle).

#### Tasks

1. `useToggle` should correctly establish its initial value, casting it to a boolean if it's not one
2. `useToggle` should toggle the state when its updater function is invoked without a value
3. `useToggle` should set the state to the provided value when its updater function is called with a boolean value
4. `useToggle` should not change the state when its updater function is called with the same boolean value
5. `useToggle` should toggle the state when its updater function is called with a value that isn't a boolean

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="usetoggle-solution-nrhm56"
  previewHeight="300px"
/>

useToggle

`usePrevious` is useful for tracking what a value was during the previous render. This can be particularly handy in scenarios where it's necessary to compare the current value with the previous one, such as triggering actions or rendering based on changes.

```js
const previousValue = usePrevious(value);
```

For the full documentation, see [usehooks.com/useprevious](https://usehooks.com/useprevious).

#### Tasks

1. `usePrevious` should return `null` on the first render
2. `usePrevious` should return the previous value when the current value changes

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="useprevious-solution-hmr2sl"
  previewHeight="300px"
/>

usePrevious

`usePreferredLanguage` returns a string that represents the preferred language of the user, as set in the browser settings. You can get access to their preferred language via `navigator.language`. You can listen to changes to the preferred language by adding an event listener for the `languagechange` event.

```js
const language = usePreferredLanguage()
```

#### Tasks

1. `usePreferredLanguage` should return the user's preferred language as a string
2. `usePreferredLanguage` should listen for changes to the user's preferred language and update the return value accordingly
3. `usePreferredLanguage` should unsubscribe from the `languagechange` event when the component that uses `usePreferredLanguage` is removed from the DOM
4. `usePreferredLanguage` should throw an error if it's used on the server

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="usepreferredlanguage-solution-pqwkjw"
  previewHeight="400px"
/>

usePreferredLanguage

`useFavicon` allows you to dynamically update the document's favicon. 

```js
useFavicon("https://ui.dev/favicon/favicon-32x32.png")
```

For the full documentation, see [usehooks.com/usefavicon](https://usehooks.com/usefavicon).

#### Tasks

1. Update the document's favicon with the `href` passed to `useFavicon`
2. Update the document's favicon when the `href` passed to `useFavicon` changes

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="usefavicon-solution-4kgxwm"
  previewHeight="300px"
/>

useFavicon

The `useCopyToClipboard` hook provides a simple way to copy text to the user's clipboard.

```js
const [copiedText, copyToClipboard] = useCopyToClipboard();

...

copyToClipboard("Text to copy");
```

For the full documentation, see [usehooks.com/usecopytoclipboard](https://usehooks.com/usecopytoclipboard).


#### Tasks

1. `useCopyToClipboard` should return an array with the first item being the value that was copied and the second being a function to copy a value to the user's clipboard
2. The first item in the array that `useCopyToClipboard` returns should be the value that was copied to the clipboard
3. The second item in the array that `useCopyToClipboard` returns should copy a provided value to the user's clipboard
4. `useCopyToClipboard` should provide a fallback for the copy functionality for browsers that don't support `navigator.writeText`

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="usecopytoclipboard-solution-98zm8h"
  previewHeight="400px"
/>

useCopyToClipboard

`useInterval` provides a convenient way to create and manage intervals in React. Using `window.setInterval` under the hood, `useInterval` repeatedly invokes a provided `callback` function at a specified `interval` and automatically clears the interval when the component using `useInterval` is removed from the DOM.

```js
const clear = useInterval(callback, interval);
```

For the full documentation, see [usehooks.com/useinterval](https://usehooks.com/useinterval).

#### Tasks

1. `useInterval` should accept a `callback` function and an `interval` integer as arguments
2. `useInterval` should invoke the `callback` function every `interval` milliseconds
3. `useInterval` should return a function that clears the interval
4. `useInterval` should clear the interval when the component using `useInterval` is removed from the DOM

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="useinterval-solution-c6tns3"
  previewHeight="500px"
/>

useInterval

`useCounter` is a hook for managing a numeric counter value. It allows you to specify a `min` and `max` value, then gives you helper methods (`increment`, `decrement`, `set`, and `reset`) for managing the value.

```js
const [count, { increment, decrement, set, reset }] = useCounter(initialCountValue, {
  min: 5,
  max: 10
});
```

For the full documentation, see [usehooks.com/usecounter](https://usehooks.com/usecounter).

#### Tasks

1. As its first argument, `useCounter` should accept a starting value and default it to `0` if no value is provided
2. As its second argument, `useCounter` should also accept an object with `min` and `max` values and throw an error if the starting value is outside of that range
3. `useCounter` should return an array with the first item being the current value of count and the second being an object with `increment`, `decrement`, `set`, and `reset` methods
4. `useCounter` should increment the count value by `1` when `increment` is called (unless the `max` value is reached)
5. `useCounter` should decrement the count value by 1 when `decrement` is called (unless the `min` value is reached)
6. `useCounter` should set the count value to the provided value when `set` is called (unless the `min` or `max` value is reached)
7. `useCounter` should reset the count value to the starting value when `reset` is called (unless the count value is already the starting value)


#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="usecounter-solution-s3mshn"
  previewHeight="300px"
/>

useCounter

The `useLockBodyScroll` hook temporarily disables scrolling on the document. This can be beneficial in scenarios where you want to restrict scrolling while displaying a modal, a dropdown menu, or any other component that requires the user’s focus. Once the component using `useLockBodyScroll` is removed from the DOM, the original overflow style should be reapplied, ensuring that the scroll behavior is reverted to its previous state.

For the full documentation, see [usehooks.com/uselockbodyscroll](https://usehooks.com/uselockbodyscroll).

#### Tasks

1. `useLockBodyScroll` should prevent the user from scrolling the document by setting `overflow` to `hidden` on the document's body
2. `useLockBodyScroll` should continue to prevent the user from scrolling across multiple component re-renders
3. `useLockBodyScroll` should reset the `overflow` position back to its original value when the component using `useLockBodyScroll` is removed from the DOM

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="uselockbodyscroll-solution-lcyd2t"
  previewHeight="700px"
/>

useLockBodyScroll

`useQueue` gives you an easy way to manage a queue type data structure. If you're not familiar, a queue follows the FIFO (first in, first out) principle. This means that the first element added to the queue is the first element that should be removed.

```js
const { add, remove, clear, first, last, size, queue } = useQueue(initialValue);
```

For the full documentation, see [usehooks.com/usequeue](https://usehooks.com/usequeue).

#### Tasks

1. `useQueue` should accept an `initialValue` argument that will be used to initialize the `queue`.
2. `useQueue` should return an object with `add`, `remove`, `clear`, `first`, `last`, `size`, and `queue` properties
3. `useQueue` should implement an `add` method that adds an element to the end of the `queue`
4. `useQueue` should implement a `remove` method that removes the first element from the `queue` and returns it
5. `useQueue` should implement a `clear` method that sets the `queue` to an empty array
6. `useQueue` should implement a `first` property that returns the first element in the `queue`
7. `useQueue` should implement a `last` property that returns the last element in the `queue`
8. `useQueue` should implement a `size` property that returns the size of the `queue`


#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="usequeue-solution-tgdr8k"
  previewHeight="300px"
/>

useQueue

`useTimeout` provides a convenient way to create and manage timeouts in React. Using `window.setTimeout` under the hood, `useTimeout` invokes a provided `callback` function after `ms` milliseconds and automatically clears the timeout when the component using `useTimeout` is removed from the DOM.

```js
const clear = useTimeout(callback, ms);
```

For the full documentation, see [usehooks.com/usetimeout](https://usehooks.com/usetimeout).

#### Tasks

1. `useTimeout` should invoke the provided callback function after `ms` milliseconds
2. `useTimeout` should reset the timeout when the `ms` prop changes
3. `useTimeout` should return a function that clears the timeout
4. `useTimeout` should clear the timeout when the component using `useTimeout` is removed from the DOM

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="usetimeout-solution-c7m52v"
  previewHeight="400px"
/>


useTimeout

The `useWindowSize` hook is useful for retrieving and tracking the dimensions (`innerWidth` and `innerHeight`) of the browser window. It attaches an event listener to the `resize` event, ensuring its state (`width` and `height`) are updated dynamically whenever the window is resized.

```js
const { width, height } = useWindowSize()
```

For the full documentation, see [usehooks.com/usewindowsize](https://usehooks.com/usewindowsize).

#### Tasks

1. `useWindowSize` should return the correct `width` and `height` values of the browser's dimension
2. When the browser is resized, `useWindowSize` should return the updated `width` and `height` values of the browser's dimension
3. `useWindowSize` should clean up any event listeners it established when the component using `useWindowSize` is removed from the DOM

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="usewindowsize-solution-m8n3lt"
  previewHeight="300px"
/>

useWindowSize

`useVisibilityChange` is useful for tracking the visibility state (`document.visibilityState`) of the document. It returns a boolean value that indicates whether the document is visible or not. It also updates the value when the `document`'s visibility state changes by adding an event listener to the `document`'s `visibilitychange` event.

```js
const documentVisible = useVisibilityChange();
```

For the full documentation, see [usehooks.com/usevisibilitychange](https://usehooks.com/usevisibilitychange).

#### Tasks

1. `useVisibilityChange` should return a boolean value that defaults to `true`
2. `useVisibilityChange` should return `true` when the document is visible
3. `useVisibilityChange` should return `false` when the document is not visible
4. `useVisibilityChange` should clean up the event listener when the component using `useVisibilityChange` is removed from the DOM

#### The Result

The final version of your app should look and behave like this.

<CodePreview
  hideEditor
  sandboxId="usevisibilitychange-solution-hd2sct"
  previewHeight="300px"
/>