From 1c1ad8059664736620af1a934b1cca721c7c051d Mon Sep 17 00:00:00 2001
From: zqran <uuxnet@gmail.com>
Date: Thu, 8 Sep 2022 04:36:05 +0800
Subject: [PATCH] [Beta] Change the position of the comma (#5007)

* [Beta] Change the position of the comma

* [Beta] Change the position of the comma

* [Beta] Change the Learn Doc

* [Beta] Change the Learn Doc
---
 beta/src/content/index.md                      |  2 +-
 .../content/learn/add-react-to-a-website.md    | 14 +++++++-------
 .../learn/choosing-the-state-structure.md      |  2 +-
 .../src/content/learn/conditional-rendering.md |  2 +-
 .../extracting-state-logic-into-a-reducer.md   |  2 +-
 .../importing-and-exporting-components.md      | 10 +++++-----
 .../content/learn/keeping-components-pure.md   |  2 +-
 .../learn/lifecycle-of-reactive-effects.md     |  2 +-
 .../learn/manipulating-the-dom-with-refs.md    |  2 +-
 .../learn/passing-data-deeply-with-context.md  |  2 +-
 .../learn/preserving-and-resetting-state.md    |  2 +-
 .../queueing-a-series-of-state-updates.md      |  4 ++--
 .../src/content/learn/react-developer-tools.md |  2 +-
 .../learn/reacting-to-input-with-state.md      | 18 +++++++++---------
 beta/src/content/learn/rendering-lists.md      |  2 +-
 beta/src/content/learn/responding-to-events.md |  2 +-
 .../learn/sharing-state-between-components.md  |  2 +-
 .../content/learn/start-a-new-react-project.md |  2 +-
 .../content/learn/state-a-components-memory.md |  4 ++--
 .../learn/synchronizing-with-effects.md        |  2 +-
 beta/src/content/learn/thinking-in-react.md    |  2 +-
 .../content/learn/updating-arrays-in-state.md  |  6 +++---
 .../content/learn/writing-markup-with-jsx.md   |  2 +-
 beta/src/content/learn/your-first-component.md |  2 +-
 24 files changed, 46 insertions(+), 46 deletions(-)

diff --git a/beta/src/content/index.md b/beta/src/content/index.md
index c779db5f..bc72d3bf 100644
--- a/beta/src/content/index.md
+++ b/beta/src/content/index.md
@@ -18,7 +18,7 @@ This beta website contains the current draft of the new docs.
 
 ## This is a work in progress! {/*this-is-a-work-in-progress*/}
 
-This is a **beta website**. There will be bugs, performance issues, and missing content.
+This is a **beta website.** There will be bugs, performance issues, and missing content.
 
 ## How much content is ready? {/*how-much-content-is-ready*/}
 
diff --git a/beta/src/content/learn/add-react-to-a-website.md b/beta/src/content/learn/add-react-to-a-website.md
index 635f5d83..3a5aca59 100644
--- a/beta/src/content/learn/add-react-to-a-website.md
+++ b/beta/src/content/learn/add-react-to-a-website.md
@@ -89,7 +89,7 @@ function LikeButton() {
 
 ### Step 4: Add your React component to the page {/*step-4-add-your-react-component-to-the-page*/}
 
-Lastly, add three lines to the bottom of **`like-button.js`**. These lines of code find the `<div>` you added to the HTML in the first step, create a React root, and then display the "Like" button React component inside of it:
+Lastly, add three lines to the bottom of **`like-button.js`.** These lines of code find the `<div>` you added to the HTML in the first step, create a React root, and then display the "Like" button React component inside of it:
 
 ```js
 const rootNode = document.getElementById('like-button-root');
@@ -106,8 +106,8 @@ root.render(React.createElement(LikeButton));
 
 You might want to display React components in multiple places on the same HTML page. This is useful if React-powered parts of your page are separate from each other. You can do this by putting multiple root tags in your HTML and then rendering React components inside each of them with `ReactDOM.createRoot()`. For example:
 
-1. In **`index.html`**, add an additional container element `<div id="another-root"></div>`.
-2. In **`like-button.js`**, add three more lines at the end:
+1. In **`index.html`,** add an additional container element `<div id="another-root"></div>`.
+2. In **`like-button.js`,** add three more lines at the end:
 
 ```js {6,7,8,9}
 const anotherRootNode = document.getElementById('another-root');
@@ -149,7 +149,7 @@ These two code snippets are equivalent. JSX is popular syntax for describing mar
 
 ### Try JSX {/*try-jsx*/}
 
-The quickest way to try JSX is to add the Babel compiler as a `<script>` tag to the page. Put it before **`like-button.js`**, and then add `type="text/babel"` attribute to the `<script>` tag for **`like-button.js`**:
+The quickest way to try JSX is to add the Babel compiler as a `<script>` tag to the page. Put it before **`like-button.js`,** and then add `type="text/babel"` attribute to the `<script>` tag for **`like-button.js`**:
 
 ```html {3,4}
   <script src="https://unpkg.com/react@18/umd/react.production.min.js" crossorigin></script>
@@ -185,7 +185,7 @@ It may feel a bit unusual at first to mix JS with markup, but it will grow on yo
 
 <Gotcha>
 
-The Babel `<script>` compiler is fine for learning and creating simple demos. However, **it makes your website slow and isn't suitable for production**. When you're ready to move forward, remove the Babel `<script>` tag and remove the `type="text/babel"` attribute you've added in this step. Instead, in the next section you will set up a JSX preprocessor to convert all your `<script>` tags from JSX to JS.
+The Babel `<script>` compiler is fine for learning and creating simple demos. However, **it makes your website slow and isn't suitable for production.** When you're ready to move forward, remove the Babel `<script>` tag and remove the `type="text/babel"` attribute you've added in this step. Instead, in the next section you will set up a JSX preprocessor to convert all your `<script>` tags from JSX to JS.
 
 </Gotcha>
 
@@ -206,7 +206,7 @@ Congratulations! You just added a **production-ready JSX setup** to your project
 
 You can preprocess JSX so that every time you save a file with JSX in it, the transform will be re-run, converting the JSX file into a new, plain JavaScript file that the browser can understand. Here's how to set this up:
 
-1. Create a folder called **`src`**.
+1. Create a folder called **`src`.**
 2. In your terminal, run this command: `npx babel --watch src --out-dir . --presets react-app/prod ` (Don't wait for it to finish! This command starts an automated watcher for edits to JSX inside `src`.)
 3. Move your JSX-ified **`like-button.js`** ([it should look like this!](https://gist.githubusercontent.com/gaearon/1884acf8834f1ef9a574a953f77ed4d8/raw/dfc664bbd25992c5278c3bf3d8504424c1104ecf/like-button.js)) to the new **`src`** folder.
 
@@ -257,7 +257,7 @@ It accepts several arguments: `React.createElement(component, props, ...children
 
 Here's how they work:
 
-1. A **component**, which can be a string representing an HTML element or a function component
+1. A **component,** which can be a string representing an HTML element or a function component
 2. An object of any [**props** you want to pass](/learn/passing-props-to-a-component)
 3. The rest are **children** the component might have, such as text strings or other elements
 
diff --git a/beta/src/content/learn/choosing-the-state-structure.md b/beta/src/content/learn/choosing-the-state-structure.md
index 25e1499b..be6cf802 100644
--- a/beta/src/content/learn/choosing-the-state-structure.md
+++ b/beta/src/content/learn/choosing-the-state-structure.md
@@ -47,7 +47,7 @@ Or this?
 const [position, setPosition] = useState({ x: 0, y: 0 });
 ```
 
-Technically, you can use either of these approaches. But **if some two state variables always change together, it might be a good idea to unify them into a single state variable**. Then you won't forget to always keep them in sync, like in this example where moving the cursor updates both coordinates of the red dot:
+Technically, you can use either of these approaches. But **if some two state variables always change together, it might be a good idea to unify them into a single state variable.** Then you won't forget to always keep them in sync, like in this example where moving the cursor updates both coordinates of the red dot:
 
 <Sandpack>
 
diff --git a/beta/src/content/learn/conditional-rendering.md b/beta/src/content/learn/conditional-rendering.md
index 5ac81bff..cb4c4da1 100644
--- a/beta/src/content/learn/conditional-rendering.md
+++ b/beta/src/content/learn/conditional-rendering.md
@@ -63,7 +63,7 @@ if (isPacked) {
 return <li className="item">{name}</li>;
 ```
 
-If the `isPacked` prop is `true`, this code **returns a different JSX tree**. With this change, some of the items get a checkmark at the end:
+If the `isPacked` prop is `true`, this code **returns a different JSX tree.** With this change, some of the items get a checkmark at the end:
 
 <Sandpack>
 
diff --git a/beta/src/content/learn/extracting-state-logic-into-a-reducer.md b/beta/src/content/learn/extracting-state-logic-into-a-reducer.md
index 60728aae..1a470ba8 100644
--- a/beta/src/content/learn/extracting-state-logic-into-a-reducer.md
+++ b/beta/src/content/learn/extracting-state-logic-into-a-reducer.md
@@ -180,7 +180,7 @@ ul, li { margin: 0; padding: 0; }
 
 </Sandpack>
 
-Each of its event handlers calls `setTasks` in order to update the state. As this component grows, so does the amount of state logic sprinkled throughout it. To reduce this complexity and keep all your logic in one easy-to-access place, you can move that state logic into a single function outside your component, **called a "reducer"**.
+Each of its event handlers calls `setTasks` in order to update the state. As this component grows, so does the amount of state logic sprinkled throughout it. To reduce this complexity and keep all your logic in one easy-to-access place, you can move that state logic into a single function outside your component, **called a "reducer".**
 
 Reducers are a different way to handle state. You can migrate from `useState` to `useReducer` in three steps:
 
diff --git a/beta/src/content/learn/importing-and-exporting-components.md b/beta/src/content/learn/importing-and-exporting-components.md
index ef2c69d8..a839a264 100644
--- a/beta/src/content/learn/importing-and-exporting-components.md
+++ b/beta/src/content/learn/importing-and-exporting-components.md
@@ -108,10 +108,10 @@ Notice how this example is broken down into two component files now:
 
 1. `Gallery.js`:
      - Defines the `Profile` component which is only used within the same file and is not exported.
-     - Exports the `Gallery` component as a **default export**.
+     - Exports the `Gallery` component as a **default export.**
 2. `App.js`:
      - Imports `Gallery` as a **default import** from `Gallery.js`.
-     - Exports the root `App` component as a **default export**.
+     - Exports the root `App` component as a **default export.**
 
 
 <Note>
@@ -219,12 +219,12 @@ img { margin: 0 10px 10px 0; height: 90px; }
 Now you're using a mix of default and named exports:
 
 * `Gallery.js`:
-  - Exports the `Profile` component as a **named export called `Profile`**.
-  - Exports the `Gallery` component as a **default export**.
+  - Exports the `Profile` component as a **named export called `Profile`.**
+  - Exports the `Gallery` component as a **default export.**
 * `App.js`:
   - Imports `Profile` as a **named import called `Profile`** from `Gallery.js`.
   - Imports `Gallery` as a **default import** from `Gallery.js`.
-  - Exports the root `App` component as a **default export**.
+  - Exports the root `App` component as a **default export.**
 
 <Recap>
 
diff --git a/beta/src/content/learn/keeping-components-pure.md b/beta/src/content/learn/keeping-components-pure.md
index 6d6d60ac..b4de4f72 100644
--- a/beta/src/content/learn/keeping-components-pure.md
+++ b/beta/src/content/learn/keeping-components-pure.md
@@ -189,7 +189,7 @@ However, it's fine because you've created them *during the same render*, inside
 
 ## Where you _can_ cause side effects {/*where-you-_can_-cause-side-effects*/}
 
-While functional programming relies heavily on purity, at some point, somewhere, _something_ has to change. That's kind of the point of programming! These changes—updating the screen, starting an animation, changing the data—are called **side effects**. They're things that happen _"on the side"_, not during rendering.
+While functional programming relies heavily on purity, at some point, somewhere, _something_ has to change. That's kind of the point of programming! These changes—updating the screen, starting an animation, changing the data—are called **side effects.** They're things that happen _"on the side"_, not during rendering.
 
 In React, **side effects usually belong inside [event handlers](/learn/responding-to-events).** Event handlers are functions that React runs when you perform some action—for example, when you click a button. Even though event handlers are defined *inside* your component, they don't run *during* rendering! **So event handlers don't need to be pure.**
 
diff --git a/beta/src/content/learn/lifecycle-of-reactive-effects.md b/beta/src/content/learn/lifecycle-of-reactive-effects.md
index 1de578d3..b0636cba 100644
--- a/beta/src/content/learn/lifecycle-of-reactive-effects.md
+++ b/beta/src/content/learn/lifecycle-of-reactive-effects.md
@@ -95,7 +95,7 @@ function ChatRoom({ roomId /* "general" */ }) {
 }
 ```
 
-After the UI is displayed, React will run your Effect to **start synchronizing**. It connects to the `"general"` room:
+After the UI is displayed, React will run your Effect to **start synchronizing.** It connects to the `"general"` room:
 
 ```js {3,4}
 function ChatRoom({ roomId /* "general" */ }) {
diff --git a/beta/src/content/learn/manipulating-the-dom-with-refs.md b/beta/src/content/learn/manipulating-the-dom-with-refs.md
index 075e7bad..19e0b30a 100644
--- a/beta/src/content/learn/manipulating-the-dom-with-refs.md
+++ b/beta/src/content/learn/manipulating-the-dom-with-refs.md
@@ -209,7 +209,7 @@ This is because **Hooks must only be called at the top-level of your component.*
 
 One possible way around this is to get a single ref to their parent element, and then use DOM manipulation methods like [`querySelectorAll`](https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelectorAll) to "find" the individual child nodes from it. However, this is brittle and can break if your DOM structure changes.
 
-Another solution is to **pass a function to the `ref` attribute**. This is called a "ref callback". React will call your ref callback with the DOM node when it's time to set the ref, and with `null` when it's time to clear it. This lets you maintain your own array or a [Map](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map), and access any ref by its index or some kind of ID.
+Another solution is to **pass a function to the `ref` attribute.** This is called a "ref callback". React will call your ref callback with the DOM node when it's time to set the ref, and with `null` when it's time to clear it. This lets you maintain your own array or a [Map](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map), and access any ref by its index or some kind of ID.
 
 This example shows how you can use this approach to scroll to an arbitrary node in a long list:
 
diff --git a/beta/src/content/learn/passing-data-deeply-with-context.md b/beta/src/content/learn/passing-data-deeply-with-context.md
index 7af26970..b3f2c1dc 100644
--- a/beta/src/content/learn/passing-data-deeply-with-context.md
+++ b/beta/src/content/learn/passing-data-deeply-with-context.md
@@ -834,7 +834,7 @@ You didn't do anything special for this to work. A `Section` specifies the conte
 
 How context works might remind you of [CSS property inheritance](https://developer.mozilla.org/en-US/docs/Web/CSS/inheritance). In CSS, you can specify `color: blue` for a `<div>`, and any DOM node inside of it, no matter how deep, will inherit that color unless some other DOM node in the middle overrides it with `color: green`. Similarly, in React, the only way to override some context coming from above is to wrap children into a context provider with a different value.
 
-In CSS, different properties like `color` and `background-color` don't override each other. You can set all  `<div>`'s `color` to red without impacting `background-color`. Similarly, **different React contexts don't override each other**. Each context that you make with `createContext()` is completely separate from other ones, and ties together components using and providing *that particular* context. One component may use or provide many different contexts without a problem.
+In CSS, different properties like `color` and `background-color` don't override each other. You can set all  `<div>`'s `color` to red without impacting `background-color`. Similarly, **different React contexts don't override each other.** Each context that you make with `createContext()` is completely separate from other ones, and ties together components using and providing *that particular* context. One component may use or provide many different contexts without a problem.
 
 ## Before you use context {/*before-you-use-context*/}
 
diff --git a/beta/src/content/learn/preserving-and-resetting-state.md b/beta/src/content/learn/preserving-and-resetting-state.md
index 69f6700f..d3847f61 100644
--- a/beta/src/content/learn/preserving-and-resetting-state.md
+++ b/beta/src/content/learn/preserving-and-resetting-state.md
@@ -599,7 +599,7 @@ When switching back, the `p` is deleted and the `Counter` is added
 
 </DiagramGroup>
 
-Also, **when you render a different component in the same position, it resets the state of its entire subtree**. To see how this works, increment the counter and then tick the checkbox:
+Also, **when you render a different component in the same position, it resets the state of its entire subtree.** To see how this works, increment the counter and then tick the checkbox:
 
 <Sandpack>
 
diff --git a/beta/src/content/learn/queueing-a-series-of-state-updates.md b/beta/src/content/learn/queueing-a-series-of-state-updates.md
index 1392ba8e..3190c93d 100644
--- a/beta/src/content/learn/queueing-a-series-of-state-updates.md
+++ b/beta/src/content/learn/queueing-a-series-of-state-updates.md
@@ -99,7 +99,7 @@ h1 { display: inline-block; margin: 10px; width: 30px; text-align: center; }
 
 </Sandpack>
 
-Here, `n => n + 1` is called an **updater function**. When you pass it to a state setter:
+Here, `n => n + 1` is called an **updater function.** When you pass it to a state setter:
 
 1. React queues this function to be processed after all the other code in the event handler has run.
 2. During the next render, React goes through the queue and gives you the final updated state.
@@ -368,7 +368,7 @@ This ensures that when you increment or decrement a counter, you do it in relati
 
 In this challenge, you will reimplement a tiny part of React from scratch! It's not as hard as it sounds.
 
-Scroll through the sandbox preview. Notice that it shows **four test cases**. They correspond to the examples you've seen earlier on this page. Your task is to implement the `getFinalState` function so that it returns the correct result for each of those cases. If you implement it correctly, all four tests should pass.
+Scroll through the sandbox preview. Notice that it shows **four test cases.** They correspond to the examples you've seen earlier on this page. Your task is to implement the `getFinalState` function so that it returns the correct result for each of those cases. If you implement it correctly, all four tests should pass.
 
 You will receive two arguments: `baseState` is the initial state (like `0`), and the `queue` is an array which contains a mix of numbers (like `5`) and updater functions (like `n => n + 1`) in the order they were added.
 
diff --git a/beta/src/content/learn/react-developer-tools.md b/beta/src/content/learn/react-developer-tools.md
index 6dd9142f..89208a6b 100644
--- a/beta/src/content/learn/react-developer-tools.md
+++ b/beta/src/content/learn/react-developer-tools.md
@@ -22,7 +22,7 @@ The easiest way to debug websites built with React is to install the React Devel
 * [Install for **Firefox**](https://addons.mozilla.org/en-US/firefox/addon/react-devtools/)
 * [Install for **Edge**](https://microsoftedge.microsoft.com/addons/detail/react-developer-tools/gpphkfbcpidddadnkolkpfckpihlkkil)
 
-Now, if you visit a website **built with React**, you will see the _Components_ and _Profiler_ panels.
+Now, if you visit a website **built with React,** you will see the _Components_ and _Profiler_ panels.
 
 ![React Developer Tools extension](/images/docs/react-devtools-extension.png)
 
diff --git a/beta/src/content/learn/reacting-to-input-with-state.md b/beta/src/content/learn/reacting-to-input-with-state.md
index e2b0a2fa..924b4329 100644
--- a/beta/src/content/learn/reacting-to-input-with-state.md
+++ b/beta/src/content/learn/reacting-to-input-with-state.md
@@ -20,12 +20,12 @@ React uses a declarative way to manipulate the UI. Instead of manipulating indiv
 
 When you design UI interactions, you probably think about how the UI *changes* in response to user actions. Consider a form that lets the user submit an answer:
 
-* When you type something into a form, the "Submit" button **becomes enabled**.
-* When you press "Submit", both form and the button **become disabled**, and a spinner **appears**.
-* If the network request succeeds, the form **gets hidden**, and the "Thank you" message **appears**.
-* If the network request fails, an error message **appears**, and the form **becomes enabled** again.
+* When you type something into a form, the "Submit" button **becomes enabled.**
+* When you press "Submit", both form and the button **become disabled,** and a spinner **appears.**
+* If the network request succeeds, the form **gets hidden,** and the "Thank you" message **appears.**
+* If the network request fails, an error message **appears,** and the form **becomes enabled** again.
 
-In **imperative programming**, the above corresponds directly to how you implement interaction. You have to write the exact instructions to manipulate the UI depending on what just happened. Here's another way to think about this: imagine riding next to someone in a car and telling them turn by turn where to go.
+In **imperative programming,** the above corresponds directly to how you implement interaction. You have to write the exact instructions to manipulate the UI depending on what just happened. Here's another way to think about this: imagine riding next to someone in a car and telling them turn by turn where to go.
 
 <Illustration src="/images/docs/illustrations/i_imperative-ui-programming.png"  alt="In a car driven by an anxious-looking person representing JavaScript, a passenger orders the driver to execute a sequence of complicated turn by turn navigations." />
 
@@ -135,7 +135,7 @@ Manipulating the UI imperatively works well enough for isolated examples, but it
 
 React was built to solve this problem.
 
-In React, you don't directly manipulate the UI--meaning you don't enable, disable, show, or hide components directly. Instead, you **declare what you want to show**, and React figures out how to update the UI. Think of getting into a taxi and telling the driver where you want to go instead of telling them exactly where to turn. It's the driver's job to get you there, and they might even know some shortcuts you haven't considered!
+In React, you don't directly manipulate the UI--meaning you don't enable, disable, show, or hide components directly. Instead, you **declare what you want to show,** and React figures out how to update the UI. Think of getting into a taxi and telling the driver where you want to go instead of telling them exactly where to turn. It's the driver's job to get you there, and they might even know some shortcuts you haven't considered!
 
 <Illustration src="/images/docs/illustrations/i_declarative-ui-programming.png" alt="In a car driven by React, a passenger asks to be taken to a specific place on the map. React figures out how to do that." />
 
@@ -318,10 +318,10 @@ Pages like this are often called "living styleguides" or "storybooks."
 
 You can trigger state updates in response to two kinds of inputs:
 
-* **Human inputs**, like clicking a button, typing in a field, navigating a link.
+* **Human inputs,** like clicking a button, typing in a field, navigating a link.
 * **Computer inputs,** like a network response arriving, a timeout completing, an image loading.
 
-In both cases, **you must set [state variables](/learn/state-a-components-memory#anatomy-of-usestate) to update the UI**. For the form you're developing, you will need to change state in response to a few different inputs:
+In both cases, **you must set [state variables](/learn/state-a-components-memory#anatomy-of-usestate) to update the UI.** For the form you're developing, you will need to change state in response to a few different inputs:
 
 * **Changing the text input** (human) should switch it from the *Empty* state to the *Typing* state or back, depending on whether the text box is empty or not.
 * **Clicking the Submit button** (human) should switch it to the *Submitting* state.
@@ -344,7 +344,7 @@ Form states
 
 ### Step 3: Represent the state in memory with `useState` {/*step-3-represent-the-state-in-memory-with-usestate*/}
 
-Next you'll need to represent the visual states of your component in memory with [`useState`](/apis/react/useState). Simplicity is key: each piece of state is a "moving piece", and **you want as few "moving pieces" as possible**. More complexity leads to more bugs!
+Next you'll need to represent the visual states of your component in memory with [`useState`](/apis/react/useState). Simplicity is key: each piece of state is a "moving piece", and **you want as few "moving pieces" as possible.** More complexity leads to more bugs!
 
 Start with the state that *absolutely must* be there. For example, you'll need to store the `answer` for the input, and the `error` (if it exists) to store the last error:
 
diff --git a/beta/src/content/learn/rendering-lists.md b/beta/src/content/learn/rendering-lists.md
index a457ddb3..6a59bb72 100644
--- a/beta/src/content/learn/rendering-lists.md
+++ b/beta/src/content/learn/rendering-lists.md
@@ -432,7 +432,7 @@ On this page you learned:
 
 This example shows a list of all people.
 
-Change it to show two separate lists one after another: **Chemists** and **Everyone Else**. Like previously, you can determine whether a person is a chemist by checking if `person.profession === 'chemist'`.
+Change it to show two separate lists one after another: **Chemists** and **Everyone Else.** Like previously, you can determine whether a person is a chemist by checking if `person.profession === 'chemist'`.
 
 <Sandpack>
 
diff --git a/beta/src/content/learn/responding-to-events.md b/beta/src/content/learn/responding-to-events.md
index 8dccd352..5eb65ccc 100644
--- a/beta/src/content/learn/responding-to-events.md
+++ b/beta/src/content/learn/responding-to-events.md
@@ -62,7 +62,7 @@ button { margin-right: 10px; }
 
 </Sandpack>
 
-You defined the `handleClick` function and then [passed it as a prop](/learn/passing-props-to-a-component) to `<button>`.  `handleClick` is an **event handler**. Event handler functions:
+You defined the `handleClick` function and then [passed it as a prop](/learn/passing-props-to-a-component) to `<button>`.  `handleClick` is an **event handler.** Event handler functions:
 
 * Are usually defined *inside* your components.
 * Have names that start with `handle`, followed by the name of the event.
diff --git a/beta/src/content/learn/sharing-state-between-components.md b/beta/src/content/learn/sharing-state-between-components.md
index d3040ef7..c6857210 100644
--- a/beta/src/content/learn/sharing-state-between-components.md
+++ b/beta/src/content/learn/sharing-state-between-components.md
@@ -302,7 +302,7 @@ When writing a component, consider which information in it should be controlled
 
 In a React application, many components will have their own state. Some state may "live" close to the leaf components (components at the bottom of the tree) like inputs. Other state may "live" closer to the top of the app. For example, even client-side routing libraries are usually implemented by storing the current route in the React state, and passing it down by props!
 
-**For each unique piece of state, you will choose the component that "owns" it**. This principle is also known as having a ["single source of truth".](https://en.wikipedia.org/wiki/Single_source_of_truth) It doesn't mean that all state lives in one place--but that for _each_ piece of state, there is a _specific_ component that holds that piece of information. Instead of duplicating shared state between components, you will *lift it up* to their common shared parent, and *pass it down* to the children that need it.
+**For each unique piece of state, you will choose the component that "owns" it.** This principle is also known as having a ["single source of truth".](https://en.wikipedia.org/wiki/Single_source_of_truth) It doesn't mean that all state lives in one place--but that for _each_ piece of state, there is a _specific_ component that holds that piece of information. Instead of duplicating shared state between components, you will *lift it up* to their common shared parent, and *pass it down* to the children that need it.
 
 Your app will change as you work on it. It is common that you will move state down or back up while you're still figuring out where each piece of the state "lives". This is all part of the process!
 
diff --git a/beta/src/content/learn/start-a-new-react-project.md b/beta/src/content/learn/start-a-new-react-project.md
index 5798e9c2..e0880efe 100644
--- a/beta/src/content/learn/start-a-new-react-project.md
+++ b/beta/src/content/learn/start-a-new-react-project.md
@@ -21,7 +21,7 @@ If you're starting a new project, we recommend to use a toolchain or a framework
 
 React is a library that lets you organize UI code by breaking it apart into pieces called components. React doesn't take care of routing or data management. This means there are several ways to start a new React project:
 
-* [Start with an **HTML file and a script tag**.](/learn/add-react-to-a-website) This doesn't require Node.js setup but offers limited features.
+* [Start with an **HTML file and a script tag.**](/learn/add-react-to-a-website) This doesn't require Node.js setup but offers limited features.
 * Start with a **minimal toolchain,** adding more features to your project as you go. (Great for learning!)
 * Start with an **opinionated framework** that has common features like data fetching and routing built-in.
 
diff --git a/beta/src/content/learn/state-a-components-memory.md b/beta/src/content/learn/state-a-components-memory.md
index c1a1ebec..0b4d3e45 100644
--- a/beta/src/content/learn/state-a-components-memory.md
+++ b/beta/src/content/learn/state-a-components-memory.md
@@ -522,7 +522,7 @@ It is a good idea to have multiple state variables if their state is unrelated,
 
 You might have noticed that the `useState` call does not receive any information about *which* state variable it refers to. There is no "identifier" that is passed to `useState`, so how does it know which of the state variables to return? Does it rely on some magic like parsing your functions? The answer is no.
 
-Instead, to enable their concise syntax, Hooks **rely on a stable call order on every render of the same component**. This works well in practice because if you follow the rule above ("only call Hooks at the top level"), Hooks will always be called in the same order. Additionally, a [linter plugin](https://www.npmjs.com/package/eslint-plugin-react-hooks) catches most mistakes.
+Instead, to enable their concise syntax, Hooks **rely on a stable call order on every render of the same component.** This works well in practice because if you follow the rule above ("only call Hooks at the top level"), Hooks will always be called in the same order. Additionally, a [linter plugin](https://www.npmjs.com/package/eslint-plugin-react-hooks) catches most mistakes.
 
 Internally, React holds an array of state pairs for every component. It also maintains the current pair index, which is set to `0` before rendering. Each time you call `useState`, React gives you the next state pair and increments the index. You can read more about this mechanism in [React Hooks: Not Magic, Just Arrays](https://medium.com/@ryardley/react-hooks-not-magic-just-arrays-cd4f1857236e).
 
@@ -887,7 +887,7 @@ button {
 
 This is what makes state different from regular variables that you might declare at the top of your module. State is not tied to a particular function call or a place in the code, but it's "local" to the specific place on the screen. You rendered two `<Gallery />` components, so their state is stored separately.
 
-Also notice how the `Page` component doesn't "know" anything about the `Gallery` state or even whether it has any. Unlike props, **state is fully private to the component declaring it**. The parent component can't change it. This lets you add state to any component or remove it without impacting the rest of the components.
+Also notice how the `Page` component doesn't "know" anything about the `Gallery` state or even whether it has any. Unlike props, **state is fully private to the component declaring it.** The parent component can't change it. This lets you add state to any component or remove it without impacting the rest of the components.
 
 What if you wanted both galleries to keep their states in sync? The right way to do it in React is to *remove* state from child components and add it to their closest shared parent. The next few pages will focus on organizing state of a single component, but we will return to this topic in [Sharing State Between Components](/learn/sharing-state-between-components).
 
diff --git a/beta/src/content/learn/synchronizing-with-effects.md b/beta/src/content/learn/synchronizing-with-effects.md
index 02335c4d..b8fdb1da 100644
--- a/beta/src/content/learn/synchronizing-with-effects.md
+++ b/beta/src/content/learn/synchronizing-with-effects.md
@@ -829,7 +829,7 @@ Type something into the input and then immediately press "Unmount the component"
 
 Finally, edit the component above and **comment out the cleanup function** so that the timeouts don't get cancelled. Try typing `abcde` fast. What do you expect to happen in three seconds? Will `console.log(text)` inside the timeout print the *latest* `text` and produce five `abcde` logs? Give it a try to check your intution!
 
-Three seconds later, you should see a sequence of logs (`a`, `ab`, `abc`, `abcd`, and `abcde`) rather than five `abcde` logs. **Each Effect "captures" the `text` value from its corresponding render**.  It doesn't matter that the `text` state changed: an Effect from the render with `text = 'ab'` will always see `'ab'`. In other words, Effects from each render are isolated from each other. If you're curious how this works, you can read about [closures](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures).
+Three seconds later, you should see a sequence of logs (`a`, `ab`, `abc`, `abcd`, and `abcde`) rather than five `abcde` logs. **Each Effect "captures" the `text` value from its corresponding render.**  It doesn't matter that the `text` state changed: an Effect from the render with `text = 'ab'` will always see `'ab'`. In other words, Effects from each render are isolated from each other. If you're curious how this works, you can read about [closures](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures).
 
 <DeepDive title="Each render has its own Effects">
 
diff --git a/beta/src/content/learn/thinking-in-react.md b/beta/src/content/learn/thinking-in-react.md
index 1291ace0..333c0efc 100644
--- a/beta/src/content/learn/thinking-in-react.md
+++ b/beta/src/content/learn/thinking-in-react.md
@@ -228,7 +228,7 @@ What's left is probably state.
 
 Let's go through them one by one again:
 
-1. The original list of products is **passed in as props, so it's not state**. 
+1. The original list of products is **passed in as props, so it's not state.** 
 2. The search text seems to be state since it changes over time and can't be computed from anything.
 3. The value of the checkbox seems to be state since it changes over time and can't be computed from anything.
 4. The filtered list of products **isn't state because it can be computed** by taking the original list of products and filtering it according to the search text and value of the checkbox.
diff --git a/beta/src/content/learn/updating-arrays-in-state.md b/beta/src/content/learn/updating-arrays-in-state.md
index 6bcef5f0..74a48636 100644
--- a/beta/src/content/learn/updating-arrays-in-state.md
+++ b/beta/src/content/learn/updating-arrays-in-state.md
@@ -18,7 +18,7 @@ Arrays are mutable in JavaScript, but you should treat them as immutable when yo
 
 ## Updating arrays without mutation {/*updating-arrays-without-mutation*/}
 
-In JavaScript, arrays are just another kind of object. [Like with objects](/learn/updating-objects-in-state), **you should treat arrays in React state as read-only**. This means that you shouldn't reassign items inside an array like `arr[0] = 'bird'`, and you also shouldn't use methods that mutate the array, such as `push()` and `pop()`.
+In JavaScript, arrays are just another kind of object. [Like with objects](/learn/updating-objects-in-state), **you should treat arrays in React state as read-only.** This means that you shouldn't reassign items inside an array like `arr[0] = 'bird'`, and you also shouldn't use methods that mutate the array, such as `push()` and `pop()`.
 
 Instead, every time you want to update an array, you'll want to pass a *new* array to your state setting function. To do that, you can create a new array from the original array in your state by calling its non-mutating methods like `filter()` and `map()`. Then you can set your state to the resulting new array.
 
@@ -446,7 +446,7 @@ export default function List() {
 
 Here, you use the `[...list]` spread syntax to create a copy of the original array first. Now that you have a copy, you can use mutating methods like `nextList.reverse()` or `nextList.sort()`, or even assign individual items with `nextList[0] = "something"`.
 
-However, **even if you copy an array, you can't mutate existing items _inside_ of it directly**. This is because copying is shallow--the new array will contain the same items as the original one. So if you modify an object inside the copied array, you are mutating the existing state. For example, code like this is a problem.
+However, **even if you copy an array, you can't mutate existing items _inside_ of it directly.** This is because copying is shallow--the new array will contain the same items as the original one. So if you modify an object inside the copied array, you are mutating the existing state. For example, code like this is a problem.
 
 ```js
 const nextList = [...list];
@@ -454,7 +454,7 @@ nextList[0].seen = true; // Problem: mutates list[0]
 setList(nextList);
 ```
 
-Although `nextList` and `list` are two different arrays, **`nextList[0]` and `list[0]` point to the same object**. So by changing `nextList[0].seen`, you are also changing `list[0].seen`. This is a state mutation, which you should avoid! You can solve this issue in a similar way to [updating nested JavaScript objects](/learn/updating-objects-in-state#updating-a-nested-object)--by copying individual items you want to change instead of mutating them. Here's how.
+Although `nextList` and `list` are two different arrays, **`nextList[0]` and `list[0]` point to the same object.** So by changing `nextList[0].seen`, you are also changing `list[0].seen`. This is a state mutation, which you should avoid! You can solve this issue in a similar way to [updating nested JavaScript objects](/learn/updating-objects-in-state#updating-a-nested-object)--by copying individual items you want to change instead of mutating them. Here's how.
 
 ## Updating objects inside arrays {/*updating-objects-inside-arrays*/}
 
diff --git a/beta/src/content/learn/writing-markup-with-jsx.md b/beta/src/content/learn/writing-markup-with-jsx.md
index b3136958..d8dfbfbd 100644
--- a/beta/src/content/learn/writing-markup-with-jsx.md
+++ b/beta/src/content/learn/writing-markup-with-jsx.md
@@ -134,7 +134,7 @@ Most of the times, React's on-screen error messages will help you find where the
 
 ### 1. Return a single root element {/*1-return-a-single-root-element*/}
 
-To return multiple elements from a component, **wrap them with a single parent tag**.
+To return multiple elements from a component, **wrap them with a single parent tag.**
 
 For example, you can use a `<div>`:
 
diff --git a/beta/src/content/learn/your-first-component.md b/beta/src/content/learn/your-first-component.md
index ef1b000a..529d4af7 100644
--- a/beta/src/content/learn/your-first-component.md
+++ b/beta/src/content/learn/your-first-component.md
@@ -55,7 +55,7 @@ As your project grows, you will notice that many of your designs can be composed
 
 ## Defining a component {/*defining-a-component*/}
 
-Traditionally when creating web pages, web developers marked up their content and then added interaction by sprinkling on some JavaScript. This worked great when interaction was a nice-to-have on the web. Now it is expected for many sites and all apps. React puts interactivity first while still using the same technology: **a React component is a JavaScript function that you can _sprinkle with markup_**. Here's what that looks like (you can edit the example below):
+Traditionally when creating web pages, web developers marked up their content and then added interaction by sprinkling on some JavaScript. This worked great when interaction was a nice-to-have on the web. Now it is expected for many sites and all apps. React puts interactivity first while still using the same technology: **a React component is a JavaScript function that you can _sprinkle with markup_.** Here's what that looks like (you can edit the example below):
 
 <Sandpack>