Browse Source

[beta] Fix some broken links, add [](TODO) (#5009)

main
Ricky 2 years ago
committed by GitHub
parent
commit
89201dd764
No known key found for this signature in database GPG Key ID: 4AEE18F83AFDEB23
  1. 14
      beta/src/components/MDX/MDXComponents.tsx
  2. 4
      beta/src/content/apis/react-dom/render.md
  3. 2
      beta/src/content/apis/react/useContext.md
  4. 4
      beta/src/content/apis/react/useState.md
  5. 2
      beta/src/content/learn/choosing-the-state-structure.md
  6. 2
      beta/src/content/learn/keeping-components-pure.md
  7. 4
      beta/src/content/learn/passing-props-to-a-component.md
  8. 2
      beta/src/content/learn/render-and-commit.md
  9. 2
      beta/src/content/learn/state-a-components-memory.md
  10. 4
      beta/src/content/learn/updating-objects-in-state.md
  11. 4
      beta/src/content/learn/writing-markup-with-jsx.md

14
beta/src/components/MDX/MDXComponents.tsx

@ -322,6 +322,18 @@ function InlineTocItem({items}: {items: Array<NestedTocNode>}) {
);
}
function LinkWithTodo({href, children, ...props}: JSX.IntrinsicElements['a']) {
if (href?.startsWith('TODO')) {
return children;
}
return (
<Link href={href} {...props}>
{children}
</Link>
);
}
export const MDXComponents = {
p: P,
strong: Strong,
@ -335,7 +347,7 @@ export const MDXComponents = {
h4: H4,
inlineCode: InlineCode,
hr: Divider,
a: Link,
a: LinkWithTodo,
code: CodeBlock,
// The code block renders <pre> so we just want a div here.
pre: (p: JSX.IntrinsicElements['div']) => <div {...p} />,

4
beta/src/content/apis/react-dom/render.md

@ -132,7 +132,7 @@ nav ul li { display: inline-block; margin-right: 20px; }
</Sandpack>
You can destroy the rendered trees with [`unmountComponentAtNode()`](TODO).
You can destroy the rendered trees with [`unmountComponentAtNode()`](/apis/react-dom/unmountComponentAtNode).
---
@ -212,6 +212,6 @@ An app fully built with React will usually only have one `render` call with its
* If you call `render` on the same `domNode` more than once, React will update the DOM as necessary to reflect the latest JSX you passed. React will decide which parts of the DOM can be reused and which need to be recreated by ["matching it up"](/learn/preserving-and-resetting-state) with the previously rendered tree. Calling `render` on the same `domNode` again is similar to calling the [`set` function](/apis/react/useState#setstate) on the root component: React avoids unnecessary DOM updates.
* If your app is fully built with React, you'll likely have only one `render` call in your app. (If you use a framework, it might do this call for you.) When you want to render a piece of JSX in a different part of the DOM tree that isn't a child of your component (for example, a modal or a tooltip), use [`createPortal`](TODO) instead of `render`.
* If your app is fully built with React, you'll likely have only one `render` call in your app. (If you use a framework, it might do this call for you.) When you want to render a piece of JSX in a different part of the DOM tree that isn't a child of your component (for example, a modal or a tooltip), use [`createPortal`](/apis/react-dom/createPortal) instead of `render`.
---

2
beta/src/content/apis/react/useContext.md

@ -1305,7 +1305,7 @@ function MyApp() {
}
```
The `login` function does not use any information from the render scope, so you can specify an empty array of dependencies. The `contextValue` object consists of `currentUser` and `login`, so it needs to list both as dependencies. As a result of this change, the components calling `useContext(AuthProvider)` won't need to re-render unless `currentUser` changes. Read more about [skipping re-renders with memoization](TODO).
The `login` function does not use any information from the render scope, so you can specify an empty array of dependencies. The `contextValue` object consists of `currentUser` and `login`, so it needs to list both as dependencies. As a result of this change, the components calling `useContext(AuthProvider)` won't need to re-render unless `currentUser` changes. Read more about [skipping re-renders with memoization](TODO:/learn/skipping-unchanged-trees).
---

4
beta/src/content/apis/react/useState.md

@ -31,7 +31,7 @@ function MyComponent() {
// ...
```
The convention is to name state variables like `[something, setSomething]` using [array destructuring](/learn/a-javascript-refresher#array-destructuring).
The convention is to name state variables like `[something, setSomething]` using [array destructuring](TODO:/learn/a-javascript-refresher#array-destructuring).
`useState` returns an array with exactly two items:
@ -1083,7 +1083,7 @@ function MyComponent() {
// ...
```
The convention is to name state variables like `[something, setSomething]` using [array destructuring](/learn/a-javascript-refresher#array-destructuring).
The convention is to name state variables like `[something, setSomething]` using [array destructuring](TODO:/learn/a-javascript-refresher#array-destructuring).
[See more examples above.](#examples-basic)

2
beta/src/content/learn/choosing-the-state-structure.md

@ -816,7 +816,7 @@ export const initialTravelPlan = {
</Sandpack>
Now let's say you want to add a button to delete a place you've already visited. How would you go about it? [Updating nested state](/learn/updating-objects-and-arrays-in-state#updating-nested-objects-and-arrays) involves making copies of objects all the way up from the part that changed. Deleting a deeply nested place would involve copying its entire parent place chain. Such code can be very verbose.
Now let's say you want to add a button to delete a place you've already visited. How would you go about it? [Updating nested state](/learn/updating-objects-in-state#updating-a-nested-object) involves making copies of objects all the way up from the part that changed. Deleting a deeply nested place would involve copying its entire parent place chain. Such code can be very verbose.
**If the state is too nested to update easily, consider making it "flat".** Here is one way you can restructure this data. Instead of a tree-like structure where each `place` has an array of *its child places*, you can have each place hold an array of *its child place IDs*. Then you can store a mapping from each place ID to the corresponding place.

2
beta/src/content/learn/keeping-components-pure.md

@ -202,7 +202,7 @@ When possible, try to express your logic with rendering alone. You'll be surpris
Writing pure functions takes some habit and discipline. But it also unlocks marvelous opportunities:
* Your components could run in a different environment—for example, on the server! Since they return the same result for the same inputs, one component can serve many user requests.
* You can improve performance by [skipping rendering](/learn/skipping-unchanged-trees) components whose inputs have not changed. This is safe because pure functions always return the same results, so they are safe to cache.
* You can improve performance by [skipping rendering](TODO:/learn/skipping-unchanged-trees) components whose inputs have not changed. This is safe because pure functions always return the same results, so they are safe to cache.
* If some data changes in the middle of rendering a deep component tree, React can restart rendering without wasting time to finish the outdated render. Purity makes it safe to stop calculating at any time.
Every new React feature we're building takes advantage of purity. From data fetching to animations to performance, keeping components pure unlocks the power of the React paradigm.

4
beta/src/content/learn/passing-props-to-a-component.md

@ -345,7 +345,7 @@ export function getImageUrl(person, size = 's') {
Try replacing the `<Avatar>` inside `<Card>` with some text to see how the `Card` component can wrap any nested content. It doesn't need to "know" what's being rendered inside of it. You will see this flexible pattern in many places.
You can think of a component with a `children` prop as having a "hole" that can be "filled in" by its parent components with arbitrary JSX. You will often use the `children` prop for visual wrappers: panels, grids, and so on. You can explore this in more detail in [Extracting Layout Components](/learn/extracting-layout-components).
You can think of a component with a `children` prop as having a "hole" that can be "filled in" by its parent components with arbitrary JSX. You will often use the `children` prop for visual wrappers: panels, grids, and so on. You can explore this in more detail in [Extracting Layout Components](TODO:/learn/extracting-layout-components).
<Illustration src="/images/docs/illustrations/i_children-prop.png" alt='A puzzle-like Card tile with a slot for "children" pieces like text and Avatar' />
@ -1110,4 +1110,4 @@ h1 {
</Solution>
</Challenges>
</Challenges>

2
beta/src/content/learn/render-and-commit.md

@ -140,7 +140,7 @@ Otherwise, you can encounter confusing bugs and unpredictable behavior as your c
<DeepDive title="Optimizing performance">
The default behavior of rendering all components nested within the updated component is not optimal for performance if the updated component is very high in the tree. If you run into a performance issue, there are several opt-in ways to solve it described in the [Performance](/learn/performance) section. **Don't optimize prematurely!**
The default behavior of rendering all components nested within the updated component is not optimal for performance if the updated component is very high in the tree. If you run into a performance issue, there are several opt-in ways to solve it described in the [Performance](https://reactjs.org/docs/optimizing-performance.html#gatsby-focus-wrapper) section. **Don't optimize prematurely!**
</DeepDive>

2
beta/src/content/learn/state-a-components-memory.md

@ -188,7 +188,7 @@ const [index, setIndex] = useState(0);
`index` is a state variable and `setIndex` is the setter function.
> The `[` and `]` syntax here is called [array destructuring](/learn/a-javascript-refresher#array-destructuring) and it lets you read values from an array. The array returned by `useState` always has exactly two items.
> The `[` and `]` syntax here is called [array destructuring](TODO:/learn/a-javascript-refresher#array-destructuring) and it lets you read values from an array. The array returned by `useState` always has exactly two items.
This is how they work together in `handleClick`:

4
beta/src/content/learn/updating-objects-in-state.md

@ -788,7 +788,7 @@ Notice how much more concise the event handlers have become. You can mix and mat
There are a few reasons:
* **Debugging:** If you use `console.log` and don't mutate state, your past logs won't get clobbered by the more recent state changes. So you can clearly see how state has changed between renders.
* **Optimizations:** Common React [optimization strategies](/learn/skipping-unchanged-trees) rely on skipping work if previous props or state are the same as the next ones. If you never mutate state, it is very fast to check whether there were any changes. If `prevObj === obj`, you can be sure that nothing could have changed inside of it.
* **Optimizations:** Common React [optimization strategies](TODO:/learn/skipping-unchanged-trees) rely on skipping work if previous props or state are the same as the next ones. If you never mutate state, it is very fast to check whether there were any changes. If `prevObj === obj`, you can be sure that nothing could have changed inside of it.
* **New Features:** The new React features we're building rely on state being [treated like a snapshot](/learn/state-as-a-snapshot). If you're mutating past versions of state, that may prevent you from using the new features.
* **Requirement Changes:** Some application features, like implementing Undo/Redo, showing a history of changes, or letting the user reset a form to earlier values, are easier to do when nothing is mutated. This is because you can keep past copies of state in memory, and reuse them when appropriate. If you start with a mutative approach, features like this can be difficult to add later on.
* **Simpler Implementation:** Because React does not rely on mutation, it does not need to do anything special with your objects. It does not need to hijack their properties, always wrap them into Proxies, or do other work at initialization as many "reactive" solutions do. This is also why React lets you put any object into state--no matter how large--without additional performance or correctness pitfalls.
@ -1612,4 +1612,4 @@ select { margin-bottom: 10px; }
</Solution>
</Challenges>
</Challenges>

4
beta/src/content/learn/writing-markup-with-jsx.md

@ -60,7 +60,7 @@ Each React component is a JavaScript function that may contain some markup that
<Note>
[JSX and React are two separate things](/blog/2020/09/22/introducing-the-new-jsx-transform.html#whats-a-jsx-transform) you _can_ use independently of each other.
[JSX and React are two separate things](https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html#whats-a-jsx-transform) you _can_ use independently of each other.
</Note>
@ -169,7 +169,7 @@ If you don't want to add an extra `<div>` to your markup, you can write `<>` and
</>
```
This empty tag is called a *[React fragment](TODO)*. React fragments let you group things without leaving any trace in the browser HTML tree.
This empty tag is called a *[React fragment](/apis/react/Fragment)*. React fragments let you group things without leaving any trace in the browser HTML tree.
<DeepDive title="Why do multiple JSX tags need to be wrapped?">

Loading…
Cancel
Save