From a2c1f903157750141975e0d08dde2139ee25d312 Mon Sep 17 00:00:00 2001 From: rdvankck Date: Sat, 26 Jul 2025 21:07:15 +0300 Subject: [PATCH 1/2] Capitalize 'Components' in conditional rendering docs - Changed 'components' to 'Components' in intro text - Follows React.dev capitalization guidelines for React concepts Fixes #6713 --- src/content/learn/conditional-rendering.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/learn/conditional-rendering.md b/src/content/learn/conditional-rendering.md index 95be5d2e018..ecf175905f5 100644 --- a/src/content/learn/conditional-rendering.md +++ b/src/content/learn/conditional-rendering.md @@ -4,7 +4,7 @@ title: Conditional Rendering -Your components will often need to display different things depending on different conditions. In React, you can conditionally render JSX using JavaScript syntax like `if` statements, `&&`, and `? :` operators. +Your Components will often need to display different things depending on different conditions. In React, you can conditionally render JSX using JavaScript syntax like `if` statements, `&&`, and `? :` operators. From 3a292eed5b67bf871e97ab67d27a487556f51347 Mon Sep 17 00:00:00 2001 From: rdvankck Date: Sat, 26 Jul 2025 21:34:15 +0300 Subject: [PATCH 2/2] Capitalize Components in documentation - Updated 7 instances across 2 files - Fixes #6713 --- src/content/learn/conditional-rendering.md | 2 +- src/content/learn/keeping-components-pure.md | 10 +++++----- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/content/learn/conditional-rendering.md b/src/content/learn/conditional-rendering.md index ecf175905f5..0d5c8f5dca0 100644 --- a/src/content/learn/conditional-rendering.md +++ b/src/content/learn/conditional-rendering.md @@ -256,7 +256,7 @@ export default function PackingList() { -This style works well for simple conditions, but use it in moderation. If your components get messy with too much nested conditional markup, consider extracting child components to clean things up. In React, markup is a part of your code, so you can use tools like variables and functions to tidy up complex expressions. +This style works well for simple conditions, but use it in moderation. If your Components get messy with too much nested conditional markup, consider extracting child components to clean things up. In React, markup is a part of your code, so you can use tools like variables and functions to tidy up complex expressions. ### Logical AND operator (`&&`) {/*logical-and-operator-*/} diff --git a/src/content/learn/keeping-components-pure.md b/src/content/learn/keeping-components-pure.md index 70049e58e27..1e7293f969e 100644 --- a/src/content/learn/keeping-components-pure.md +++ b/src/content/learn/keeping-components-pure.md @@ -4,7 +4,7 @@ title: Keeping Components Pure -Some JavaScript functions are *pure.* Pure functions only perform a calculation and nothing more. By strictly only writing your components as pure functions, you can avoid an entire class of baffling bugs and unpredictable behavior as your codebase grows. To get these benefits, though, there are a few rules you must follow. +Some JavaScript functions are *pure.* Pure functions only perform a calculation and nothing more. By strictly only writing your Components as pure functions, you can avoid an entire class of baffling bugs and unpredictable behavior as your codebase grows. To get these benefits, though, there are a few rules you must follow. @@ -12,7 +12,7 @@ Some JavaScript functions are *pure.* Pure functions only perform a calculation * What purity is and how it helps you avoid bugs * How to keep components pure by keeping changes out of the render phase -* How to use Strict Mode to find mistakes in your components +* How to use Strict Mode to find mistakes in your Components @@ -81,7 +81,7 @@ If you pass `drinkers={4}`, it will return JSX containing `4 cups of water`. Alw Just like a math formula. -You could think of your components as recipes: if you follow them and don't introduce new ingredients during the cooking process, you will get the same dish every time. That "dish" is the JSX that the component serves to React to [render.](/learn/render-and-commit) +You could think of your Components as recipes: if you follow them and don't introduce new ingredients during the cooking process, you will get the same dish every time. That "dish" is the JSX that the component serves to React to [render.](/learn/render-and-commit) @@ -143,7 +143,7 @@ export default function TeaSet() { Now your component is pure, as the JSX it returns only depends on the `guest` prop. -In general, you should not expect your components to be rendered in any particular order. It doesn't matter if you call y = 2x before or after y = 5x: both formulas will resolve independently of each other. In the same way, each component should only "think for itself", and not attempt to coordinate with or depend upon others during rendering. Rendering is like a school exam: each component should calculate JSX on their own! +In general, you should not expect your Components to be rendered in any particular order. It doesn't matter if you call y = 2x before or after y = 5x: both formulas will resolve independently of each other. In the same way, each component should only "think for itself", and not attempt to coordinate with or depend upon others during rendering. Rendering is like a school exam: each component should calculate JSX on their own! @@ -219,7 +219,7 @@ Every new React feature we're building takes advantage of purity. From data fetc * **It minds its own business.** It should not change any objects or variables that existed before rendering. * **Same inputs, same output.** Given the same inputs, a component should always return the same JSX. * Rendering can happen at any time, so components should not depend on each others' rendering sequence. -* You should not mutate any of the inputs that your components use for rendering. That includes props, state, and context. To update the screen, ["set" state](/learn/state-a-components-memory) instead of mutating preexisting objects. +* You should not mutate any of the inputs that your Components use for rendering. That includes props, state, and context. To update the screen, ["set" state](/learn/state-a-components-memory) instead of mutating preexisting objects. * Strive to express your component's logic in the JSX you return. When you need to "change things", you'll usually want to do it in an event handler. As a last resort, you can `useEffect`. * Writing pure functions takes a bit of practice, but it unlocks the power of React's paradigm.