perf

Author: btholt

lessons/05-performance-optimizations/A-where-react-can-be-slow.md

@@ -0,0 +1,19 @@
+React generally has a very good performance profile, no matter what "thought leaders" may be tweeting about it. If you write React in a way consistent with the way I taught you in this class and the intro as well as the docs, you really don't need to concern yourself too much with "is this going to perform well" because React tends to be really good at making sure average code runs fast enough.
+
+To be entirely honest, it was _hard_ to make non-performant code in React. We're going to have to resort to adding artificial slowdowns in our code because my MacBook could consistenly churn through the code inefficient code anyway, making it hard to see performance gains we're going to get. Nonetheless, these concepts aren't important until they're _very_ important.
+
+> 💡 I am about to show your four different ways to make React perform better in certain circumstances. My **strong** advice for is to not pre-emptively use these. You should wait until you have a performance problem in your UI before you try to optimize it. These tools make your code harder to read and makes bugs hard to track down (since you're getting outside of the normal way of writing React.) Have problems before you solve them.
+
+So where does React have problems some times?
+
+![React tree of five components: app, content, profile, profilepic, and profilename. App has children content and profile. Profile has children ProfilePic and ProfileName.](/images/profile.png)
+
+Imagine a change happens in the Profile component and nowhere else. What happens? Profile will update, and as apart of that, ProfilePic and ProfileName _will also run_ even though nothing changed in them. Why? React isn't sure that the change Profile won't cause some cascading effect in either of those components, and re-runs them just to be sure.
+
+Is this a problem? 99.99% no – most of the time these renders are so fast it's not even measurably different to just let them re-render, particularly if it's infrequent.
+
+Do Content and App re-render? No. Only the children in the Profile tree do.
+
+So what if ProfilePic is particularly expensive to render? Maybe it's an LLM-generated picture and it runs the LLM every time it re-renders. This could be bad: every change in Profile and App would cause re-renders in ProfilePic, even if it's not changing!
+
+This is where three tools are going to come in very helpful: memo, useMemo, and useCallback. These going to give us a finer grain control to say "only re-render when this component indeed needs to re-render."

lessons/05-performance-optimizations/B-the-project.md

@@ -0,0 +1,91 @@
+Let's open the `perf` project in our repo and run `npm install`.
+
+We're going to build a markdown previewer! On some laptops this can be pretty slow to parse and re-render to the DOM. On my laptop it's actually fast enough to get through it so we're going to introduce some artifical jank. Your computer may not need it.
+
+I left a long markdown file for you to use as a sample in markdownContent.js. I asked Claude to make some jokes for us. I'd call it a middling success.
+
+Make a new file called MarkdownPreview.jsx. Put this in there
+
+```javascript
+const JANK_DELAY = 100;
+
+export default function MarkdownPreview({ render, options }) {
+  const expensiveRender = () => {
+    const start = performance.now();
+    while (performance.now() - start < JANK_DELAY) {}
+    return null;
+  };
+  return (
+    <div>
+      <h1>Last Render: {Date.now()}</h1>
+      <div
+        className="markdown-preview"
+        dangerouslySetInnerHTML={{ __html: render(options.text) }}
+        style={{ color: options.theme }}
+      ></div>
+      {expensiveRender()}
+    </div>
+  );
+}
+```
+
+- This is the artificial jank. It ties up the main thread so it'll run slower. Feel free to modify `JANK_DELAY`. Right now I have it delaying 100ms so you can see the jank more pronounced.
+- I'm also showing the time so can see how often the component runs.
+- `dangerouslySetInnerHTML` is fun. It just means you need to _really_ trust what you're putting in there. If you just put raw user generated content in there, they could drop a script tag in there and do a good ol' [XSS attack][xss]. In this case the user can only XSS themself so that's fine enough.
+
+Okay, let's make our App.jsx
+
+```javascript
+import { useEffect } from "react";
+import { marked } from "marked";
+import { useState } from "react";
+
+import MarkdownPreview from "./MarkdownPreview";
+import markdownContent from "./markdownContent";
+
+export default function App() {
+  const [text, setText] = useState(markdownContent);
+  const [time, setTime] = useState(Date.now());
+  const [theme, setTheme] = useState("green");
+
+  useEffect(() => {
+    const interval = setInterval(() => {
+      setTime(Date.now());
+    }, 1000);
+    return () => clearInterval(interval);
+  }, []);
+
+  const options = { text, theme };
+  const render = (text) => marked.parse(text);
+
+  return (
+    <div className="app">
+      <h1>Performance with React</h1>
+      <h2>Current Time: {time}</h2>
+      <label htmlFor={"theme"}>
+        Choose a theme:
+        <select value={theme} onChange={(e) => setTheme(e.target.value)}>
+          <option value="green">Green</option>
+          <option value="blue">Blue</option>
+          <option value="red">Red</option>
+          <option value="yellow">Yellow</option>
+        </select>
+      </label>
+      <div className="markdown">
+        <textarea
+          className="markdown-editor"
+          value={text}
+          onChange={(e) => setText(e.target.value)}
+        ></textarea>
+        <MarkdownPreview options={options} render={render} />
+      </div>
+    </div>
+  );
+}
+```
+
+Alright, go play with it now (you may need to mess with the JANK_DELAY as well as the interval of how often the interval runs). The scroll is probably either janky or it has a hard time re-rendering. Typing in it should hard as well. Also notice that the current render. Re-rendering the theme is tough too.
+
+So how can we fix at least the scroll portion, as well make the other two a little less painful (as they'll only re-renderingo once as opposed to continually.)
+
+[xss]: https://owasp.org/www-community/attacks/xss/

lessons/05-performance-optimizations/C-fixing-it.md

@@ -0,0 +1,50 @@
+When does a componet re-render? It re-renders when its parents have changed, always. But what if we could say "only re-render when your props have changed"? Frankly that's most components, but this is an opt-in pattern for React. Generally, like we said, renders are so cheap that introducing this "memoization" layer just makes it harder to debug. But in this case we need some help, so let's do it!
+
+In MarkdownPreview.jsx
+
+```javascript
+// at top
+import { memo } from "react";
+
+// wrap function
+export default memo(function MarkdownPreview({ render, options }) {
+  // code
+});
+```
+
+Now we've told React "only re-render this when the props haven't changed. But it's still re-rendering? Why?
+
+Well, answer me two questions
+
+```javascript
+const objectA = {};
+const objectB = {};
+
+console.log(objectA === objectB); // is this true or false?
+
+const functionA = function () {};
+const functionB = function () {};
+
+console.log(functionA === functionB); // is this true or false?
+```
+
+If you run this, what will be the two logs? Go ahead and try it. Copy and paste it into your console.
+
+Did you get two `false`? It's because despite being equivalent in terms of what we've instantiated them with, they are two separate entities. They're two different pointers, if you're familiar with C++ or other languages.
+
+So with our example, despite our functions and objects being constructed equivalently like in our little example here, they're considered **not equal** when React compares them.
+
+Well, damn, okay, how do we deal with that? useCallback and useMemo. Let's go do it in our app.
+
+```javascript
+// at top
+import { useState, useCallback, useMemo } from "react";
+
+// replace our options and render
+const render = useCallback((text) => marked.parse(text), []);
+const options = useMemo(() => ({ text, theme }), [text, theme]);
+```
+
+- There you go! Now it should be rendering and only re-rendering when needed! 🎉
+- Now it gives _the same_ options and _the same_ render each render so the `===` comparison will be true.
+- The array following it works just like useEffect - it's essentially the cache key. If one of those things changes in the array, it invalidates the memo/callback and makes it render again.

lessons/05-performance-optimizations/D-other-perf-questions.md

@@ -0,0 +1,30 @@
+## useMemo vs useCallback
+
+What's the difference between useCallback and useMemo? Not much. You could actually rewrite our code to look like this and it'd be equivalent.
+
+```javascript
+// render and render2 are functionally equivalent
+const render = useMemo(() => (text) => marked.parse(text), []);
+const render2 = useCallback((text) => marked.parse(text), []);
+```
+
+Notice there's an extra `() => [fn]`. useCallback is only a thin wrapper on useMemo that automatically wraps it in the additional function. It's otherwise 100% equivalent.
+
+## What about strings and numbers?
+
+If you're just passing in strings and numbers to a `memo`ized function, you don't need useMemo or useCallback since those will just pass the `===` test already. It's just objects and functions! So instead of having options as an object, we could have had theme and text as top level props and we could have skipped using useMemo!
+
+That's it! While you should use these tools sparingly, they're handy when you do need them. They let you create a better performance profile when it's important.
+
+## Don't just use memo all the time 🙏
+
+As your potential future coworker, please please please don't just use memo on every function. I know it sounds like a good idea but let me tell you why. When you memoize something, it doesn't re-render when its props haven't changed. You're correct in thinking that is normally true of most components. However I **guarantee** you will start getting bugs of a component not re-rendering when you expect it to, and that is a hard bug to find if it's an errant memo somewhere in your codebase (spoken by someone who has had to debug this.) Just don't do it.
+
+## React Compiler
+
+We talk a bit about [React Compiler][compiler] in the intro course, but let's mention it again here. The function of React Compiler is to examine your code and determine what components could be memoized without causing unexpected behavior. So just what I told you not to do? React is actually going to do this for you free. It's still in a rough alpha but they're encouraging people to try it out.
+
+[See my Intro lesson on it][intro].
+
+[compiler]: https://react.dev/learn/react-compiler
+[intro]: https://react-v9.holt.courses/lessons/whats-next/react-compiler