React.js • Chapter 11 • Foundations to Advanced
Sharing State Between Components
Study each React concept through explanations, focused examples, code, reasoning, expected behavior, practice, and review.
11.1 Lifting State Up
State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place. In Chapter 11, the purpose is to make the behavior observable rather than memorizing an API. Follow the value from its source through the component tree and identify what React needs in order to produce the next interface. This section 11.1 connects the idea directly to Sharing State Between Components.
For Lifting State Up, inspect initial state, update timing, immutable changes, and the next render. A reliable React design makes ownership explicit, keeps rendering predictable, and separates calculations from synchronization with external systems. When a feature seems complicated, reduce it to one component, one state change, or one boundary and rebuild from that verified behavior. In Sharing State Between Components, keep the Lifting State Up responsibility visible while you test it.
This topic emphasizes structure. Use complete states for loading, success, empty data, and failure when those states can occur. After the example works, explain why React rendered what you see and which change would cause another render; that reasoning is more valuable than copying syntax. For section 11.1, relate that explanation back to Lifting State Up.
Key terms in plain language
- Render — React evaluating components to describe what the screen should show.
- Lifting — a focused part of lifting state up used to describe one responsibility, input, rendering decision, or boundary in the interface.
- State — a focused part of lifting state up used to describe one responsibility, input, rendering decision, or boundary in the interface.
10 teaching examples
Example 1: Two-component comparison
Build one version of the Search panel with the Lifting State Up responsibility in the parent and another with it in the child. Compare data ownership, reuse, and how many components need to know about the decision. State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
Example 2: Failure or edge case
Create a safe edge case for Lifting State Up in the Shopping cart: empty data, a missing prop, a rejected request, rapid clicks, or an unmounted element. Show the user a clear state instead of allowing confusing or stale output.
Example 3: Accessibility check
Use Lifting State Up in the Dashboard filter while testing keyboard access, semantic markup, labels, focus order, and understandable status feedback. React does not replace browser accessibility rules, so verify the generated interface.
Example 4: State ownership check
For the Message composer, identify which component truly owns the information involved in Lifting State Up. Remove duplicated state and derive values during rendering when they can be calculated from existing props or state. State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
Example 5: Network-delay scenario
Assume the Appointment form is waiting on a slow API while using Lifting State Up. Decide what stays interactive, what shows pending feedback, what can be cancelled, and how stale responses are prevented from replacing newer data.
Example 6: Refactoring exercise
Take a large Photo gallery component that mixes Lifting State Up with unrelated concerns. Extract one focused component or custom hook, give it a narrow API, and confirm that the user-visible behavior stays the same.
Example 7: Performance experiment
Profile the Task board before optimizing Lifting State Up. Record which components render, what calculation is costly, and whether the delay is actually noticeable; apply an optimization only when the measurement supports it. State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
Example 8: Production review
Assume the Notification center feature using Lifting State Up ships to many devices and languages. Review error recovery, loading states, accessibility, RTL layout, small-screen width, security boundaries, and whether monitoring can reveal failures.
Example 9: Smallest useful case
Create the smallest working version of Lifting State Up inside a Course catalog. Keep one input and one visible result, then describe initial state, update timing, immutable changes, and the next render. This gives you a baseline before extra features hide the important behavior. State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
Example 10: Change one input
Keep the Profile settings example stable but change one input that affects Lifting State Up. Predict what React will render before running the code, then compare the result with your prediction and explain the render path.
React coding example
import { useState } from 'react';
export default function TopicDemo() {
const [count, setCount] = useState(0);
return (
<section>
<h2>{"Lifting State Up"}</h2>
<p>Interactions: {count}</p>
<button onClick={() => setCount(value => value + 1)}>
Update interface
</button>
</section>
);
}Step-by-step code explanation
- Identify the responsibility demonstrated by Lifting State Up.
- Read the component from inputs to returned JSX before focusing on individual syntax.
- Trace which event, prop, promise, or state update can cause the visible result to change.
- Test one normal path and one edge case so the behavior is not inferred from the happy path alone.
- Keep the example small enough that you can explain every render and every external side effect.
Expected behavior: A small React interface demonstrating Lifting State Up; the exact browser text depends on the interaction or data used in the example.
Practice exercise
Create a small interface focused on Lifting State Up. Write the expected screen state before running it, test one edge case, and change one input or interaction. Then explain which component owns the relevant data, what caused the render, and one accessibility or small-screen check you would perform before shipping the feature. Record the result as the Chapter 11 practice for Sharing State Between Components.
11.2 Single Source of Truth
Single Source of Truth is best understood through render: React evaluating components to describe what the screen should show. Focus on state changes, props, event flow, list identity, and predictable re-rendering. In Chapter 11, the purpose is to make the behavior observable rather than memorizing an API. Follow the value from its source through the component tree and identify what React needs in order to produce the next interface. This section 11.2 connects the idea directly to Sharing State Between Components.
For Single Source of Truth, inspect inputs, component ownership, visible output, edge cases, and the reason another render occurs. A reliable React design makes ownership explicit, keeps rendering predictable, and separates calculations from synchronization with external systems. When a feature seems complicated, reduce it to one component, one state change, or one boundary and rebuild from that verified behavior. In Sharing State Between Components, keep the Single Source of Truth responsibility visible while you test it.
This topic emphasizes data flow. Use complete states for loading, success, empty data, and failure when those states can occur. After the example works, explain why React rendered what you see and which change would cause another render; that reasoning is more valuable than copying syntax. For section 11.2, relate that explanation back to Single Source of Truth.
Key terms in plain language
- Render — React evaluating components to describe what the screen should show.
- Single — a focused part of single source of truth used to describe one responsibility, input, rendering decision, or boundary in the interface.
- Source — a focused part of single source of truth used to describe one responsibility, input, rendering decision, or boundary in the interface.
- Truth — a focused part of single source of truth used to describe one responsibility, input, rendering decision, or boundary in the interface.
10 teaching examples
Example 1: Failure or edge case
Create a safe edge case for Single Source of Truth in the Appointment form: empty data, a missing prop, a rejected request, rapid clicks, or an unmounted element. Show the user a clear state instead of allowing confusing or stale output.
Example 2: Accessibility check
Use Single Source of Truth in the Photo gallery while testing keyboard access, semantic markup, labels, focus order, and understandable status feedback. React does not replace browser accessibility rules, so verify the generated interface.
Example 3: State ownership check
For the Task board, identify which component truly owns the information involved in Single Source of Truth. Remove duplicated state and derive values during rendering when they can be calculated from existing props or state. Single Source of Truth is best understood through render: React evaluating components to describe what the screen should show. Focus on state changes, props, event flow, list identity, and predictable re-rendering.
Example 4: Network-delay scenario
Assume the Notification center is waiting on a slow API while using Single Source of Truth. Decide what stays interactive, what shows pending feedback, what can be cancelled, and how stale responses are prevented from replacing newer data.
Example 5: Refactoring exercise
Take a large Quiz screen component that mixes Single Source of Truth with unrelated concerns. Extract one focused component or custom hook, give it a narrow API, and confirm that the user-visible behavior stays the same.
Example 6: Performance experiment
Profile the Language selector before optimizing Single Source of Truth. Record which components render, what calculation is costly, and whether the delay is actually noticeable; apply an optimization only when the measurement supports it. Single Source of Truth is best understood through render: React evaluating components to describe what the screen should show. Focus on state changes, props, event flow, list identity, and predictable re-rendering.
Example 7: Production review
Assume the Account menu feature using Single Source of Truth ships to many devices and languages. Review error recovery, loading states, accessibility, RTL layout, small-screen width, security boundaries, and whether monitoring can reveal failures.
Example 8: Smallest useful case
Create the smallest working version of Single Source of Truth inside a Shopping cart. Keep one input and one visible result, then describe inputs, component ownership, visible output, edge cases, and the reason another render occurs. This gives you a baseline before extra features hide the important behavior. Single Source of Truth is best understood through render: React evaluating components to describe what the screen should show. Focus on state changes, props, event flow, list identity, and predictable re-rendering.
Example 9: Change one input
Keep the Dashboard filter example stable but change one input that affects Single Source of Truth. Predict what React will render before running the code, then compare the result with your prediction and explain the render path.
Example 10: Two-component comparison
Build one version of the Message composer with the Single Source of Truth responsibility in the parent and another with it in the child. Compare data ownership, reuse, and how many components need to know about the decision. Single Source of Truth is best understood through render: React evaluating components to describe what the screen should show. Focus on state changes, props, event flow, list identity, and predictable re-rendering.
React coding example
import { useState } from 'react';
export default function TopicDemo() {
const [count, setCount] = useState(0);
return (
<section>
<h2>{"Single Source of Truth"}</h2>
<p>Interactions: {count}</p>
<button onClick={() => setCount(value => value + 1)}>
Update interface
</button>
</section>
);
}Step-by-step code explanation
- Identify the responsibility demonstrated by Single Source of Truth.
- Read the component from inputs to returned JSX before focusing on individual syntax.
- Trace which event, prop, promise, or state update can cause the visible result to change.
- Test one normal path and one edge case so the behavior is not inferred from the happy path alone.
- Keep the example small enough that you can explain every render and every external side effect.
Expected behavior: A small React interface demonstrating Single Source of Truth; the exact browser text depends on the interaction or data used in the example.
Practice exercise
Create a small interface focused on Single Source of Truth. Write the expected screen state before running it, test one edge case, and change one input or interaction. Then explain which component owns the relevant data, what caused the render, and one accessibility or small-screen check you would perform before shipping the feature. Record the result as the Chapter 11 practice for Sharing State Between Components.
11.3 Passing State Down
State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place. In Chapter 11, the purpose is to make the behavior observable rather than memorizing an API. Follow the value from its source through the component tree and identify what React needs in order to produce the next interface. This section 11.3 connects the idea directly to Sharing State Between Components.
For Passing State Down, inspect initial state, update timing, immutable changes, and the next render. A reliable React design makes ownership explicit, keeps rendering predictable, and separates calculations from synchronization with external systems. When a feature seems complicated, reduce it to one component, one state change, or one boundary and rebuild from that verified behavior. In Sharing State Between Components, keep the Passing State Down responsibility visible while you test it.
This topic emphasizes edge cases. Use complete states for loading, success, empty data, and failure when those states can occur. After the example works, explain why React rendered what you see and which change would cause another render; that reasoning is more valuable than copying syntax. For section 11.3, relate that explanation back to Passing State Down.
Key terms in plain language
- Render — React evaluating components to describe what the screen should show.
- Passing — a focused part of passing state down used to describe one responsibility, input, rendering decision, or boundary in the interface.
- State — a focused part of passing state down used to describe one responsibility, input, rendering decision, or boundary in the interface.
- Down — a focused part of passing state down used to describe one responsibility, input, rendering decision, or boundary in the interface.
10 teaching examples
Example 1: Accessibility check
Use Passing State Down in the Quiz screen while testing keyboard access, semantic markup, labels, focus order, and understandable status feedback. React does not replace browser accessibility rules, so verify the generated interface.
Example 2: State ownership check
For the Language selector, identify which component truly owns the information involved in Passing State Down. Remove duplicated state and derive values during rendering when they can be calculated from existing props or state. State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
Example 3: Network-delay scenario
Assume the Account menu is waiting on a slow API while using Passing State Down. Decide what stays interactive, what shows pending feedback, what can be cancelled, and how stale responses are prevented from replacing newer data.
Example 4: Refactoring exercise
Take a large Data table component that mixes Passing State Down with unrelated concerns. Extract one focused component or custom hook, give it a narrow API, and confirm that the user-visible behavior stays the same.
Example 5: Performance experiment
Profile the Upload panel before optimizing Passing State Down. Record which components render, what calculation is costly, and whether the delay is actually noticeable; apply an optimization only when the measurement supports it. State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
Example 6: Production review
Assume the Team roster feature using Passing State Down ships to many devices and languages. Review error recovery, loading states, accessibility, RTL layout, small-screen width, security boundaries, and whether monitoring can reveal failures.
Example 7: Smallest useful case
Create the smallest working version of Passing State Down inside a Appointment form. Keep one input and one visible result, then describe initial state, update timing, immutable changes, and the next render. This gives you a baseline before extra features hide the important behavior. State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
Example 8: Change one input
Keep the Photo gallery example stable but change one input that affects Passing State Down. Predict what React will render before running the code, then compare the result with your prediction and explain the render path.
Example 9: Two-component comparison
Build one version of the Task board with the Passing State Down responsibility in the parent and another with it in the child. Compare data ownership, reuse, and how many components need to know about the decision. State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
Example 10: Failure or edge case
Create a safe edge case for Passing State Down in the Notification center: empty data, a missing prop, a rejected request, rapid clicks, or an unmounted element. Show the user a clear state instead of allowing confusing or stale output.
React coding example
import { useState } from 'react';
export default function TopicDemo() {
const [count, setCount] = useState(0);
return (
<section>
<h2>{"Passing State Down"}</h2>
<p>Interactions: {count}</p>
<button onClick={() => setCount(value => value + 1)}>
Update interface
</button>
</section>
);
}Step-by-step code explanation
- Identify the responsibility demonstrated by Passing State Down.
- Read the component from inputs to returned JSX before focusing on individual syntax.
- Trace which event, prop, promise, or state update can cause the visible result to change.
- Test one normal path and one edge case so the behavior is not inferred from the happy path alone.
- Keep the example small enough that you can explain every render and every external side effect.
Expected behavior: A small React interface demonstrating Passing State Down; the exact browser text depends on the interaction or data used in the example.
Practice exercise
Create a small interface focused on Passing State Down. Write the expected screen state before running it, test one edge case, and change one input or interaction. Then explain which component owns the relevant data, what caused the render, and one accessibility or small-screen check you would perform before shipping the feature. Record the result as the Chapter 11 practice for Sharing State Between Components.
11.4 Passing Updates Up
Passing Updates Up is best understood through render: React evaluating components to describe what the screen should show. Focus on state changes, props, event flow, list identity, and predictable re-rendering. In Chapter 11, the purpose is to make the behavior observable rather than memorizing an API. Follow the value from its source through the component tree and identify what React needs in order to produce the next interface. This section 11.4 connects the idea directly to Sharing State Between Components.
For Passing Updates Up, inspect inputs, component ownership, visible output, edge cases, and the reason another render occurs. A reliable React design makes ownership explicit, keeps rendering predictable, and separates calculations from synchronization with external systems. When a feature seems complicated, reduce it to one component, one state change, or one boundary and rebuild from that verified behavior. In Sharing State Between Components, keep the Passing Updates Up responsibility visible while you test it.
This topic emphasizes accessibility. Use complete states for loading, success, empty data, and failure when those states can occur. After the example works, explain why React rendered what you see and which change would cause another render; that reasoning is more valuable than copying syntax. For section 11.4, relate that explanation back to Passing Updates Up.
Key terms in plain language
- Render — React evaluating components to describe what the screen should show.
- Passing — a focused part of passing updates up used to describe one responsibility, input, rendering decision, or boundary in the interface.
- Updates — a focused part of passing updates up used to describe one responsibility, input, rendering decision, or boundary in the interface.
10 teaching examples
Example 1: State ownership check
For the Upload panel, identify which component truly owns the information involved in Passing Updates Up. Remove duplicated state and derive values during rendering when they can be calculated from existing props or state. Passing Updates Up is best understood through render: React evaluating components to describe what the screen should show. Focus on state changes, props, event flow, list identity, and predictable re-rendering.
Example 2: Network-delay scenario
Assume the Team roster is waiting on a slow API while using Passing Updates Up. Decide what stays interactive, what shows pending feedback, what can be cancelled, and how stale responses are prevented from replacing newer data.
Example 3: Refactoring exercise
Take a large Analytics card component that mixes Passing Updates Up with unrelated concerns. Extract one focused component or custom hook, give it a narrow API, and confirm that the user-visible behavior stays the same.
Example 4: Performance experiment
Profile the Booking flow before optimizing Passing Updates Up. Record which components render, what calculation is costly, and whether the delay is actually noticeable; apply an optimization only when the measurement supports it. Passing Updates Up is best understood through render: React evaluating components to describe what the screen should show. Focus on state changes, props, event flow, list identity, and predictable re-rendering.
Example 5: Production review
Assume the Support ticket feature using Passing Updates Up ships to many devices and languages. Review error recovery, loading states, accessibility, RTL layout, small-screen width, security boundaries, and whether monitoring can reveal failures.
Example 6: Smallest useful case
Create the smallest working version of Passing Updates Up inside a Notification center. Keep one input and one visible result, then describe inputs, component ownership, visible output, edge cases, and the reason another render occurs. This gives you a baseline before extra features hide the important behavior. Passing Updates Up is best understood through render: React evaluating components to describe what the screen should show. Focus on state changes, props, event flow, list identity, and predictable re-rendering.
Example 7: Change one input
Keep the Quiz screen example stable but change one input that affects Passing Updates Up. Predict what React will render before running the code, then compare the result with your prediction and explain the render path.
Example 8: Two-component comparison
Build one version of the Language selector with the Passing Updates Up responsibility in the parent and another with it in the child. Compare data ownership, reuse, and how many components need to know about the decision. Passing Updates Up is best understood through render: React evaluating components to describe what the screen should show. Focus on state changes, props, event flow, list identity, and predictable re-rendering.
Example 9: Failure or edge case
Create a safe edge case for Passing Updates Up in the Account menu: empty data, a missing prop, a rejected request, rapid clicks, or an unmounted element. Show the user a clear state instead of allowing confusing or stale output.
Example 10: Accessibility check
Use Passing Updates Up in the Data table while testing keyboard access, semantic markup, labels, focus order, and understandable status feedback. React does not replace browser accessibility rules, so verify the generated interface.
React coding example
import { useState } from 'react';
export default function TopicDemo() {
const [count, setCount] = useState(0);
return (
<section>
<h2>{"Passing Updates Up"}</h2>
<p>Interactions: {count}</p>
<button onClick={() => setCount(value => value + 1)}>
Update interface
</button>
</section>
);
}Step-by-step code explanation
- Identify the responsibility demonstrated by Passing Updates Up.
- Read the component from inputs to returned JSX before focusing on individual syntax.
- Trace which event, prop, promise, or state update can cause the visible result to change.
- Test one normal path and one edge case so the behavior is not inferred from the happy path alone.
- Keep the example small enough that you can explain every render and every external side effect.
Expected behavior: A small React interface demonstrating Passing Updates Up; the exact browser text depends on the interaction or data used in the example.
Practice exercise
Create a small interface focused on Passing Updates Up. Write the expected screen state before running it, test one edge case, and change one input or interaction. Then explain which component owns the relevant data, what caused the render, and one accessibility or small-screen check you would perform before shipping the feature. Record the result as the Chapter 11 practice for Sharing State Between Components.
11.5 Avoiding Duplicate State
State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place. In Chapter 11, the purpose is to make the behavior observable rather than memorizing an API. Follow the value from its source through the component tree and identify what React needs in order to produce the next interface. This section 11.5 connects the idea directly to Sharing State Between Components.
For Avoiding Duplicate State, inspect initial state, update timing, immutable changes, and the next render. A reliable React design makes ownership explicit, keeps rendering predictable, and separates calculations from synchronization with external systems. When a feature seems complicated, reduce it to one component, one state change, or one boundary and rebuild from that verified behavior. In Sharing State Between Components, keep the Avoiding Duplicate State responsibility visible while you test it.
This topic emphasizes production behavior. Use complete states for loading, success, empty data, and failure when those states can occur. After the example works, explain why React rendered what you see and which change would cause another render; that reasoning is more valuable than copying syntax. For section 11.5, relate that explanation back to Avoiding Duplicate State.
Key terms in plain language
- Render — React evaluating components to describe what the screen should show.
- Avoiding — a focused part of avoiding duplicate state used to describe one responsibility, input, rendering decision, or boundary in the interface.
- Duplicate — a focused part of avoiding duplicate state used to describe one responsibility, input, rendering decision, or boundary in the interface.
- State — a focused part of avoiding duplicate state used to describe one responsibility, input, rendering decision, or boundary in the interface.
10 teaching examples
Example 1: Network-delay scenario
Assume the Support ticket is waiting on a slow API while using Avoiding Duplicate State. Decide what stays interactive, what shows pending feedback, what can be cancelled, and how stale responses are prevented from replacing newer data.
Example 2: Refactoring exercise
Take a large Lesson tracker component that mixes Avoiding Duplicate State with unrelated concerns. Extract one focused component or custom hook, give it a narrow API, and confirm that the user-visible behavior stays the same.
Example 3: Performance experiment
Profile the Course catalog before optimizing Avoiding Duplicate State. Record which components render, what calculation is costly, and whether the delay is actually noticeable; apply an optimization only when the measurement supports it. State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
Example 4: Production review
Assume the Profile settings feature using Avoiding Duplicate State ships to many devices and languages. Review error recovery, loading states, accessibility, RTL layout, small-screen width, security boundaries, and whether monitoring can reveal failures.
Example 5: Smallest useful case
Create the smallest working version of Avoiding Duplicate State inside a Account menu. Keep one input and one visible result, then describe initial state, update timing, immutable changes, and the next render. This gives you a baseline before extra features hide the important behavior. State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
Example 6: Change one input
Keep the Data table example stable but change one input that affects Avoiding Duplicate State. Predict what React will render before running the code, then compare the result with your prediction and explain the render path.
Example 7: Two-component comparison
Build one version of the Upload panel with the Avoiding Duplicate State responsibility in the parent and another with it in the child. Compare data ownership, reuse, and how many components need to know about the decision. State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
Example 8: Failure or edge case
Create a safe edge case for Avoiding Duplicate State in the Team roster: empty data, a missing prop, a rejected request, rapid clicks, or an unmounted element. Show the user a clear state instead of allowing confusing or stale output.
Example 9: Accessibility check
Use Avoiding Duplicate State in the Analytics card while testing keyboard access, semantic markup, labels, focus order, and understandable status feedback. React does not replace browser accessibility rules, so verify the generated interface.
Example 10: State ownership check
For the Booking flow, identify which component truly owns the information involved in Avoiding Duplicate State. Remove duplicated state and derive values during rendering when they can be calculated from existing props or state. State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
React coding example
import { useState } from 'react';
export default function TopicDemo() {
const [count, setCount] = useState(0);
return (
<section>
<h2>{"Avoiding Duplicate State"}</h2>
<p>Interactions: {count}</p>
<button onClick={() => setCount(value => value + 1)}>
Update interface
</button>
</section>
);
}Step-by-step code explanation
- Identify the responsibility demonstrated by Avoiding Duplicate State.
- Read the component from inputs to returned JSX before focusing on individual syntax.
- Trace which event, prop, promise, or state update can cause the visible result to change.
- Test one normal path and one edge case so the behavior is not inferred from the happy path alone.
- Keep the example small enough that you can explain every render and every external side effect.
Expected behavior: A small React interface demonstrating Avoiding Duplicate State; the exact browser text depends on the interaction or data used in the example.
Practice exercise
Create a small interface focused on Avoiding Duplicate State. Write the expected screen state before running it, test one edge case, and change one input or interaction. Then explain which component owns the relevant data, what caused the render, and one accessibility or small-screen check you would perform before shipping the feature. Record the result as the Chapter 11 practice for Sharing State Between Components.
Chapter 11 review — 20 questions and answers
1. What problem does Lifting State Up help solve in this chapter?
Answer: State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
2. What should you inspect when Lifting State Up does not behave as expected?
Answer: Check initial state, update timing, immutable changes, and the next render. Reduce the example until you can identify the input, render decision, update, and visible result.
3. How can you practice Lifting State Up without copying a large application?
Answer: Build a small component focused on Lifting State Up, predict its output, change one condition, and explain why React renders the new result.
4. What production concern belongs with Lifting State Up?
Answer: Review error recovery, accessibility, performance, security boundaries, localization, and small-screen behavior according to what Lifting State Up touches.
5. What problem does Single Source of Truth help solve in this chapter?
Answer: Single Source of Truth is best understood through render: React evaluating components to describe what the screen should show. Focus on state changes, props, event flow, list identity, and predictable re-rendering.
6. What should you inspect when Single Source of Truth does not behave as expected?
Answer: Check inputs, component ownership, visible output, edge cases, and the reason another render occurs. Reduce the example until you can identify the input, render decision, update, and visible result.
7. How can you practice Single Source of Truth without copying a large application?
Answer: Build a small component focused on Single Source of Truth, predict its output, change one condition, and explain why React renders the new result.
8. What production concern belongs with Single Source of Truth?
Answer: Review error recovery, accessibility, performance, security boundaries, localization, and small-screen behavior according to what Single Source of Truth touches.
9. What problem does Passing State Down help solve in this chapter?
Answer: State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
10. What should you inspect when Passing State Down does not behave as expected?
Answer: Check initial state, update timing, immutable changes, and the next render. Reduce the example until you can identify the input, render decision, update, and visible result.
11. How can you practice Passing State Down without copying a large application?
Answer: Build a small component focused on Passing State Down, predict its output, change one condition, and explain why React renders the new result.
12. What production concern belongs with Passing State Down?
Answer: Review error recovery, accessibility, performance, security boundaries, localization, and small-screen behavior according to what Passing State Down touches.
13. What problem does Passing Updates Up help solve in this chapter?
Answer: Passing Updates Up is best understood through render: React evaluating components to describe what the screen should show. Focus on state changes, props, event flow, list identity, and predictable re-rendering.
14. What should you inspect when Passing Updates Up does not behave as expected?
Answer: Check inputs, component ownership, visible output, edge cases, and the reason another render occurs. Reduce the example until you can identify the input, render decision, update, and visible result.
15. How can you practice Passing Updates Up without copying a large application?
Answer: Build a small component focused on Passing Updates Up, predict its output, change one condition, and explain why React renders the new result.
16. What production concern belongs with Passing Updates Up?
Answer: Review error recovery, accessibility, performance, security boundaries, localization, and small-screen behavior according to what Passing Updates Up touches.
17. What problem does Avoiding Duplicate State help solve in this chapter?
Answer: State is component memory that persists between renders. Updating state schedules another render rather than changing the current render in place.
18. What should you inspect when Avoiding Duplicate State does not behave as expected?
Answer: Check initial state, update timing, immutable changes, and the next render. Reduce the example until you can identify the input, render decision, update, and visible result.
19. How can you practice Avoiding Duplicate State without copying a large application?
Answer: Build a small component focused on Avoiding Duplicate State, predict its output, change one condition, and explain why React renders the new result.
20. What production concern belongs with Avoiding Duplicate State?
Answer: Review error recovery, accessibility, performance, security boundaries, localization, and small-screen behavior according to what Avoiding Duplicate State touches.