add videos

epicweb-dev · Aug 26, 2024 · b52df7d · b52df7d
1 parent 1a8ea26
commit b52df7d
Show file tree

Hide file tree

Showing 54 changed files with 108 additions and 0 deletions.
diff --git a/exercises/01.elements/01.problem.reuse/README.mdx b/exercises/01.elements/01.problem.reuse/README.mdx
@@ -1,5 +1,7 @@
 # Reusing Elements
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/reusing-elements" />
+
 👨‍💼 We're going to be building a simple user interface and in the process we want
 to limit unnecessary renders as much as possible (not because it's necessary
 for this specific application, but because it's a useful exercise for you to

diff --git a/exercises/01.elements/01.solution.reuse/README.mdx b/exercises/01.elements/01.solution.reuse/README.mdx
@@ -1,4 +1,6 @@
 # Reusing Elements
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/reusing-elements/solution" />
+
 👨‍💼 Great! Now we're not unnecessarily rendering the `Footer` component. But
 let's complicate things a little bit more...
diff --git a/exercises/01.elements/02.problem.props/README.mdx b/exercises/01.elements/02.problem.props/README.mdx
@@ -1,5 +1,7 @@
 # Element Props
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/element-props" />
+
 🧝‍♂️ I've enhanced our app a bit to add some buttons that will control the color
 of our footer. This means we can't just render the component outside the `App`
 component since we need to pass the `color` as a prop. Feel free

diff --git a/exercises/01.elements/02.solution.props/README.mdx b/exercises/01.elements/02.solution.props/README.mdx
@@ -1,5 +1,7 @@
 # Element Props
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/element-props/solution" />
+
 👨‍💼 Great! So we can still make dynamic elements that are positioned where we
 want them to be without allowing them to be rerendered with every state change
 by passing them as props! This is the composition pattern from the Advanced

diff --git a/exercises/01.elements/03.problem.context/README.mdx b/exercises/01.elements/03.problem.context/README.mdx
@@ -1,5 +1,7 @@
 # Context
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/context" />
+
 👨‍💼 We now have a counter inside the `App` component and every time that count is
 incremented, we trigger a rerender of the `Footer` component! Have we lost the
 ability to take advantage of React's element optimization? No!

diff --git a/exercises/01.elements/03.solution.context/README.mdx b/exercises/01.elements/03.solution.context/README.mdx
@@ -1,4 +1,6 @@
 # Context
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/context/solution" />
+
 👨‍💼 Interesting that we can manage to really take this optimization with React
 elements so far huh? Well, let's try another one...
diff --git a/exercises/01.elements/04.problem.use-memo/README.mdx b/exercises/01.elements/04.problem.use-memo/README.mdx
@@ -1,5 +1,7 @@
 # Memoize Elements
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/memoize-elements" />
+
 👨‍💼 Now we want our users to be able to type their name and have that show up in
 the footer. But we don't want to use context for the name like we do with the
 color just yet. We just want to be able to pass the `name` as a regular prop.

diff --git a/exercises/01.elements/04.solution.use-memo/README.mdx b/exercises/01.elements/04.solution.use-memo/README.mdx
@@ -1,5 +1,7 @@
 # Memoize Elements
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/memoize-elements/solution" />
+
 👨‍💼 This is a bit of an unconventional approach to optimizing things, but it's
 cool to understand how all this works and see how far we can take this
 optimization that's built-into React! Let's take this a bit further with

diff --git a/exercises/01.elements/05.problem.memo/README.mdx b/exercises/01.elements/05.problem.memo/README.mdx
@@ -1,5 +1,7 @@
 # Memoize Components
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/memoize-components" />
+
 🦉 Memoizing elements is such a common idea that React has a built-in optimizer
 called `memo` which allows you to memoize an entire component based on its
 props:

diff --git a/exercises/01.elements/05.solution.memo/README.mdx b/exercises/01.elements/05.solution.memo/README.mdx
@@ -1,5 +1,7 @@
 # Memoize Components
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/memoize-components/solution" />
+
 👨‍💼 Great work!
 
 🦉 What's interesting is we could actually move the `Footer` to be rendered

diff --git a/exercises/01.elements/FINISHED.mdx b/exercises/01.elements/FINISHED.mdx
@@ -1,5 +1,7 @@
 # Element Optimization
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/dad-joke-break-element-optimization" />
+
 👨‍💼 Great work! You've really explored React's element optimization a lot in this
 exercise and hopefully it informs how you structure your components going
 forward.

diff --git a/exercises/01.elements/README.mdx b/exercises/01.elements/README.mdx
@@ -1,5 +1,7 @@
 # Element Optimization
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/intro-to-element-optimization" />
+
 Elements are the fundamentals building blocks of React UI. It was the first
 we started with when you started learning React in this workshop series. And
 React has some smarts under the hood we can take advantage of when we're

diff --git a/exercises/02.context/01.problem.memo-context/README.mdx b/exercises/02.context/01.problem.memo-context/README.mdx
@@ -1,5 +1,7 @@
 # Memoize Context
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/memoize-context" />
+
 🧝‍♂️ I've taken the `name` and `color` state and combined them into a single
 `FooterContext` as well as extracted some of the UI into a `FooterSetters`
 component (for all the stuff that allows you to control the `Footer`). Feel free

diff --git a/exercises/02.context/01.solution.memo-context/README.mdx b/exercises/02.context/01.solution.memo-context/README.mdx
@@ -1,4 +1,6 @@
 # Memoize Context
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/memoize-context/solution" />
+
 👨‍💼 Super duper! You've been able to keep our components rerendering only when
 necessary again. Well done.
diff --git a/exercises/02.context/02.problem.provider-component/README.mdx b/exercises/02.context/02.problem.provider-component/README.mdx
@@ -1,5 +1,7 @@
 # Provider Component
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/provider-component" />
+
 👨‍💼 We've noticed that when we change some of the Footer context stuff, we're
 actually rerendering the `App` and `Main` components even though those don't
 have anything to do with the Footer context.

diff --git a/exercises/02.context/02.solution.provider-component/README.mdx b/exercises/02.context/02.solution.provider-component/README.mdx
@@ -1,5 +1,7 @@
 # Provider Component
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/provider-component/solution" />
+
 👨‍💼 Great work! You've eliminated more unnecessary rerenders!
 
 🦉 This is a really common pattern in the React community. It's kind of natural.

diff --git a/exercises/02.context/03.problem.split-context/README.mdx b/exercises/02.context/03.problem.split-context/README.mdx
@@ -1,5 +1,7 @@
 # Split Context
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/split-context" />
+
 👨‍💼 Something you may have noticed is that the `FooterSetters` component is
 rerendering whenever the footer state changes, but that component doesn't
 actually depend on the footer state at all. All it cares about is the setter

diff --git a/exercises/02.context/03.solution.split-context/README.mdx b/exercises/02.context/03.solution.split-context/README.mdx
@@ -1,4 +1,6 @@
 # Split Context
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/split-context/solution" />
+
 👨‍💼 You've done good work! When you've got a lot of components that only consume
 the setters, this can be a good way to optimize those components.
diff --git a/exercises/02.context/FINISHED.mdx b/exercises/02.context/FINISHED.mdx
@@ -1,4 +1,6 @@
 # Optimize Context
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/dad-joke-break-optimize-context" />
+
 👨‍💼 Great work! You now have some great context optimizations in your back
 pocket to use whenever you run into performance problems (and not before!!).
diff --git a/exercises/02.context/README.mdx b/exercises/02.context/README.mdx
@@ -1,5 +1,7 @@
 # Optimize Context
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/intro-to-optimize-context" />
+
 The way that context works is that whenever the provided value changes from one
 render to another, it triggers a re-render of all the consuming components
 (which will re-render whether or not they're memoized).

diff --git a/exercises/03.concurrent-rendering/01.problem.deferred/README.mdx b/exercises/03.concurrent-rendering/01.problem.deferred/README.mdx
@@ -1,5 +1,7 @@
 # useDeferredValue + memo
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/usedeferredvalue-and-memo" />
+
 👨‍💼 We've got a performance problem with our `Card` component in this UI. (🧝‍♂️
 actually, I just added an arbitrary slowdown to simulate a problem to keep this
 exercise simple while still teaching the lesson). As a result, every time we

diff --git a/exercises/03.concurrent-rendering/01.solution.deferred/README.mdx b/exercises/03.concurrent-rendering/01.solution.deferred/README.mdx
@@ -1,5 +1,7 @@
 # useDeferredValue + memo
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/usedeferredvalue-and-memo/solution" />
+
 👨‍💼 Great work! You've managed to drastically improve this user experience by
 making the UI responsive even when rerendering the cards is slow. All with a
 simple `memo` and a `useDeferredValue`. Great job!
diff --git a/exercises/03.concurrent-rendering/FINISHED.mdx b/exercises/03.concurrent-rendering/FINISHED.mdx
@@ -1,5 +1,7 @@
 # Concurrent Rendering
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/dad-joke-break-concurrent-rendering" />
+
 👨‍💼 React managed to provide this feature to developers by re-writing the
 internals of React while avoiding huge breaking changes to developer's apps.
 Really impressive! And now you know how to take advantage of `useDeferredValue`

diff --git a/exercises/03.concurrent-rendering/README.mdx b/exercises/03.concurrent-rendering/README.mdx
@@ -1,5 +1,7 @@
 # Concurrent Rendering
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/concurrent-rendering-intro" />
+
 Sometimes, you're rendering so many components or those components are doing
 such complex things that you can't afford to render them all quickly enough.
 

diff --git a/exercises/04.code-splitting/01.problem.lazy/README.mdx b/exercises/04.code-splitting/01.problem.lazy/README.mdx
@@ -1,5 +1,7 @@
 # lazy
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/lazy" />
+
 👨‍💼 Our app has a neat Globe component that shows the user where they are on the
 globe. Cool right? It's super duper fun.
 

diff --git a/exercises/04.code-splitting/01.solution.lazy/README.mdx b/exercises/04.code-splitting/01.solution.lazy/README.mdx
@@ -1,5 +1,7 @@
 # lazy
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/lazy/solution" />
+
 👨‍💼 Great! That makes our initial page load **much** lighter than before. Based
 on my count in the development environment, we've gone from 2.0 MB JavaScript
 downloaded to 1.4 MB. That's a 30% reduction in the amount of JavaScript we're

diff --git a/exercises/04.code-splitting/02.problem.eager/README.mdx b/exercises/04.code-splitting/02.problem.eager/README.mdx
@@ -1,5 +1,7 @@
 # Eager Loading
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/eager-loading" />
+
 👨‍💼 So it's great that the users can get the app loaded faster, but it's annoying
 when 99% of the time the reason the users are using the app is so they can
 interact with our globe. We don't want to have to make them wait first to load

diff --git a/exercises/04.code-splitting/02.solution.eager/README.mdx b/exercises/04.code-splitting/02.solution.eager/README.mdx
@@ -1,5 +1,7 @@
 # Eager Loading
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/eager-loading/solution" />
+
 👨‍💼 Great. Now we're loading it a bit sooner. In general, this is a helpful
 practice to reduce the amount of time between when the user indicates they want
 to see something and when they actually see it.

diff --git a/exercises/04.code-splitting/03.problem.transition/README.mdx b/exercises/04.code-splitting/03.problem.transition/README.mdx
@@ -1,5 +1,7 @@
 # Transitions
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/transitions" />
+
 👨‍💼 By default, when a component suspends (like our `lazy` component is while
 we're lazy-loading some code), React will render the fallback of our suspense
 boundary immediately. Go ahead and try it now. Hover over the checkbox for long

diff --git a/exercises/04.code-splitting/03.solution.transition/README.mdx b/exercises/04.code-splitting/03.solution.transition/README.mdx
@@ -1,4 +1,6 @@
 # Transitions
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/transitions/solution" />
+
 👨‍💼 React gives us lots of options to control the user experience we're after
 while also optimizing things for performance. Great work on this one!
diff --git a/exercises/04.code-splitting/FINISHED.mdx b/exercises/04.code-splitting/FINISHED.mdx
@@ -1,5 +1,7 @@
 # Code Splitting
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/dad-joke-break-code-splitting" />
+
 👨‍💼 Great job! You've successfully added code splitting for a part of the app
 that is particularly "heavy." This will help reduce the initial load time of
 your app and improve the user experience.
diff --git a/exercises/04.code-splitting/README.mdx b/exercises/04.code-splitting/README.mdx
@@ -1,5 +1,7 @@
 # Code Splitting
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/intro-to-code-splitting" />
+
 Code splitting acts on the principle that loading less code will speed up your
 app. Say for example that we're building a complex dashboard application that
 includes the venerable d3 library for graphing data. Your users start

diff --git a/exercises/05.calculations/01.problem.use-memo/README.mdx b/exercises/05.calculations/01.problem.use-memo/README.mdx
@@ -1,5 +1,7 @@
 # useMemo
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/usememo" />
+
 👨‍💼 We have a combobox that's calling `searchCities` every render. This function
 is really slow because it's attempting to intelligently sort thousands of items
 based on the user's filter input.

diff --git a/exercises/05.calculations/01.solution.use-memo/README.mdx b/exercises/05.calculations/01.solution.use-memo/README.mdx
@@ -1,5 +1,7 @@
 # useMemo
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/usememo/solution" />
+
 👨‍💼 Wow! That's a significant improvement!
 
 🦉 Even with this improvement, it seems like React is doing a lot of extra work

diff --git a/exercises/05.calculations/02.problem.worker/README.mdx b/exercises/05.calculations/02.problem.worker/README.mdx
@@ -1,5 +1,7 @@
 # Web Worker
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/web-worker" />
+
 <callout-warning>
 	Warning, this one's _really_ cool, but kinda tricky... Also, the intent isn't
 	necessarily for you to learn about [web

diff --git a/exercises/05.calculations/02.solution.worker/README.mdx b/exercises/05.calculations/02.solution.worker/README.mdx
@@ -1,3 +1,5 @@
 # Web Worker
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/web-worker/solution" />
+
 👨‍💼 Great! Now we're ready for the next step.
diff --git a/exercises/05.calculations/03.problem.async/README.mdx b/exercises/05.calculations/03.problem.async/README.mdx
@@ -1,5 +1,7 @@
 # Async Results
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/async-results" />
+
 👨‍💼 Now that we have a web worker we can work with, let's refactor our `App` to
 use this new async data source. We'll be using React's `use` hook and passing
 a promise to that. This means we'll want to have state for the promises of data

diff --git a/exercises/05.calculations/03.solution.async/README.mdx b/exercises/05.calculations/03.solution.async/README.mdx
@@ -1,5 +1,7 @@
 # Async Results
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/async-results/solution" />
+
 👨‍💼 Great job! Now if you take some measurements with the dev tools, you'll
 notice that doing searches is much faster than before. Offloading this work is
 a nice improvement!

diff --git a/exercises/05.calculations/FINISHED.mdx b/exercises/05.calculations/FINISHED.mdx
@@ -1,4 +1,6 @@
 # Expensive Calculations
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/dad-joke-break-expensive-calculations" />
+
 👨‍💼 Great work! Sometimes you're just doing expensive stuff. It's cool that React
 and the web platform give us great tools for managing those... expenses 🤑
diff --git a/exercises/05.calculations/README.mdx b/exercises/05.calculations/README.mdx
@@ -1,5 +1,7 @@
 # Expensive Calculations
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/intro-to-expensive-calculations" />
+
 React hooks are amazing. Being able to put all the logic and state management
 within a function component allows for mind blowing composability.
 

diff --git a/exercises/06.rerenders/01.problem.memo/README.mdx b/exercises/06.rerenders/01.problem.memo/README.mdx
@@ -1,5 +1,7 @@
 # Component Memoization
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/component-memoization" />
+
 👨‍💼 We've got a problem. Here's how you reproduce it in our component.
 
 In this exercise, pull up the React DevTools Profiler and start a recording.

diff --git a/exercises/06.rerenders/01.solution.memo/README.mdx b/exercises/06.rerenders/01.solution.memo/README.mdx
@@ -1,5 +1,7 @@
 # Component Memoization
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/component-memoization/solution" />
+
 👨‍💼 Great job! You've managed to really improve the performance of our list when
 unrelated updates occur. But what if there are updates to the list itself?
 Hmm...
diff --git a/exercises/06.rerenders/02.problem.comparator/README.mdx b/exercises/06.rerenders/02.problem.comparator/README.mdx
@@ -1,5 +1,7 @@
 # Custom Comparator
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/custom-comparator" />
+
 👨‍💼 We've improved things so the `ListItem` components don't rerender when there
 are unrelated changes, but what if there are changes to the list item state?
 

diff --git a/exercises/06.rerenders/02.solution.comparator/README.mdx b/exercises/06.rerenders/02.solution.comparator/README.mdx
@@ -1,4 +1,6 @@
 # Custom Comparator
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/custom-comparator/solution" />
+
 👨‍💼 Great! The performance is better! Unfortunately, that custom comparator is
 kinda complex. I wonder if we could simplify it a bit...
diff --git a/exercises/06.rerenders/03.problem.primitives/README.mdx b/exercises/06.rerenders/03.problem.primitives/README.mdx
@@ -1,5 +1,7 @@
 # Primitives
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/primitives" />
+
 👨‍💼 I would love to have the performance improvement without all the complexity
 of the custom comparator function.
 

diff --git a/exercises/06.rerenders/03.solution.primitives/README.mdx b/exercises/06.rerenders/03.solution.primitives/README.mdx
@@ -1,4 +1,6 @@
 # Primitive Values
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/primitives/solution" />
+
 👨‍💼 Great job! That's much better! We still get the perf benefits with `memo`
 without all the complexity of a custom comparator function.
diff --git a/exercises/06.rerenders/FINISHED.mdx b/exercises/06.rerenders/FINISHED.mdx
@@ -1,4 +1,6 @@
 # Optimize Rendering
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/dad-joke-break-optimize-rendering" />
+
 👨‍💼 When you find yourself rendering a ton of the same component, optimizing that
 one component can have an outsized impact on performance. Good job!
diff --git a/exercises/06.rerenders/README.mdx b/exercises/06.rerenders/README.mdx
@@ -1,5 +1,7 @@
 # Optimize Rendering
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/intro-to-optimize-rendering" />
+
 Here's the lifecycle of a React app:
 
 ![→ render → reconciliation → commit → state change → rerender](/img/react-render-cycle.png)

diff --git a/exercises/07.windowing/01.problem.virtualizer/README.mdx b/exercises/07.windowing/01.problem.virtualizer/README.mdx
@@ -1,5 +1,7 @@
 # Virtualizer
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/virtualizer" />
+
 Hover over one of the items with CPU 6x throttle and it's crazy slow despite
 only re-rendering the ListItem
 

diff --git a/exercises/07.windowing/01.solution.virtualizer/README.mdx b/exercises/07.windowing/01.solution.virtualizer/README.mdx
@@ -1,4 +1,6 @@
 # Virtualizer
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/virtualizer/solution" />
+
 👨‍💼 Great job! Even with returning all of the results and slowing down the CPU to
 6x, we're still getting great performance on this list. Well done 👏👏
diff --git a/exercises/07.windowing/FINISHED.mdx b/exercises/07.windowing/FINISHED.mdx
@@ -1,5 +1,7 @@
 # Windowing
 
+<EpicVideo url="https://www.epicreact.dev/workshops/react-performance/dad-joke-break-windowing" />
+
 👨‍💼 You did it! Great work on improving the performance of this component!
 
 🦉 One thing you should know about virtualization is that ⌘+F (or on