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

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

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

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

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

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



Test Post With Video

When was the last time you saw an error and had _no idea_ what it meant (and therefore no idea what to do about it)? Today? Yeah, you're not alone... Let's talk about how to fix that.

## A story

A while ago, I got a new faucet. It's one of those cool ones where the head of the faucet could come off so we could direct the water's flow and would automatically retract back into the neck when you're done. Unfortunately, it wasn't long before we had a problem:

![Faucet with the head not retracting into the neck](/articles-images/requisite-react/broken-faucet.png)

The head of the faucet wouldn't automatically go back into the neck! And we couldn't even push it back in. It just hung there. Like a sad flower 🥀

So we called the plumber who had installed it for us to have them come look at it and see if they could fix it or give us a replacement. A few days later was the day of our appointment. A few hours before he arrived, I looked frustratingly at the faucet and wondered... So I looked under the sink, and this is what I saw:

![Under a sink a faucet hose is tangled in itself](/articles-images/requisite-react/tangled-hose.png)

That's the hose for our faucet. It turns out there's a simple weight that goes on the hose and that weight is what pulls the head of the faucet into the neck. Because it was tangled in itself, the weight wasn't pulling the hose down. So I reached in and untangled the hose:

![Under a sink a faucet hose is untangled](/articles-images/requisite-react/untangled-hose.png)

And like a miracle, it suddenly worked! I called the plumber to cancel as quickly as I could to avoid revealing my shame. Can you imagine if I hadn't discovered the problem and they came over, untangled the hose, and gave me an invoice for their trouble. I don't know if I could have taken that hit to my ego. The embarrassment would have been too much 🙈

So what does a faucet problem have to do with React? A faucet is an abstraction. We don't have to have faucets. We could just pull the hose straight out of the wall and use that instead, but we put the faucet in place because it makes the water more useful. Normally it works fine, but when there's a problem, if you don't understand how the abstraction works, it's difficult to figure out what went wrong and how to resolve the problem.

## A universal truth

React is an abstraction too. And here's a universal truth about abstractions:

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

Abstractions are all around us. Your phone is an abstraction. Your car is an abstraction. And the better we understand how those things work, the better we are able to use them. And that's not to say that you _can't_ use the abstraction if you don't know how they work. I drive my car all the time and I have no idea how it works. But whenever something goes wrong with it, I'm at a total loss (and that's just the way my mechanic likes it 🤑).

You can use React without a good foundation in the fundamentals and that's totally fine. You can ship really amazing things without a solid foundation. But if you'd like to level-up on your capabilities and productivity with React, then digging in and gaining an understanding in how they work is the way to do it.

## A simple example

There's a fun site [YouMightNotNeedjQuery.com](http://youmightnotneedjquery.com/) which shows common jQuery functions and the code needed for that same functionality based on the browser support you have (up to IE10).

So let's imagine that you needed [jQuery's `toggleClass` functionality](https://api.jquery.com/toggleclass/) so you copy/pasted the code from YouMightNotNeedjQuery.com and built this function so you don't have to bring all of jQuery into your app:

```javascript
function toggleClass(el, className) {
  if (el.classList) {
    el.classList.toggle(className)
  } else {
    var classes = el.className.split(' ')
    var existingIndex = -1
    for (var i = classes.length; i--; ) {
      if (classes[i] === className) existingIndex = i
    }

    if (existingIndex >= 0) classes.splice(existingIndex, 1)
    else classes.push(className)

    el.className = classes.join(' ')
  }
}
```

What you've created is your own little abstraction. But actually, you're also _using_ an abstraction: the DOM. And if you knew a little bit more about that abstraction, you'd know that browsers (including IE10) have support for this built-in. So that function could be simplified... a lot:

```javascript
function toggleClass(el, className) {
  el.classList.toggle(className)
}
```

So by understanding the abstraction we're using (the DOM in this case), we're able to drastically simplify our code which ultimately [impacts our users](https://kentcdodds.com/blog/why-users-care-about-how-you-write-code).

## A problem with learning abstractions

These days not many people build an application without using a soup of tools and libraries to do so. Unfortunately, if you skip over the fundamentals of each tool, it's easy for your understanding of each to become muddled. Is React managing my state or React Query? Is Babel compiling my JSX or React? Do I need PropTypes if I'm using TypeScript? Isn't redux required if you're building a React app? (That last one is a definite no).

One of the biggest causes for people's struggle at understanding abstractions is they struggle to draw lines around the abstractions. When you're not sure which abstraction should do which job, it's very easy to use the wrong tool for the job. Sure you can get it working eventually, but you may be left with a solution that causes you and ultimately your users some real pain.

So a great first step to understanding your abstractions better is to learn them in isolation from one another and only add them to your learning when you run into the problem they actually solve.

Too many people start learning and using React with Webpack, Babel, React Router, Redux, Jest, React Testing Library, Material UI, etc. etc. This makes it really difficult to draw lines around these abstractions and really understand the purpose of each.

## A different approach

This is why [EpicReact.Dev](https://epicreact.dev) introduces one concept at a time. And we don't skip anything. As you just get started, we literally write JavaScript in a script tag of an HTML file. We don't even write React first. We start with regular DOM nodes. Then we add `React.createElement`. Then we add JSX. And we methodically add more and more concepts over time so you get a good idea of what tools are responsible for what so you can use each as effectively as possible.

This is why people who have been using React for _years_ tell me that they _still_ learn new things from my beginner material. Because we so often skip over that methodical approach when we're in a rush to ship something.

## Time to level-up

If you're tired of seeing errors pop up in your console and not understanding what to do about them, then gaining a deeper understanding of the fundamentals of how things work is the best thing you can do to get over that. If you're tired of fumbling around with wiring things together and praying that nobody blows your house of cards over, then taking a bit to sharpen your understanding of your primary abstractions (like React) will go a long way.

And this is exactly why I created [EpicReact.Dev](https://epicreact.dev): To help you level-up your professional React knowledge and productivity.

When was the last time you saw an error and had no idea what it meant (and therefore no idea what to do about it)? Today? Yeah, you're not alone... Let's talk about how to fix that.

Requisite React

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

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

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

## React’s core building block

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

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

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

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

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

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

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

## JSX

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

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

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

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

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

## Reusable elements: Components

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

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

You can then create that element like other elements:

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

Here’s what that element object looks like:

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

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

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

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

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

## Updating UIs with React

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

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

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

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

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

## So, what is React?

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

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

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

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

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

What is React?

Let's analyze this React tree structure:

```tsx
<App>
	<ShipSearch />
	<ShipDetails />
</App>
```

Let's assume that `App` renders the `ShipSearch` and `ShipDetails` components,
passing props as needed.

`ShipSearch` is a server component which takes a `search` and uses that to
perform a database query:

```ts
async function ShipSearch({ search }) {
	const shipResults = await searchShips({ search })
	// ... render stuff
}
```

The `ShipDetails` component is also a server component which takes a `shipId`
and uses that to perform a database query:

```ts
async function ShipDetails({ shipId }) {
	const ship = await getShip({ shipId })
	// ... render stuff
}
```

Because these are sibling components, both queries will run at the same time.

```
searchShips query  ---->  searchShips result
getShip query      ---->  getShip result
```

## Server Waterfalls

That's all fine. But let's say the `App` component needs to resolve a logged in
user:

```ts
async function App() {
	const user = await getLoggedInUser()
	// ... render stuff
}
```

Uh oh, now we have a waterfall:

```
getLoggedInUser query ---->  getLoggedInUser result
                             searchShips query      ---->  searchShips result
                             getShip query          ---->  getShip result
```

The issue here is now `App` is waiting for `getLoggedInUser` to resolve before
it can render anything. This means both `searchShips` and `getShip` won't be
executed until _after_ `getLoggedInUser` resolves, even though those don't
directly depend on the user.

This is a problem generally for React Suspense as well and I dive deep into that
in the
[React Suspense workshop exercise 6](https://suspense.epicreact.dev/exercise/06).

There are a few ways to think about this problem:

Maybe it's not a problem if `getLoggedInUser` is fast 🤷‍♂️ But that's not always a
sure thing, and even if it's fast today doesn't mean someone won't add something
else that will be slow tomorrow. Still, it's always good to think about how bad
ignoring the problem would actually be since there could be bigger fish to fry.

Alternatively, we can lift `searchShips` and `getShip` into `App` and pass the
results down to `ShipSearch` and `ShipDetails`. Then we could use `Promise.all`
to make sure they run concurrently. But passing props can get annoying pretty
fast. We can use a library like
[`@epic-web/cachified`](https://github.com/epicweb-dev/cachified) to dedupe the
queries and then `App` simply kicks off the query earlier which would at least
be better.

Unfortunately, another issue though is this can get unweildy pretty fast,
especially if there's logic around which queries should run based on other
props. You'd have to move all that logic until your entire app lives in `App`
😱.

The next solution I can come up with is to use or build a compiler which can
find all queries and preload them automatically. This is what Relay is. There
are quite a few things I don't like about this approach though:

1. If you have logic around which queries should run based on other props, this
   approach doesn't work.
2. It adds a lot of complexity to your build process.
3. When you're working in product code, it's not obvious what's happening.

So I guess what I'm saying is I don't like any of these solutions. But I'd like
to reframe the problem with more context.

## The status quo

Let's say we live in a world where we don't have RSCs or Suspense. You're just
building an app with components that fetch data and render stuff.

In that world you've got three options:

1. Group together (colocate) your queries with the components that need them.
2. Lift all your queries into a single component and pass the results down.
3. Use a compiler to find all your queries and preload them automatically.

Sound familiar? It's exactly the same problem we've always had with components
and data. There's always been this tension between colocating and passing down
data (prop drilling).

One of the nice things about Remix is that it gives you a fourth option:

4. Decouple your data fetching from your components.

This allows Remix to load data as soon as the request comes in regardless of
whether the component has rendered.

This is what I've been doing for years and it's been awesome.

## So, why RSCs?

This blog post isn't really about why I think RSCs are awesome. You can read
[React Server Components: The Future of UI](https://www.epicreact.dev/react-server-components-the-future-of-ui)
for that. Just know that composition at route boundaries is not as good as
composition at component boundaries and I want React-level composition badly.

What I want to do is show how RSCs fit into the same tension between colocating
and prop drilling that we've always had with components and data. There's no new
problems here.

But what I find interesting is how a server-side waterfall is probably better
than a client-side waterfall primarily because you get to control the network.
The connection between your server rendering server and your database is
probably stronger, faster, more reliable, and closer. Or maybe it's not, but the
point is _you_ are in control there and can make improvements to that if it's
important to you. You also have more fine-grained control over caching (requests
from separate clients can share a cache for common data).

When you have a client-side waterfall, you're dealing with the user's device and
their network connection which may be great or may be terrible but you
definitely have no control over.

So shifting this problem from the client to the server sounds like a net gain
for many scenarios.

## Conclusion

The "waterfall" problem of RSCs is not a new problem. It's the same tension
between colocating and prop drilling that we've always had with components and
data. Maybe there's a new solution we can look forward to in the future. I
welcome ideas (preferrably something that doesn't require a special compiler)!
Until then, I'm actually pretty happy with just making things fast enough that the
problem isn't a problem.


Understanding server-side waterfalls with RSCs and client-side waterfalls we're familiar with and why server-side waterfalls are probably better.

The Big "Server Waterfall Problem" with RSCs

One thing that I like about React is that it allows me to write my components like little black boxes of abstraction. I can look at a design and draw lines around the UI elements and I know the components that I'm going to be making:

For example, here's my GitHub home page:

![GitHub homepage UI](/articles-images/one-react-mistake-thats-slowing-you-down/before.png)

Can you identify the different components you might create out of this design? Here's how I look at it:

![The same UI with boxes around different UI elements](/articles-images/one-react-mistake-thats-slowing-you-down/marked-up.png)

Now, you might not need an individual component for all of these things, or you may want _more_ components. It really depends on a variety of factors we won't get into here. The mistake I want to point out is that the way we compose these UI elements together in our code often makes a drastic difference on how maintainable it is (as well as how often we feel "prop-drilling" pains).

Let's imagine how we might structure some of the components for this page:

```javascript
function App() {
  return (
    <div>
      <MainNav />
      <Homepage />
    </div>
  )
}

function MainNav() {
  return (
    <div>
      <GitHubLogo />
      <SiteSearch />
      <NavLinks />
      <NotificationBell />
      <CreateDropdown />
      <ProfileDropdown />
    </div>
  )
}

function Homepage() {
  return (
    <div>
      <LeftNav />
      <CenterContent />
      <RightContent />
    </div>
  )
}

function LeftNav() {
  return (
    <div>
      <DashboardDropdown />
      <Repositories />
      <Teams />
    </div>
  )
}

function CenterContent() {
  return (
    <div>
      <RecentActivity />
      <AllActivity />
    </div>
  )
}

function RightContent() {
  return (
    <div>
      <Notices />
      <ExploreRepos />
    </div>
  )
}
```

We could keep going, but I think that's sufficient. You may have structured this differently (or come up with a better name than `RightContent` 🤦‍♂️), but based on apps that I've built in the past as well as apps I've seen others build, this is a pretty typical structure. Before I talk about some potential issues, let me show you an alternative structure that takes advantage of React's brilliant composition model. Then we can talk about the improvements and trade-offs.

```javascript
function App() {
  return (
    <div>
      <MainNav>
        <GitHubLogo />
        <SiteSearch />
        <NavLinks />
        <NotificationBell />
        <CreateDropdown />
        <ProfileDropdown />
      </MainNav>
      <Homepage
        leftNav={
          <LeftNav>
            <DashboardDropdown />
            <Repositories />
            <Teams />
          </LeftNav>
        }
        centerContent={
          <CenterContent>
            <RecentActivity />
            <AllActivity />
          </CenterContent>
        }
        rightContent={
          <RightContent>
            <Notices />
            <ExploreRepos />
          </RightContent>
        }
      />
    </div>
  )
}

function MainNav({children}) {
  return <div>{children}</div>
}

function Homepage({leftNav, centerContent, rightContent}) {
  return (
    <div>
      {leftNav}
      {centerContent}
      {rightContent}
    </div>
  )
}

function LeftNav({children}) {
  return <div>{children}</div>
}

function CenterContent({children}) {
  return <div>{children}</div>
}

function RightContent({children}) {
  return <div>{children}</div>
}
```

What's your initial reaction to this? Shock? Awe? Curiosity? Confusion? Disgust? Is your initial reaction based on the fact that this is unfamiliar to you and therefore should be shunned? If that's the case, then I invite you to pause and consider this for a moment.

First, let me be clear that this use of React's composition capabilities can probably be taken too far. Everything with moderation. The idea here is that our structural components are responsible for layout. They likely won't do much to manage state themselves (though they certainly could). They simply accept the different stateful elements and then lay them out onto the page in the places where they're supposed to appear. Most of the time, the `children` prop is sufficient (in the Angular.js world, we call this "transclusion"), but sometimes you might have several elements that you need to lay out, so you can use specific and named props like our `Homepage` component (in the Vue.js world, we call this "slots").

## But... Why?

So, why would we do this? The biggest and best reason to do this is for state management. We're not showing any state use here, but let's imagine for a moment that we needed to pass the user around. Consider the first example. Where would you store the user's information? You'd probably store it in the `App` component because that's the "lowest common parent" of the components that require that state. From there you'd have to pass the `user`'s information (and potentially mechanisms to update the user's information) as props.

This results in "prop-drilling". For example: `<App /> -> <Homepage /> -> <CenterContent /> -> <AllActivity />` (and potentially further). People have a pretty low tolerance for this, so you're probably think that you'd use React's `context` API to solve this instead (so would I).

But consider what this would look like for our second, more composed example. You'd still need to store the `user` state in the `App` component, but what does it look like to get the user's info to the `AllActivity` component now? `<App /> -> <AllActivity />`. Boom. That's it.

## Conclusion

I think too many people go from "passing props" -> "context" too quickly. If we structure our components with more composition in mind, then I think our codebase will be more maintainable (you'll likely not need to open so many files when you make changes) and we'll have fewer performance and state management problems.

I'm excited to show you more on [EpicReact.Dev](https://epicreact.dev)!

Simplify and speed up your app development using React composition

Test Post With Video

Get my free 7-part email course on React!

More Articles

Requisite React

What is React?

The Big "Server Waterfall Problem" with RSCs

One React mistake that's slowing you down