From 5f332483ec1ac98b2ce549e0e21410cedd28a0a7 Mon Sep 17 00:00:00 2001 From: Kevin Barabash Date: Fri, 28 Jun 2024 13:35:57 -0400 Subject: [PATCH] fix inline code --- src/react-render-perf/lesson-01/content.mdx | 24 ++++++++++----------- src/react-render-perf/lesson-02/content.mdx | 20 ++++++++--------- src/react-render-perf/lesson-03/content.mdx | 6 +++--- src/react-render-perf/lesson-04/content.mdx | 14 ++++++------ 4 files changed, 32 insertions(+), 32 deletions(-) diff --git a/src/react-render-perf/lesson-01/content.mdx b/src/react-render-perf/lesson-01/content.mdx index ba9defe..e544374 100644 --- a/src/react-render-perf/lesson-01/content.mdx +++ b/src/react-render-perf/lesson-01/content.mdx @@ -1,5 +1,5 @@ Memoization can be used to avoid unnecessary renders. This is most useful when -the component itself is expensive to render (e.g. the `MathJax` component in +the component itself is expensive to render (e.g. the MathJax component in webapp) or it renders a lot of descedent components. Memoization works by saving the rendered output of the component based on the @@ -11,11 +11,11 @@ same implementation are considered differen objects. In order for memoization to have the desired benefit, we don't want the component to rerender if there are only superficial changes to props. -`React.memo(Component, arePropsEqual?)` by default does a shallow comparison of +React.memo(Component, arePropsEqual?) by default does a shallow comparison of props and as such isn't able to determine when a prop that's an object or function -is the same or not. We can pass a custom `arePropsEqual` function to override +is the same or not. We can pass a custom arePropsEqual function to override that behavior. To keep things simple we use a third-party library called -`react-fast-compare` which provides a function that does a deep comparison of +react-fast-compare which provides a function that does a deep comparison of objects. ```ts @@ -34,7 +34,7 @@ export default React.memo(ChildComponent, arePropsEqual); ``` There is a bit of a gotcha here when it comes to props that are functions. -`react-fast-compare` cannot check if two functions are the same. Imagine the +react-fast-compare cannot check if two functions are the same. Imagine the following scenario: ```ts @@ -57,10 +57,10 @@ const ParentComponent = (props: Props) => { } ``` -Each time `ParentComponent` renders, a new copy of `handleClick` will be created -even if the `result` from `useQuery` isn't ready yet. We only want this function -to treated as a new function when `result` changes. React provides a hook called -`useCallback` which does exactly that by memoizing the function. +Each time ParentComponent renders, a new copy of handleClick will be created +even if the result from useQuery isn't ready yet. We only want this function +to treated as a new function when result changes. React provides a hook called +useCallback which does exactly that by memoizing the function. ```ts import ChildComponent from "./my-component"; @@ -82,10 +82,10 @@ const ParentComponent = (props: Props) => { } ``` -If the `ParentComponent` is a class-based component, there is no need to memoize +If the ParentComponent is a class-based component, there is no need to memoize function props that are pre-bound methods. This is because the method never changes for the component instance. If the prop is an inline function though, e.g. -`onClick={() => { ... }}` it should be converted to a pre-bound method, see the +onClick=\{() => \{ ... \}\} it should be converted to a pre-bound method, see the example below. ```ts @@ -131,5 +131,5 @@ what to memoize. ## Exercise 1. Use the profiler in React dev tools to measure the render performance of the code in the "exercise" folder. -2. Update the code in the "exercise" folder memoize the `Child` component to avoid rerender this component. +2. Update the code in the "exercise" folder memoize the Child component to avoid rerender this component. 3. Use the profiler in React dev tools to measure the render performance again diff --git a/src/react-render-perf/lesson-02/content.mdx b/src/react-render-perf/lesson-02/content.mdx index 6662afd..6c17337 100644 --- a/src/react-render-perf/lesson-02/content.mdx +++ b/src/react-render-perf/lesson-02/content.mdx @@ -7,7 +7,7 @@ In order to avoid re-rendering all of the descendents we'd like only those components using the context to re-render. Ideally, they should only re-render if the data that they're making use of changes. -In the following example, everytime we update the `value` in the context, we +In the following example, everytime we update the value in the context, we re-render both child components of the context even though only one of them needs to be updated. @@ -47,13 +47,13 @@ const Parent = () => { ``` To avoid this problem we can replace the plain old JavaScript object being -used for the context's `value` with a event emitter instance. The instance is -only created once and is never replaced so the `value` never changes which +used for the context's value with a event emitter instance. The instance is +only created once and is never replaced so the value never changes which means that the context will never trigger a re-render. The child components will register event listeners for changes to only the data they care about. The parent component will emit the appropriate event when -increment the values for `foo` and `bar`. +increment the values for foo and bar. ```tsx import {createContext, useContext, useState, useMemo} from "react"; @@ -102,10 +102,10 @@ const Parent = () => { }; ``` -This is necessary but not sufficient to prevent both `Foo` and `Bar` from -re-rendering when either `foo` or `bar` is incremented. That's because -`Parent` is re-rendering when its state changes. To avoid this issue we also -need to memoize `Foo` and `Bar` themselves. Thankfully they don't take any +This is necessary but not sufficient to prevent both Foo and Bar from +re-rendering when either foo or bar is incremented. That's because +Parent is re-rendering when its state changes. To avoid this issue we also +need to memoize Foo and Bar themselves. Thankfully they don't take any props so this is trivial to do. ```tsx @@ -133,7 +133,7 @@ const Bar = memo(() => { 1. Use the profiler in React dev tools to measure the render performance of the code in the "exercise" folder. -2. Update the code in the "exercise" folder to use an `EventEmitter` to prevent -the `value` in the context provider from changing. +2. Update the code in the "exercise" folder to use an EventEmitter to prevent +the value in the context provider from changing. 3. Memoize only the necessary components to prevent unecessary re-renders. 4. Use the profiler in React dev tools to measure the render performance again. diff --git a/src/react-render-perf/lesson-03/content.mdx b/src/react-render-perf/lesson-03/content.mdx index 34ac1d4..b018150 100644 --- a/src/react-render-perf/lesson-03/content.mdx +++ b/src/react-render-perf/lesson-03/content.mdx @@ -18,7 +18,7 @@ benefits over React Context: ## Example Using our example from [Lesson 2](/react-render-perf/lesson-02) we can replace the context -by creating an `EventEmitter` singleton and using it directly in our components. +by creating an EventEmitter singleton and using it directly in our components. ```tsx import {createContext, useContext, useState, useMemo} from "react"; @@ -68,10 +68,10 @@ const Parent = () => { While singletons are sometimes frowned upon because they can make testing more difficult in some languages, that isn't the case in JavaScript. It's easy to mock -the singleton using `jest` if follow these guidelines: +the singleton using jest if follow these guidelines: - Export the singleton from its own file. -- If you have a custom class instead of using `EventEmitter` be sure to export +- If you have a custom class instead of using EventEmitter be sure to export that as well so that you can use it when mocking the singleton. ## Exercise diff --git a/src/react-render-perf/lesson-04/content.mdx b/src/react-render-perf/lesson-04/content.mdx index 853f544..fafb60c 100644 --- a/src/react-render-perf/lesson-04/content.mdx +++ b/src/react-render-perf/lesson-04/content.mdx @@ -19,7 +19,7 @@ prevent them from re-rendering in response to props changes. ## Example -Consider `LargeComponent` below. Clicking on either of the buttons will cause +Consider LargeComponent below. Clicking on either of the buttons will cause the whole component to re-render. ```tsx @@ -55,7 +55,7 @@ const LargeComponent = () => { } ``` -Extracting components `Foo` and `Bar` allows those components to update and +Extracting components Foo and Bar allows those components to update and re-render indepedently of each other. ```tsx @@ -104,7 +104,7 @@ const ParentComponent = () => { ## Notes -- If there are still other things left in the `ParentComponent` that could +- If there are still other things left in the ParentComponent that could trigger a re-render, you may want to memoize some or all of the children components. - Splitting up components has the added benefit of making the components easier to test. You can even mock the child components when testing the parent component. @@ -113,7 +113,7 @@ const ParentComponent = () => { 1. Use the profiler in React dev tools to measure the render performance of the code in the "exercise" folder. -2. Split `LargeComponent` in the exercise/ folder into a `Parent` component and +2. Split LargeComponent in the exercise/ folder into a Parent component and multiple child components. 3. Memoize components as necessary to address remaining render performance issues. 4. Use the profiler in React dev tools to measure the render performance again. @@ -122,8 +122,8 @@ const ParentComponent = () => { The following pattern can be quite useful when writing jest tests for large components that render a number of subcomponents. The subcomponents can be mocked with module -mocks to return simple strings that are easy to find using `@testing-library/react`'s -`screen.findByText()`. +mocks to return simple strings that are easy to find using @testing-library/react's +screen.findByText(). ```ts import {render, screen} from "@testing-library/react"; @@ -169,4 +169,4 @@ describe("Parent", () => { }); ``` -NOTE: The extra `{}` in the call to `toHaveBeenCalledWith` is necessary. +NOTE: The extra {} in the call to toHaveBeenCalledWith is necessary.