From 5b40443a6cb654fc6fe8354ec968b5f0e2feff3a Mon Sep 17 00:00:00 2001 From: Thomas Hintz Date: Thu, 8 Oct 2020 15:54:12 -0700 Subject: [PATCH] Removing inline code from titles. --- high-performance-react.org | 8 ++++---- manuscript/fundamentals--building-our-own-react.markua | 4 ++-- manuscript/rendering-model.markua | 4 ++-- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/high-performance-react.org b/high-performance-react.org index 31040c9..804732e 100644 --- a/high-performance-react.org +++ b/high-performance-react.org @@ -154,7 +154,7 @@ complete picture of the entire process. The more black-boxes we have in our mental model the harder it will be for us to diagnose performance problems. -** Markup in JavaScript: ~JSX~ +** Markup in JavaScript: JSX ~createElement~, however, takes as input something that is probably not familiar to us since we usually work in JSX, which is the last @@ -274,7 +274,7 @@ by leaving those aspects of the JSX compiler out. So now that we've worked through JSX we're ready to tackle ~createElement~, the next item on our way to building our own React. -** Getting Ready to Render with ~createElement~ +** Getting Ready to Render with createElement React's ~render~ expects to consume a tree of element objects in a specific, uniform format. ~createElement~ is the method by which we @@ -853,7 +853,7 @@ React API itself, then we will extend our React implementation from chapter one to support the same API. Then we will discuss its usage and analyze when and how to use it. -** ~React.memo~ +** React.memo The first API React provides that we will look at is ~React.memo~. ~React.memo~ is a higher-order component (HOC) that @@ -896,7 +896,7 @@ using ~areEqual?~ because it can suffer from the same problem that -** ~React.PureComponent~ +** React.PureComponent ~React.PureComponent~ is very similar to ~React.memo~, but for class based components. Like ~React.memo~, ~React.PureComponent~ memoizes diff --git a/manuscript/fundamentals--building-our-own-react.markua b/manuscript/fundamentals--building-our-own-react.markua index b20d4c5..e50ba30 100644 --- a/manuscript/fundamentals--building-our-own-react.markua +++ b/manuscript/fundamentals--building-our-own-react.markua @@ -20,7 +20,7 @@ But what does that actually look like? If your app is janky does that explanatio React is centered around the `render` method. The `render` method is what walks our trees, diffs them with the browser's DOM tree, and updates the DOM as needed. But before we can look at the `render` method we have to understand its input. The input comes from `createElement`. While `createElement` itself is unlikely to be a bottleneck it's good to understand how it works so that we can have a complete picture of the entire process. The more black-boxes we have in our mental model the harder it will be for us to diagnose performance problems. -## Markup in JavaScript: `JSX` +## Markup in JavaScript: JSX `createElement`, however, takes as input something that is probably not familiar to us since we usually work in JSX, which is the last element of the chain in this puzzle and the first step in solving it. While not strictly a part of React, it is almost universally used with it. And if we understand it then `createElement` will be less of a mystery since we will be able to connect all the dots. @@ -87,7 +87,7 @@ As you can see, it is very similar to our JSM data-structure and for the purpose So now that we've worked through JSX we're ready to tackle `createElement`, the next item on our way to building our own React. -## Getting Ready to Render with `createElement` +## Getting Ready to Render with createElement React's `render` expects to consume a tree of element objects in a specific, uniform format. `createElement` is the method by which we achieve that objective. `createElement` will take as input JSM and output a tree of objects compatible with `render`. diff --git a/manuscript/rendering-model.markua b/manuscript/rendering-model.markua index 6f20522..89d8fb1 100644 --- a/manuscript/rendering-model.markua +++ b/manuscript/rendering-model.markua @@ -28,7 +28,7 @@ This is indeed such a common bottleneck and solution that React provides an API We will learn about this API by first looking at the signatures of the React API itself, then we will extend our React implementation from chapter one to support the same API. Then we will discuss its usage and analyze when and how to use it. -## `React.memo` +## React.memo The first API React provides that we will look at is `React.memo`. `React.memo` is a higher-order component (HOC) that wraps your functional component. It handles partially memoizing your component based on its props (not state). If your component contains `useState` or `useContext` hooks it will re-render when the state or context changes. @@ -45,7 +45,7 @@ It takes two arguments, one required and one optional. The required argument is If the second argument is not specified then React performs a *shallow* comparison between props it has received in the past and the current props. If the current props match props that have been passed to your component before, React will use the output stored from that previous render instead of rendering your component again. If you want more control over the prop comparison, like if you wanted to deeply compare some props, you would pass in your own `areEqual?`. However, it's generally recommended to program in a more pure style instead of using `areEqual?` because it can suffer from the same problem that `shouldComponentUpdate` did. -## `React.PureComponent` +## React.PureComponent `React.PureComponent` is very similar to `React.memo`, but for class based components. Like `React.memo`, `React.PureComponent` memoizes the component based on a shallow comparison of its props and state.