Skip to content

Commit d8dda1c

Browse files
author
Ryan Mario
committed
fix: standardize capitalization of "State" and "Component" throughout managing-state.md
1 parent abe931a commit d8dda1c

1 file changed

Lines changed: 35 additions & 35 deletions

File tree

src/content/learn/managing-state.md

Lines changed: 35 additions & 35 deletions
Original file line numberDiff line numberDiff line change
@@ -4,27 +4,27 @@ title: Managing State
44

55
<Intro>
66

7-
As your application grows, it helps to be more intentional about how your state is organized and how the data flows between your components. Redundant or duplicate state is a common source of bugs. In this chapter, you'll learn how to structure your state well, how to keep your state update logic maintainable, and how to share state between distant components.
7+
As your application grows, it helps to be more intentional about how your State is organized and how the data flows between your Components. Redundant or duplicate State is a common source of bugs. In this chapter, you'll learn how to structure your State well, how to keep your State update logic maintainable, and how to share State between distant Components.
88

99
</Intro>
1010

1111
<YouWillLearn isChapter={true}>
1212

13-
* [How to think about UI changes as state changes](/learn/reacting-to-input-with-state)
14-
* [How to structure state well](/learn/choosing-the-state-structure)
15-
* [How to "lift state up" to share it between components](/learn/sharing-state-between-components)
16-
* [How to control whether the state gets preserved or reset](/learn/preserving-and-resetting-state)
17-
* [How to consolidate complex state logic in a function](/learn/extracting-state-logic-into-a-reducer)
13+
* [How to think about UI changes as State changes](/learn/reacting-to-input-with-state)
14+
* [How to structure State well](/learn/choosing-the-state-structure)
15+
* [How to "lift State up" to share it between Components](/learn/sharing-state-between-components)
16+
* [How to control whether the State gets preserved or reset](/learn/preserving-and-resetting-state)
17+
* [How to consolidate complex State logic in a function](/learn/extracting-state-logic-into-a-reducer)
1818
* [How to pass information without "prop drilling"](/learn/passing-data-deeply-with-context)
19-
* [How to scale state management as your app grows](/learn/scaling-up-with-reducer-and-context)
19+
* [How to scale State management as your app grows](/learn/scaling-up-with-reducer-and-context)
2020

2121
</YouWillLearn>
2222

23-
## Reacting to input with state {/*reacting-to-input-with-state*/}
23+
## Reacting to Input with State {/*reacting-to-input-with-state*/}
2424

25-
With React, you won't modify the UI from code directly. For example, you won't write commands like "disable the button", "enable the button", "show the success message", etc. Instead, you will describe the UI you want to see for the different visual states of your component ("initial state", "typing state", "success state"), and then trigger the state changes in response to user input. This is similar to how designers think about UI.
25+
With React, you won't modify the UI from code directly. For example, you won't write commands like "disable the button", "enable the button", "show the success message", etc. Instead, you will describe the UI you want to see for the different visual states of your Component ("initial state", "typing state", "success state"), and then trigger the State changes in response to user input. This is similar to how designers think about UI.
2626

27-
Here is a quiz form built using React. Note how it uses the `status` state variable to determine whether to enable or disable the submit button, and whether to show the success message instead.
27+
Here is a quiz form built using React. Note how it uses the `status` State variable to determine whether to enable or disable the submit button, and whether to show the success message instead.
2828

2929
<Sandpack>
3030

@@ -108,15 +108,15 @@ function submitForm(answer) {
108108
109109
<LearnMore path="/learn/reacting-to-input-with-state">
110110
111-
Read **[Reacting to Input with State](/learn/reacting-to-input-with-state)** to learn how to approach interactions with a state-driven mindset.
111+
Read **[Reacting to Input with State](/learn/reacting-to-input-with-state)** to learn how to approach interactions with a State-driven mindset.
112112
113113
</LearnMore>
114114
115-
## Choosing the state structure {/*choosing-the-state-structure*/}
115+
## Choosing the State Structure {/*choosing-the-state-structure*/}
116116
117-
Structuring state well can make a difference between a component that is pleasant to modify and debug, and one that is a constant source of bugs. The most important principle is that state shouldn't contain redundant or duplicated information. If there's unnecessary state, it's easy to forget to update it, and introduce bugs!
117+
Structuring State well can make a difference between a Component that is pleasant to modify and debug, and one that is a constant source of bugs. The most important principle is that State shouldn't contain redundant or duplicated information. If there's unnecessary State, it's easy to forget to update it, and introduce bugs!
118118
119-
For example, this form has a **redundant** `fullName` state variable:
119+
For example, this form has a **redundant** `fullName` State variable:
120120
121121
<Sandpack>
122122
@@ -169,7 +169,7 @@ label { display: block; margin-bottom: 5px; }
169169
170170
</Sandpack>
171171
172-
You can remove it and simplify the code by calculating `fullName` while the component is rendering:
172+
You can remove it and simplify the code by calculating `fullName` while the Component is rendering:
173173
174174
<Sandpack>
175175
@@ -225,15 +225,15 @@ This might seem like a small change, but many bugs in React apps are fixed this
225225
226226
<LearnMore path="/learn/choosing-the-state-structure">
227227
228-
Read **[Choosing the State Structure](/learn/choosing-the-state-structure)** to learn how to design the state shape to avoid bugs.
228+
Read **[Choosing the State Structure](/learn/choosing-the-state-structure)** to learn how to design the State shape to avoid bugs.
229229
230230
</LearnMore>
231231
232-
## Sharing state between components {/*sharing-state-between-components*/}
232+
## Sharing State Between Components {/*sharing-state-between-components*/}
233233
234-
Sometimes, you want the state of two components to always change together. To do it, remove state from both of them, move it to their closest common parent, and then pass it down to them via props. This is known as "lifting state up", and it's one of the most common things you will do writing React code.
234+
Sometimes, you want the State of two Components to always change together. To do it, remove State from both of them, move it to their closest common parent, and then pass it down to them via props. This is known as "lifting State up", and it's one of the most common things you will do writing React code.
235235
236-
In this example, only one panel should be active at a time. To achieve this, instead of keeping the active state inside each individual panel, the parent component holds the state and specifies the props for its children.
236+
In this example, only one panel should be active at a time. To achieve this, instead of keeping the active State inside each individual panel, the parent Component holds the State and specifies the props for its children.
237237
238238
<Sandpack>
239239
@@ -296,13 +296,13 @@ h3, p { margin: 5px 0px; }
296296
297297
<LearnMore path="/learn/sharing-state-between-components">
298298
299-
Read **[Sharing State Between Components](/learn/sharing-state-between-components)** to learn how to lift state up and keep components in sync.
299+
Read **[Sharing State Between Components](/learn/sharing-state-between-components)** to learn how to lift State up and keep Components in sync.
300300
301301
</LearnMore>
302302
303-
## Preserving and resetting state {/*preserving-and-resetting-state*/}
303+
## Preserving and Resetting State {/*preserving-and-resetting-state*/}
304304
305-
When you re-render a component, React needs to decide which parts of the tree to keep (and update), and which parts to discard or re-create from scratch. In most cases, React's automatic behavior works well enough. By default, React preserves the parts of the tree that "match up" with the previously rendered component tree.
305+
When you re-render a Component, React needs to decide which parts of the tree to keep (and update), and which parts to discard or re-create from scratch. In most cases, React's automatic behavior works well enough. By default, React preserves the parts of the tree that "match up" with the previously rendered Component tree.
306306

307307
However, sometimes this is not what you want. In this chat app, typing a message and then switching the recipient does not reset the input. This can make the user accidentally send a message to the wrong person:
308308

@@ -399,7 +399,7 @@ textarea {
399399

400400
</Sandpack>
401401

402-
React lets you override the default behavior, and *force* a component to reset its state by passing it a different `key`, like `<Chat key={email} />`. This tells React that if the recipient is different, it should be considered a *different* `Chat` component that needs to be re-created from scratch with the new data (and UI like inputs). Now switching between the recipients resets the input field--even though you render the same component.
402+
React lets you override the default behavior, and *force* a Component to reset its State by passing it a different `key`, like `<Chat key={email} />`. This tells React that if the recipient is different, it should be considered a *different* `Chat` Component that needs to be re-created from scratch with the new data (and UI like inputs). Now switching between the recipients resets the input field--even though you render the same Component.
403403

404404
<Sandpack>
405405

@@ -496,13 +496,13 @@ textarea {
496496

497497
<LearnMore path="/learn/preserving-and-resetting-state">
498498

499-
Read **[Preserving and Resetting State](/learn/preserving-and-resetting-state)** to learn the lifetime of state and how to control it.
499+
Read **[Preserving and Resetting State](/learn/preserving-and-resetting-state)** to learn the lifetime of State and how to control it.
500500

501501
</LearnMore>
502502

503-
## Extracting state logic into a reducer {/*extracting-state-logic-into-a-reducer*/}
503+
## Extracting State Logic into a Reducer {/*extracting-state-logic-into-a-reducer*/}
504504

505-
Components with many state updates spread across many event handlers can get overwhelming. For these cases, you can consolidate all the state update logic outside your component in a single function, called "reducer". Your event handlers become concise because they only specify the user "actions". At the bottom of the file, the reducer function specifies how the state should update in response to each action!
505+
Components with many State updates spread across many event handlers can get overwhelming. For these cases, you can consolidate all the State update logic outside your Component in a single function, called "reducer". Your event handlers become concise because they only specify the user "actions". At the bottom of the file, the reducer function specifies how the State should update in response to each action!
506506

507507
<Sandpack>
508508

@@ -697,11 +697,11 @@ Read **[Extracting State Logic into a Reducer](/learn/extracting-state-logic-int
697697
698698
</LearnMore>
699699
700-
## Passing data deeply with context {/*passing-data-deeply-with-context*/}
700+
## Passing Data Deeply with Context {/*passing-data-deeply-with-context*/}
701701
702-
Usually, you will pass information from a parent component to a child component via props. But passing props can become inconvenient if you need to pass some prop through many components, or if many components need the same information. Context lets the parent component make some information available to any component in the tree below it—no matter how deep it is—without passing it explicitly through props.
702+
Usually, you will pass information from a parent Component to a child Component via props. But passing props can become inconvenient if you need to pass some prop through many Components, or if many Components need the same information. Context lets the parent Component make some information available to any Component in the tree below it—no matter how deep it is—without passing it explicitly through props.
703703
704-
Here, the `Heading` component determines its heading level by "asking" the closest `Section` for its level. Each `Section` tracks its own level by asking the parent `Section` and adding one to it. Every `Section` provides information to all components below it without passing props--it does that through context.
704+
Here, the `Heading` Component determines its heading level by "asking" the closest `Section` for its level. Each `Section` tracks its own level by asking the parent `Section` and adding one to it. Every `Section` provides information to all Components below it without passing props--it does that through Context.
705705
706706
<Sandpack>
707707
@@ -795,15 +795,15 @@ export const LevelContext = createContext(0);
795795
796796
<LearnMore path="/learn/passing-data-deeply-with-context">
797797
798-
Read **[Passing Data Deeply with Context](/learn/passing-data-deeply-with-context)** to learn about using context as an alternative to passing props.
798+
Read **[Passing Data Deeply with Context](/learn/passing-data-deeply-with-context)** to learn about using Context as an alternative to passing props.
799799
800800
</LearnMore>
801801
802-
## Scaling up with reducer and context {/*scaling-up-with-reducer-and-context*/}
802+
## Scaling Up with Reducer and Context {/*scaling-up-with-reducer-and-context*/}
803803
804-
Reducers let you consolidate a component’s state update logic. Context lets you pass information deep down to other components. You can combine reducers and context together to manage state of a complex screen.
804+
Reducers let you consolidate a Component’s State update logic. Context lets you pass information deep down to other Components. You can combine reducers and Context together to manage State of a complex screen.
805805
806-
With this approach, a parent component with complex state manages it with a reducer. Other components anywhere deep in the tree can read its state via context. They can also dispatch actions to update that state.
806+
With this approach, a parent Component with complex State manages it with a reducer. Other Components anywhere deep in the tree can read its State via Context. They can also dispatch actions to update that State.
807807
808808
<Sandpack>
809809
@@ -1004,11 +1004,11 @@ ul, li { margin: 0; padding: 0; }
10041004
10051005
<LearnMore path="/learn/scaling-up-with-reducer-and-context">
10061006
1007-
Read **[Scaling Up with Reducer and Context](/learn/scaling-up-with-reducer-and-context)** to learn how state management scales in a growing app.
1007+
Read **[Scaling Up with Reducer and Context](/learn/scaling-up-with-reducer-and-context)** to learn how State management scales in a growing app.
10081008
10091009
</LearnMore>
10101010
1011-
## What's next? {/*whats-next*/}
1011+
## What's Next? {/*whats-next*/}
10121012
10131013
Head over to [Reacting to Input with State](/learn/reacting-to-input-with-state) to start reading this chapter page by page!
10141014

0 commit comments

Comments
 (0)