One status instead of two booleans
Type a message and send it. The status moves typing → sending → sent and can never be two things at once. isSending and charsLeft are calculated, so they can't drift.
Good state has no room for bugs: group values that change together, replace clashing booleans with one status, don't store what you can calculate, don't keep copies of data you already have (store its id), and keep nested data flat.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 5 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
A component has const [firstName, setFirstName] = useState(""), const [lastName, setLastName] = useState("") and const [fullName, setFullName] = useState(""), and every change handler also updates fullName. Simplify it.
A traffic light component uses isRed, isYellow and isGreen booleans. Rewrite its state with one variable and a button that moves to the next light (green → yellow → red → green).
Explain it without notes
Name the five principles for structuring state and give a one-line example of each.
Why is one status variable better than several booleans? How do you keep readable names like isSending?
Why should you store a selected item's id instead of the item itself?
What is normalised state, and when is it worth it?
Preview
Console
Nothing logged yet.Expected console output
status: typing