Merge pull request #560 from reactjs/sync-d07016ae

Sync with reactjs.org @ d07016a
reactjs · Oct 10, 2022 · 958a934 · 958a934
2 parents 648aba9 + c49be86
commit 958a934
Show file tree

Hide file tree

Showing 39 changed files with 124 additions and 122 deletions.
diff --git a/beta/src/components/Icon/IconGotcha.tsx → beta/src/components/Icon/IconPitfall.tsx b/beta/src/components/Icon/IconGotcha.tsx → beta/src/components/Icon/IconPitfall.tsx
@@ -4,8 +4,8 @@
 
 import {memo} from 'react';
 
-export const IconGotcha = memo<JSX.IntrinsicElements['svg']>(
-  function IconGotcha({className}) {
+export const IconPitfall = memo<JSX.IntrinsicElements['svg']>(
+  function IconPitfall({className}) {
     return (
       <svg
         className={className}

diff --git a/beta/src/components/MDX/ExpandableCallout.tsx b/beta/src/components/MDX/ExpandableCallout.tsx
@@ -7,9 +7,9 @@ import * as React from 'react';
 import cn from 'classnames';
 import {IconNote} from '../Icon/IconNote';
 import {IconWarning} from '../Icon/IconWarning';
-import {IconGotcha} from '../Icon/IconGotcha';
+import {IconPitfall} from '../Icon/IconPitfall';
 
-type CalloutVariants = 'deprecated' | 'gotcha' | 'note' | 'wip';
+type CalloutVariants = 'deprecated' | 'pitfall' | 'note' | 'wip';
 
 interface ExpandableCalloutProps {
   children: React.ReactNode;
@@ -34,9 +34,9 @@ const variantMap = {
     overlayGradient:
       'linear-gradient(rgba(245, 249, 248, 0), rgba(245, 249, 248, 1)',
   },
-  gotcha: {
+  pitfall: {
     title: 'Atención',
-    Icon: IconGotcha,
+    Icon: IconPitfall,
     containerClasses: 'bg-yellow-5 dark:bg-yellow-60 dark:bg-opacity-20',
     textColor: 'text-yellow-50 dark:text-yellow-40',
     overlayGradient:
@@ -56,6 +56,8 @@ function ExpandableCallout({children, type}: ExpandableCalloutProps) {
   const contentRef = useRef<HTMLDivElement>(null);
   const variant = variantMap[type];
 
+  console.log('v,', variant);
+
   return (
     <div
       className={cn(

diff --git a/beta/src/components/MDX/MDXComponents.tsx b/beta/src/components/MDX/MDXComponents.tsx
@@ -76,8 +76,8 @@ const Divider = () => (
 const Wip = ({children}: {children: React.ReactNode}) => (
   <ExpandableCallout type="wip">{children}</ExpandableCallout>
 );
-const Gotcha = ({children}: {children: React.ReactNode}) => (
-  <ExpandableCallout type="gotcha">{children}</ExpandableCallout>
+const Pitfall = ({children}: {children: React.ReactNode}) => (
+  <ExpandableCallout type="pitfall">{children}</ExpandableCallout>
 );
 const Deprecated = ({children}: {children: React.ReactNode}) => (
   <ExpandableCallout type="deprecated">{children}</ExpandableCallout>
@@ -371,7 +371,7 @@ export const MDXComponents = {
   MaxWidth({children}: {children: any}) {
     return <div className="max-w-4xl ml-0 2xl:mx-auto">{children}</div>;
   },
-  Gotcha,
+  Pitfall,
   Deprecated,
   Wip,
   HomepageHero,

diff --git a/beta/src/content/apis/react-dom/client/createRoot.md b/beta/src/content/apis/react-dom/client/createRoot.md
@@ -96,11 +96,11 @@ This can feel very slow! To solve this, you can generate the initial HTML from y
 
 </Note>
 
-<Gotcha>
+<Pitfall>
 
 **Apps using server rendering or static generation must call [`hydrateRoot`](/apis/react-dom/client/hydrateRoot) instead of `createRoot`.** React will then *hydrate* (reuse) the DOM nodes from your HTML instead of destroying and re-creating them.
 
-</Gotcha>
+</Pitfall>
 
 ---
 

diff --git a/beta/src/content/apis/react-dom/client/hydrateRoot.md b/beta/src/content/apis/react-dom/client/hydrateRoot.md
@@ -79,7 +79,7 @@ function Counter() {
 
 You shouldn't need to call `hydrateRoot` again or to call it in more places. From this point on, React will be managing the DOM of your application. If you want to update the UI, your components can do this by [using state.](/apis/react/useState)
 
-<Gotcha>
+<Pitfall>
 
 The React tree you pass to `hydrateRoot` needs to produce **the same output** as it did on the server.
 
@@ -94,7 +94,7 @@ The most common causes leading to hydration errors include:
 
 React can recover from some hydration errors, but **you must fix them like other bugs.** In the best case, they'll lead to a slower app; in the worst case, event handlers would get attached to the wrong elements.
 
-</Gotcha>
+</Pitfall>
 
 ### Updating a hydrated root component {/*updating-a-hydrated-root-component*/}
 

diff --git a/beta/src/content/apis/react-dom/findDOMNode.md b/beta/src/content/apis/react-dom/findDOMNode.md
@@ -21,8 +21,8 @@ findDOMNode(component)
 
 <InlineToc />
 
-<Gotcha>
+<Pitfall>
 
 `findDOMNode` is an escape hatch used to access the underlying DOM node. In most cases, use of this escape hatch is discouraged because it pierces the component abstraction. [It has been deprecated in StrictMode.](https://reactjs.org/docs/strict-mode.html#warning-about-deprecated-finddomnode-usage)
 
-</Gotcha>
+</Pitfall>
diff --git a/beta/src/content/apis/react-dom/flushSync.md b/beta/src/content/apis/react-dom/flushSync.md
@@ -2,11 +2,11 @@
 title: flushSync
 ---
 
-<Gotcha>
+<Pitfall>
 
 Using `flushSync` is uncommon and can hurt the performance of your app.
 
-</Gotcha>
+</Pitfall>
 
 <Intro>
 
@@ -90,13 +90,13 @@ export default function PrintApp() {
 
 If you remove the call to `flushSync`, then when the print dialog will display `isPrinting` as "no". This is because React batches the updates asynchronously and the print dialog is displayed before the state is updated.
 
-<Gotcha>
+<Pitfall>
 
 `flushSync` can significantly hurt performance, and may unexpectedly force pending Suspense boundaries to show their fallback state.
 
 Most of the time, `flushSync` can be avoided, so use `flushSync` as last resort.
 
-</Gotcha>
+</Pitfall>
 
 ---
 

diff --git a/beta/src/content/apis/react-dom/hydrate.md b/beta/src/content/apis/react-dom/hydrate.md
@@ -1,11 +1,11 @@
 ---
 title: hydrate
 ---
-<Gotcha>
+<Pitfall>
 
 In React 18, `hydrate` was replaced by [`hydrateRoot`.](/apis/react-dom/client/hydrateRoot) Using `hydrate` in React 18 will warn that your app will behave as if it’s running React 17. Learn more [here.](https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html#updates-to-client-rendering-apis)
 
-</Gotcha>
+</Pitfall>
 
 <Intro>
 
@@ -155,13 +155,13 @@ export default function App() {
 
 This way the initial render pass will render the same content as the server, avoiding mismatches, but an additional pass will happen synchronously right after hydration.
 
-<Gotcha>
+<Pitfall>
 
 This approach will make your components slower because they have to render twice, so use it with caution.
 
 Remember to be mindful of user experience on slow connections. The JavaScript code may load significantly later than the initial HTML render, so if you render something different in the client-only pass, the transition can be jarring. However, if executed well, it may be beneficial to render a “shell” of the application on the server, and only show some of the extra widgets on the client. To learn how to do this without getting the markup mismatch issues, refer to the explanation in the previous paragraph.
 
-</Gotcha>
+</Pitfall>
 
 
 

diff --git a/beta/src/content/apis/react-dom/render.md b/beta/src/content/apis/react-dom/render.md
@@ -2,11 +2,11 @@
 title: render
 ---
 
-<Gotcha>
+<Pitfall>
 
 In React 18, `render` was replaced by [`createRoot`.](/apis/react-dom/client/createRoot) Using `render` in React 18 will warn that your app will behave as if it’s running React 17. Learn more [here.](https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html#updates-to-client-rendering-apis)
 
-</Gotcha>
+</Pitfall>
 
 
 <Intro>

diff --git a/beta/src/content/apis/react/Children.md b/beta/src/content/apis/react/Children.md
@@ -2,11 +2,11 @@
 title: Children
 ---
 
-<Gotcha>
+<Pitfall>
 
 Using `Children` is uncommon and can lead to fragile code. [See common alternatives.](#alternatives)
 
-</Gotcha>
+</Pitfall>
 
 <Intro>
 
@@ -136,7 +136,7 @@ Even when `children` is an array, `Children.map` has useful special behavior. Fo
 
 </DeepDive>
 
-<Gotcha>
+<Pitfall>
 
 The `children` data structure **does not include rendered output** of the components you pass as JSX. In the example below, the `children` received by the `RowList` only contains two items rather than three:
 
@@ -204,7 +204,7 @@ export default function RowList({ children }) {
 
 **There is no way to get the rendered output of an inner component** like `<MoreRows />` when manipulating `children`. This is why [it's usually better to use one of the alternative solutions.](#alternatives)
 
-</Gotcha>
+</Pitfall>
 
 ---
 
@@ -244,11 +244,11 @@ export default function SeparatorList({ children }) {
 
 </Sandpack>
 
-<Gotcha>
+<Pitfall>
 
 As mentioned earlier, there is no way to get the rendered output of an inner component when manipulating `children`. This is why [it's usually better to use one of the alternative solutions.](#alternatives)
 
-</Gotcha>
+</Pitfall>
 
 ---
 
@@ -315,11 +315,11 @@ export default function RowList({ children }) {
 
 </Sandpack>
 
-<Gotcha>
+<Pitfall>
 
 As mentioned earlier, there is no way to get the rendered output of an inner component when manipulating `children`. This is why [it's usually better to use one of the alternative solutions.](#alternatives)
 
-</Gotcha>
+</Pitfall>
 
 ---
 
@@ -355,11 +355,11 @@ export default function ReversedList({ children }) {
 
 </Sandpack>
 
-<Gotcha>
+<Pitfall>
 
 As mentioned earlier, there is no way to get the rendered output of an inner component when manipulating `children`. This is why [it's usually better to use one of the alternative solutions.](#alternatives)
 
-</Gotcha>
+</Pitfall>
 
 ---
 

diff --git a/beta/src/content/apis/react/Suspense.md b/beta/src/content/apis/react/Suspense.md
@@ -54,7 +54,7 @@ Suspense will never show unintentional "holes" in your content. For example, if
 
 To reveal nested content as it loads, you need to [add more Suspense boundaries.](#revealing-nested-content-as-it-loads)
 
-<Gotcha>
+<Pitfall>
 
 **Only Suspense-enabled data sources will activate a Suspense boundary.** These data sources are said to *suspend* when the data needed to render has not yet loaded. Currently, Suspense is only supported for:
 
@@ -65,7 +65,7 @@ Suspense-enabled data fetching without the use of an opinionated framework is no
 
 Suspense does not detect when data is fetched inside an Effect or event handler.
 
-</Gotcha>
+</Pitfall>
 
 ---
 

diff --git a/beta/src/content/apis/react/createFactory.md b/beta/src/content/apis/react/createFactory.md
@@ -175,7 +175,7 @@ export default function App() {
 
 </Sandpack>
 
-<Gotcha>
+<Pitfall>
 
 Sometimes, your existing code might pass some variable as a `type` instead of a constant like `'button'`:
 
@@ -198,7 +198,7 @@ function Heading({ isSubheading, ...props }) {
 
 Otherwise React will interpret `<type>` as a built-in HTML tag because it is lowercase.
 
-</Gotcha>
+</Pitfall>
 
 ---
 

diff --git a/beta/src/content/apis/react/forwardRef.md b/beta/src/content/apis/react/forwardRef.md
@@ -407,13 +407,13 @@ input {
 
 [Read more about using imperative handles.](/apis/react/useImperativeHandle)
 
-<Gotcha>
+<Pitfall>
 
 **Do not overuse refs.** You should only use refs for *imperative* behaviors that you can't express as props: for example, scrolling to a node, focusing a node, triggering an animation, selecting text, and so on.
 
 **If you can express something as a prop, you should not use a ref.** For example, instead of exposing an imperative handle like `{ open, close }` from a `Modal` component, it is better to take `isOpen` as a prop like `<Modal isOpen={isOpen} />`. [Effects](/learn/synchronizing-with-effects) can help you expose imperative behaviors via props.
 
-</Gotcha>
+</Pitfall>
 
 ---
 

diff --git a/beta/src/content/apis/react/memo.md b/beta/src/content/apis/react/memo.md
@@ -317,13 +317,13 @@ If you do this, use the Performance panel in your browser developer tools to mak
 
 When you do performance measurements, make sure that React is running in the production mode.
 
-<Gotcha>
+<Pitfall>
 
 If you provide a custom `arePropsEqual` implementation, **you must compare every prop, including functions.** Functions often [close over](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures) the props and state of parent components. If you return `true` when `oldProps.onClick !== newProps.onClick`, your component will keep "seeing" the props and state from a previous render inside its `onClick` handler, leading to very confusing bugs.
 
 Avoid doing deep equality checks inside `arePropsEqual` unless you are 100% sure that the data structure you're working with has a known limited depth. **Deep equality checks can become incredibly slow** and can freeze your app for many seconds if someone changes the data structure later.
 
-</Gotcha>
+</Pitfall>
 
 ---
 

diff --git a/beta/src/content/apis/react/useContext.md b/beta/src/content/apis/react/useContext.md
@@ -51,11 +51,11 @@ function Form() {
 
 It doesn't matter how many layers of components there are between the provider and the `Button`. When a `Button` *anywhere* inside of `Form` calls `useContext(ThemeContext)`, it will receive `"dark"` as the value.
 
-<Gotcha>
+<Pitfall>
 
 `useContext()` always looks for the closest provider *above* the component that calls it. It searches upwards and **does not** consider providers in the component from which you're calling `useContext()`.
 
-</Gotcha>
+</Pitfall>
 
 <Sandpack>
 

diff --git a/beta/src/content/apis/react/useEffect.md b/beta/src/content/apis/react/useEffect.md
@@ -1066,7 +1066,7 @@ function ChatRoom() {
 
 [An Effect with empty dependencies](/learn/lifecycle-of-reactive-effects#what-an-effect-with-empty-dependencies-means) doesn't re-run when any of your component's props or state change.
 
-<Gotcha>
+<Pitfall>
 
 If you have an existing codebase, you might have some Effects that suppress the linter like this:
 
@@ -1080,7 +1080,7 @@ useEffect(() => {
 
 **When dependencies don't match the code, there is a high risk of introducing bugs.** By suppressing the linter, you "lie" to React about the values your Effect depends on. [Instead, prove they're unnecessary.](/learn/removing-effect-dependencies#removing-unnecessary-dependencies)
 
-</Gotcha>
+</Pitfall>
 
 <Recipes titleText="Examples of passing reactive dependencies" titleId="examples-dependencies">
 

diff --git a/beta/src/content/apis/react/useId.md b/beta/src/content/apis/react/useId.md
@@ -18,11 +18,11 @@ const id = useId()
 
 ## Usage {/*usage*/}
 
-<Gotcha>
+<Pitfall>
 
 **Do not call `useId` to generate keys in a list.** [Keys should be generated from your data.](/learn/rendering-lists#where-to-get-your-key)
 
-</Gotcha>
+</Pitfall>
 
 ### Generating unique IDs for accessibility attributes {/*generating-unique-ids-for-accessibility-attributes*/}
 
@@ -133,11 +133,11 @@ input { margin: 5px; }
 
 [Watch this video](https://www.youtube.com/watch?v=0dNzNcuEuOo) to see the difference in the user experience with assistive technologies.
 
-<Gotcha>
+<Pitfall>
 
 **`useId` requires an identical component tree on the server and the client** when you use [server rendering](/apis/react-dom/server). If the trees you render on the server and the client don't match exactly, the generated IDs won't match.
 
-</Gotcha>
+</Pitfall>
 
 <DeepDive title="Why is useId better than an incrementing counter?">
 

diff --git a/beta/src/content/apis/react/useImperativeHandle.md b/beta/src/content/apis/react/useImperativeHandle.md
@@ -245,13 +245,13 @@ export default AddComment;
 
 </Sandpack>
 
-<Gotcha>
+<Pitfall>
 
 **Do not overuse refs.** You should only use refs for *imperative* behaviors that you can't express as props: for example, scrolling to a node, focusing a node, triggering an animation, selecting text, and so on.
 
 **If you can express something as a prop, you should not use a ref.** For example, instead of exposing an imperative handle like `{ open, close }` from a `Modal` component, it is better to take `isOpen` as a prop like `<Modal isOpen={isOpen} />`. [Effects](/learn/synchronizing-with-effects) can help you expose imperative behaviors via props.
 
-</Gotcha>
+</Pitfall>
 
 ---