Reacting to input with state

A coupon box that locks you out

A checkout page often has a box for a coupon code. You type a code, press Apply, and the shop asks its server whether the code is real. While it waits, the form should say so. Then it either shows the discount or explains what went wrong. Here is that box written with plain JavaScript, changing the page by hand. The result is live. Type TEA5 in the box, press Apply, and wait one second:

1const form = document.querySelector("#coupon-form");2const input = document.querySelector("#code");3const button = document.querySelector("#apply");4const checking = document.querySelector("#checking");5const errorText = document.querySelector("#error");6const success = document.querySelector("#success");7 8async function handleSubmit(e) {9  e.preventDefault();10  input.disabled = true;11  button.disabled = true;12  checking.hidden = false;13  errorText.hidden = true;14  try {15    await checkCoupon(input.value);16    form.hidden = true;17    success.textContent = "Coupon " + input.value + " applied: 10% off.";18    success.hidden = false;19  } catch (err) {20    checking.hidden = true;21    errorText.textContent = err.message;22    errorText.hidden = false;23    button.disabled = false;24  }25}26 27function handleInput() {28  button.disabled = input.value.length === 0;29}30 31form.addEventListener("submit", handleSubmit);32input.addEventListener("input", handleInput);

Lines 1 to 6 find the six parts of the page. handleSubmit (lines 8 to 25) runs when you press Apply. Line 9 stops the browser from sending the form and loading a new page. Lines 10 to 13 turn the box and the button off and show "Checking your code…". Line 15 waits for the pretend server in the api.js tab: it answers after one second, accepts TEA10, and refuses anything else. If it accepts, lines 16 to 18 hide the form and show the discount. If it refuses, lines 20 to 23 hide the waiting message, show the error, and turn Apply back on.

Now try to fix your code. You can't: the box is still grey. Nothing on lines 20 to 23 turns the box back on, so the page asks you to check your code and won't let you change it. The bug is on purpose here, and it's the kind that hand-written page updates are full of: each event lists its own changes, and one list missed one.

You met this problem with a shopping cart in Why React?. A form makes it worse, because a form has many looks: empty, being typed in, waiting for the server, done, or showing an error. Here is the same box in React. Try TEA5 again, then change it to TEA10 and press Apply:

1import { useState } from "react";2import { checkCoupon } from "./api.js";3 4export default function App() {5  const [code, setCode] = useState("");6  const [error, setError] = useState(null);7  const [status, setStatus] = useState("typing");8 9  if (status === "success") {10    return <p>Coupon {code} applied: 10% off.</p>;11  }12 13  async function handleSubmit(e) {14    e.preventDefault();15    setStatus("submitting");16    setError(null);17    try {18      await checkCoupon(code);19      setStatus("success");20    } catch (err) {21      setStatus("typing");22      setError(err);23    }24  }25 26  return (27    <form onSubmit={handleSubmit}>28      <label>29        Coupon code{" "}30        <input31          value={code}32          onChange={(e) => setCode(e.target.value)}33          disabled={status === "submitting"}34        />35      </label>36      <button disabled={code.length === 0 || status === "submitting"}>Apply</button>37      {status === "submitting" && <p>Checking your code…</p>}38      {error !== null && <p>{error.message}</p>}39    </form>40  );41}

This time you can fix the code after the error. Lines 5 to 7 keep three pieces of state: what's in the box, the last error, and a status that names what the form is doing. The JSX below them doesn't give the page orders. Line 33 describes the box: it's off while status is "submitting", and on the rest of the time. There is no line that turns it back on, because there is nothing to forget. Every render works the box out again from the state.

That's the idea of this lesson. In React you don't change parts of the page in response to events. You describe each look the component can have, and when something happens, you set state to pick a look. The rest of the lesson builds this form step by step, the way you would build any form in React.

Commands for each event, or a description of each look

The by-hand box is imperative: each handler gives the page a list of commands for one event. "Turn the box off. Turn Apply off. Show the waiting message." The React box is declarative: each part of the page says what it looks like for any state. To see the difference, follow each part of the form through both versions. Each row is one part of the form; the middle column lists the by-hand lines that change it, and the last column the React line that describes it:

By hand, the box is changed in one place, and needed two. Apply is changed in three places, in two different handlers. Every new event, like a "Remove coupon" button, would need its own list of commands, and each list has to know the state that every other list left behind. With React, each part has one line, and that line covers every look at once. Adding a new event means setting state; the descriptions already handle it.

Both versions end up making the same kind of DOM change. React turns the box off and on for you (it adds or removes the disabled attribute), after it compares the new description with the last one. Render and commit follows those steps.

Step 1: list every look the form can have

Before you write any logic, list the looks a user can see. Designers call them visual states. For the coupon form there are five:

• Empty: the box is empty, so Apply is off.
• Typing: there is a code in the box, so Apply is on.
• Submitting: the box and Apply are off, and the form says it's checking.
• Success: the form is gone, and a message says the coupon is applied.
• Error: like Typing, with the server's error message under the form.

Then draw each look, with no logic yet. In React, a quick way to draw them is a mock: a component that takes the look as a prop and shows it. Here status is a prop with a default value, "empty":

1export default function CouponForm({ status = "empty" }) {2  if (status === "success") {3    return <p>Coupon TEA10 applied: 10% off.</p>;4  }5  return (6    <form onSubmit={(e) => e.preventDefault()}>7      <label>8        Coupon code <input disabled={status === "submitting"} />9      </label>10      <button disabled={status === "empty" || status === "submitting"}>Apply</button>11      {status === "submitting" && <p>Checking your code…</p>}12      {status === "error" && <p>That code isn't valid. Check it and try again.</p>}13    </form>14  );15}

Line 1 takes status and uses "empty" when no one passes it. Lines 2 to 4 return the success message instead of the form (an early return, from Conditional rendering). Line 6 stops the browser from sending the form, so pressing Apply in a mock does nothing. Line 8 turns the box off only while submitting. Line 10 turns Apply off when the box is empty or while submitting. Lines 11 and 12 show a message for two of the looks.

Press Edit & run and change "empty" on line 1 to "success". The result shows Coupon TEA10 applied: 10% off.. Try "error" and "submitting" too. You are checking the design before any of it works.

Or flip between the looks with the buttons below. The form is the same mock, rendered by React on this page; the highlighted lines are the ones whose condition is true for the look you pick, and the table reads what ended up on the page.

1export default function CouponForm({ status = "empty" }) {2  if (status === "success") {3    return <p>Coupon TEA10 applied: 10% off.</p>;4  }5  return (6    <form onSubmit={(e) => e.preventDefault()}>7      <label>8        Coupon code <input disabled={status === "submitting"} />9      </label>10      <button disabled={status === "empty" || status === "submitting"}>Apply</button>11      {status === "submitting" && <p>Checking your code…</p>}12      {status === "error" && <p>That code isn't valid. Check it and try again.</p>}13    </form>14  );15}

Pick Submitting: lines 8, 10, and 11 light up, so the box and Apply are off and the waiting message shows. Pick Typing: no line lights up. Every condition is false, which is exactly the look you want: both on, no message.

When a component has many looks, it helps to see them all at once. Render the mock once per look on one page. A page like this is called a living styleguide, because it shows the real component, not a picture of it:

1import CouponForm from "./CouponForm.jsx";2 3const statuses = ["empty", "typing", "submitting", "success", "error"];4 5export default function App() {6  return (7    <>8      {statuses.map((status) => (9        <section key={status}>10          <h4>Coupon form: {status}</h4>11          <CouponForm status={status} />12        </section>13      ))}14    </>15  );16}

The mock is now in the CouponForm.jsx tab, and App.jsx imports it on line 1. Line 3 lists the five looks. Lines 8 to 13 use map to draw a heading and a CouponForm for each one, with status as the key. Change line 10 of CouponForm.jsx, say to turn Apply off in the error look too, and all five forms update at once. Tools like Storybook are built on this idea.

Step 2: find what triggers each change

Next, find what moves the form from one look to another. Changes come from two kinds of input:

• Human inputs: the user types, clicks, or presses a key. You handle them with event handlers, from Responding to events.
• Computer inputs: the server answers, a timer ends, an image finishes loading. You handle them in the code that waits for them, like the code after await.

Either way, the screen changes only because the code sets state. For the coupon form, the changes are:

Read each row as "in this look, this happens, so the form moves to that look". A good way to check the list is to draw it: a card for each look and an arrow for each change.

The drawing also shows what can't happen. No arrow leaves Success: once the coupon is applied, the form is gone. No arrow goes from Empty to Submitting: Apply is off while the box is empty. And typing doesn't move the form out of Error: the message stays until you press Apply again. If you find an arrow that you didn't plan, you found a bug before writing any code.

Now watch the arrows happen. The form below is the overview's React coupon box, running on this page, and the log lists each change of look with the input that caused it:

Type TEA5: the first letter logs Empty to Typing, and the other letters log nothing, because the look stays Typing. Press Apply: a human input moves it to Submitting. One second later, a computer input, the server's answer, moves it to Error. Change the code to TEA10 and press Apply again: Error to Submitting, then Submitting to Success. Each line is one arrow in the drawing.

Steps 3 and 4: keep only the state you need

Now hold the looks in state with useState. Each piece of state is something that can change, and something that can go wrong, so you want as few as possible. A first try often has one true-or-false value, a boolean, per look, plus the code and the error. It covers every look, so it works:

1const [code, setCode] = useState("");2const [error, setError] = useState(null);3const [isEmpty, setIsEmpty] = useState(true);4const [isTyping, setIsTyping] = useState(false);5const [isSubmitting, setIsSubmitting] = useState(false);6const [isSuccess, setIsSuccess] = useState(false);7const [isError, setIsError] = useState(false);

Lines 1 and 2 keep the code and the last error. Lines 3 to 7 keep one boolean per look: isEmpty starts true, and the others start false. That's seven pieces of state, and every handler must set the right ones. Pressing Apply would need setIsTyping(false) and setIsSubmitting(true); an error would need setIsSubmitting(false), setIsError(true), and setError(err). Forget one, and the state says two things at once.

Five booleans can be set in 2 × 2 × 2 × 2 × 2 = 32 ways. Only 5 of them, where exactly one is true, are a look the form really has. The other 27 are impossible states: combinations the state allows, but that no user should ever see. Switch the booleans below and watch the form the first try would draw:

1if (isSuccess) {2  return <p>Coupon TEA10 applied: 10% off.</p>;3}4return (5  <form>6    <label>7      Coupon code <input disabled={isSubmitting} />8    </label>9    <button disabled={isEmpty || isSubmitting}>Apply</button>10    {isSubmitting && <p>Checking your code…</p>}11    {isError && <p>That code isn't valid. Check it and try again.</p>}12  </form>13);

Turn on isError while isSubmitting is on: the page shows the error and turns the box off, the same trap as the by-hand bug. Turn on isEmpty and isTyping together: Apply stays off while the box has a code. Notice too that isTyping changes nothing on the page: the drawing never reads it.

To remove the impossible states, ask three questions about each piece of state. Each row is one question, what it finds in the first try, and what to do about it:

After the clean-up, three pieces of state are left, down from seven:

1const [code, setCode] = useState("");2const [error, setError] = useState(null);3const [status, setStatus] = useState("typing"); // "typing", "submitting", or "success"

Line 1 keeps the code and line 2 the last error, as before. Line 3 replaces three booleans with one status that holds one of three strings. It can't be "typing" and "submitting" at once, because a variable holds one value. A set of names like this, one of which is chosen, is often called an enum. JavaScript has no enum type, so a string does the job; the comment lists the three allowed values.

The five looks are all still there. Each one is worked out from the three pieces:

• Empty: status is "typing" and code.length === 0.
• Typing: status is "typing", the box has a code, and error is null.
• Submitting and Success: status says so.
• Error: status is "typing" and error !== null.

Could error go into status as a fourth value, "error"? Yes, and that works well too. The message still needs a place, though, and it only makes sense in the error look. TypeScript can say exactly that with a discriminated union: a type with one shape per status, where only the error shape has a message. This one has an error on purpose:

1type CouponState =2  | { status: "typing" }3  | { status: "submitting" }4  | { status: "success" }5  | { status: "error"; message: string };6 7function messageFor(state: CouponState) {8  if (state.status === "error") {9    return state.message;10  }11  return state.message;12}

Lines 1 to 5 list the four shapes the state can have. Inside the if on line 8, TypeScript knows the status is "error", so line 9 may read message. Line 11 is outside it, where the state could be any of the other three, and TypeScript stops it: Property 'message' does not exist on type '{ status: "typing"; }'. That means the typing shape has no message to read. The impossible state, a message with no error, can't even be written. Typing state and hooks shows how to give useState a type like this.

Step 5: connect the handlers to the state

Last, make each trigger set state. Typing is one line: the box's onChange on line 32 of the overview's form calls setCode(e.target.value). Apply and the server's answer both live in handleSubmit, from lines 13 to 24 of that form:

1async function handleSubmit(e) {2  e.preventDefault();3  setStatus("submitting");4  setError(null);5  try {6    await checkCoupon(code);7    setStatus("success");8  } catch (err) {9    setStatus("typing");10    setError(err);11  }12}

Line 1 is the form's onSubmit handler. It's async, because it waits for the server. Line 2 stops the browser's own submit. Lines 3 and 4 handle the human input, Apply: the form moves to Submitting, and any old error goes. Line 6 waits. If the server accepts, line 7 sets "success". If it refuses, checkCoupon throws, and the catch block moves the form back to typing on line 9 and keeps the error on line 10.

Compare it with the by-hand handleSubmit. Neither branch mentions the box, the button, or the messages. Each one says which look comes next, and the JSX already knows what every look shows. Lines 9 and 10 can't forget to turn the box back on, because they don't turn anything on.

Lines 3 and 4 run together, before the await on line 6, so React renders them as one change. Lines 9 and 10 run together after it, and React batches them the same way, as Queueing a series of state updates showed. So the page never shows a half-set state, like Submitting with the old error still under it.

Reviews that load, built with the five steps

The same five steps work for anything that waits, not just forms. Here is a product page's reviews panel. You press a button, the reviews load from a server, and the panel shows them. The pretend server in the api.js tab fails the first time on purpose, as networks sometimes do, and works after that. Press Show reviews, wait, then press Try again:

1import { useState } from "react";2import { loadReviews } from "./api.js";3 4export default function App() {5  const [reviews, setReviews] = useState([]);6  const [error, setError] = useState(null);7  const [status, setStatus] = useState("closed"); // "closed", "loading", or "loaded"8 9  async function handleShow() {10    setStatus("loading");11    setError(null);12    try {13      setReviews(await loadReviews());14      setStatus("loaded");15    } catch (err) {16      setStatus("closed");17      setError(err);18    }19  }20 21  if (status === "loading") {22    return <p>Loading reviews…</p>;23  }24  if (status === "loaded") {25    return reviews.length === 0 ? (26      <p>No reviews yet.</p>27    ) : (28      <ul>29        {reviews.map((review) => (30          <li key={review}>{review}</li>31        ))}32      </ul>33    );34  }35  return (36    <>37      <button onClick={handleShow}>{error === null ? "Show reviews" : "Try again"}</button>38      {error !== null && <p>{error.message}</p>}39    </>40  );41}

Here are the five steps, applied to the panel:

1. The looks: closed (a button), loading, loaded with reviews, loaded with none, and error (a Try again button and the message).
2. The triggers: a click on the button (human), and the server's answer or failure (computer).
3. The state: the reviews, the last error, and a status on line 7: "closed", "loading", or "loaded".
4. What's removed: there is no isEmpty. Line 25 works it out from reviews.length. There is no isError. Lines 37 and 38 check error.
5. The handler: handleShow on lines 9 to 19 sets "loading", waits, then sets "loaded", or sets "closed" and keeps the error.

Lines 21 to 23 return the loading look, lines 24 to 34 the loaded looks, and lines 35 to 40 the closed and error looks, which share a button whose label depends on error. To see the "no reviews" look, press Edit & run, open the api.js tab, and change line 11 to resolve([]);. Show reviews, then Try again, now ends with No reviews yet..

Each change in these forms has a trigger. Sort these: does a person cause it, or the computer?

Common mix-ups

• "In React, you show and hide elements in event handlers." No. Handlers set state. The JSX describes what each state shows, and React changes the page to match.
• "A visual state and a state variable are the same thing." No. The coupon form has five looks and three state variables. Empty and Error are worked out from code and error.
• "More booleans make a form clearer." No. Each boolean doubles the combinations. Five allow 32, and 27 of them are impossible states that a missed setter can reach.
• "Only clicks and typing change state." No. Computer inputs, like a server's answer or a timer, change it too. They set state in the code that waits for them.
• "A status needs a library or an enum type." No. A string like "submitting" in useState is enough. TypeScript can list the allowed strings, but plain JavaScript works the same way.
• "A mock is wasted work." No. The mock's JSX becomes the real component's JSX. You only swap the status prop for state and add the handlers.

Practice exercises

Each exercise shows its code's result under it, or when you press Edit & run. The pretend servers answer after one second. Try a guess first, then use the hints.

export default function SaveButton({ status = "saving" }) {
  return (
    <button disabled={status === "saving" || status === "saved"}>
      {status === "saving" ? "Saving…" : status === "saved" ? "Saved" : "Save"}
    </button>
  );
}

1export default function SaveButton({ status = "saving" }) {2  return (3    <button disabled={status === "saving" || status === "saved"}>4      {status === "saving" ? "Saving…" : status === "saved" ? "Saved" : "Save"}5    </button>6  );7}

1import SaveButton from "./SaveButton.jsx";2 3const statuses = ["idle", "saving"];4 5export default function App() {6  return (7    <>8      {statuses.map((status) => (9        <section key={status}>10          <h4>{status}</h4>11          <SaveButton status={status} />12        </section>13      ))}14    </>15  );16}

1import SaveButton from "./SaveButton.jsx";2 3const statuses = ["idle", "saving", "saved", "error"];4 5export default function App() {6  return (7    <>8      {statuses.map((status) => (9        <section key={status}>10          <h4>{status}</h4>11          <SaveButton status={status} />12        </section>13      ))}14    </>15  );16}

1const form = document.querySelector("#coupon-form");2const input = document.querySelector("#code");3const button = document.querySelector("#apply");4const checking = document.querySelector("#checking");5const errorText = document.querySelector("#error");6const success = document.querySelector("#success");7 8async function handleSubmit(e) {9  e.preventDefault();10  input.disabled = true;11  button.disabled = true;12  checking.hidden = false;13  errorText.hidden = true;14  try {15    await checkCoupon(input.value);16    form.hidden = true;17    success.textContent = "Coupon " + input.value + " applied: 10% off.";18    success.hidden = false;19  } catch (err) {20    checking.hidden = true;21    errorText.textContent = err.message;22    errorText.hidden = false;23    button.disabled = false;24  }25}26 27function handleInput() {28  button.disabled = input.value.length === 0;29}30 31form.addEventListener("submit", handleSubmit);32input.addEventListener("input", handleInput);

1const form = document.querySelector("#coupon-form");2const input = document.querySelector("#code");3const button = document.querySelector("#apply");4const checking = document.querySelector("#checking");5const errorText = document.querySelector("#error");6const success = document.querySelector("#success");7 8async function handleSubmit(e) {9  e.preventDefault();10  input.disabled = true;11  button.disabled = true;12  checking.hidden = false;13  errorText.hidden = true;14  try {15    await checkCoupon(input.value);16    form.hidden = true;17    success.textContent = "Coupon " + input.value + " applied: 10% off.";18    success.hidden = false;19  } catch (err) {20    checking.hidden = true;21    errorText.textContent = err.message;22    errorText.hidden = false;23    button.disabled = false;24    input.disabled = false;25  }26}27 28function handleInput() {29  button.disabled = input.value.length === 0;30}31 32form.addEventListener("submit", handleSubmit);33input.addEventListener("input", handleInput);

1import { useState } from "react";2import { subscribe } from "./api.js";3 4export default function App() {5  const [isSubscribing, setIsSubscribing] = useState(false);6  const [isSubscribed, setIsSubscribed] = useState(false);7 8  async function handleClick() {9    setIsSubscribing(true);10    await subscribe("asha@shop.com");11    setIsSubscribed(true);12  }13 14  return (15    <>16      <button onClick={handleClick} disabled={isSubscribing}>Subscribe</button>17      {isSubscribing && <p>Subscribing…</p>}18      {isSubscribed && <p>You're subscribed.</p>}19    </>20  );21}

1import { useState } from "react";2import { subscribe } from "./api.js";3 4export default function App() {5  const [status, setStatus] = useState("idle"); // "idle", "subscribing", or "subscribed"6 7  async function handleClick() {8    setStatus("subscribing");9    await subscribe("asha@shop.com");10    setStatus("subscribed");11  }12 13  if (status === "subscribed") {14    return <p>You're subscribed.</p>;15  }16  return (17    <>18      <button onClick={handleClick} disabled={status === "subscribing"}>Subscribe</button>19      {status === "subscribing" && <p>Subscribing…</p>}20    </>21  );22}

1import { useState } from "react";2import { subscribe } from "./api.js";3 4export default function App() {5  const [email, setEmail] = useState("taken@shop.com");6  const [status, setStatus] = useState("typing"); // "typing", "sending", or "sent"7 8  async function handleSubmit(e) {9    e.preventDefault();10    setStatus("sending");11    await subscribe(email);12    setStatus("sent");13  }14 15  if (status === "sent") {16    return <p>Thanks! Check {email} for a welcome note.</p>;17  }18  return (19    <form onSubmit={handleSubmit}>20      <label>21        Email <input value={email} onChange={(e) => setEmail(e.target.value)} disabled={status === "sending"} />22      </label>23      <button disabled={email.length === 0 || status === "sending"}>Sign up</button>24      {status === "sending" && <p>Signing you up…</p>}25    </form>26  );27}

1import { useState } from "react";2import { subscribe } from "./api.js";3 4export default function App() {5  const [email, setEmail] = useState("taken@shop.com");6  const [error, setError] = useState(null);7  const [status, setStatus] = useState("typing"); // "typing", "sending", or "sent"8 9  async function handleSubmit(e) {10    e.preventDefault();11    setStatus("sending");12    setError(null);13    try {14      await subscribe(email);15      setStatus("sent");16    } catch (err) {17      setStatus("typing");18      setError(err);19    }20  }21 22  if (status === "sent") {23    return <p>Thanks! Check {email} for a welcome note.</p>;24  }25  return (26    <form onSubmit={handleSubmit}>27      <label>28        Email <input value={email} onChange={(e) => setEmail(e.target.value)} disabled={status === "sending"} />29      </label>30      <button disabled={email.length === 0 || status === "sending"}>Sign up</button>31      {status === "sending" && <p>Signing you up…</p>}32      {error !== null && <p>{error.message}</p>}33    </form>34  );35}

1import { useState } from "react";2 3export default function App() {4  const [password, setPassword] = useState("");5  const [isEmpty, setIsEmpty] = useState(true);6  const [isTooShort, setIsTooShort] = useState(false);7  const [status, setStatus] = useState("typing"); // "typing" or "saved"8 9  function handleChange(e) {10    setPassword(e.target.value);11    setIsEmpty(e.target.value.length === 0);12    setIsTooShort(e.target.value.length > 0 && e.target.value.length < 8);13  }14 15  if (status === "saved") {16    return <p>Password saved.</p>;17  }18  return (19    <>20      <label>21        New password <input value={password} onChange={handleChange} />22      </label>23      <button disabled={isEmpty || isTooShort} onClick={() => setStatus("saved")}>Save</button>24      {isTooShort && <p>Use at least 8 characters.</p>}25    </>26  );27}

1import { useState } from "react";2 3export default function App() {4  const [password, setPassword] = useState("");5  const [status, setStatus] = useState("typing"); // "typing" or "saved"6 7  const isEmpty = password.length === 0;8  const isTooShort = password.length > 0 && password.length < 8;9 10  if (status === "saved") {11    return <p>Password saved.</p>;12  }13  return (14    <>15      <label>16        New password <input value={password} onChange={(e) => setPassword(e.target.value)} />17      </label>18      <button disabled={isEmpty || isTooShort} onClick={() => setStatus("saved")}>Save</button>19      {isTooShort && <p>Use at least 8 characters.</p>}20    </>21  );22}

Check your understanding

For each code question, find the status first, then read which conditions are true for it. Press Edit & run on a question's code to check your answer.

Key takeaways

• Imperative UI code gives the page commands for each event, and every list of commands can miss a part. Declarative code describes each look once, and React makes the changes.
• Step 1: list every look the user can see. Draw them with a mock that takes a status prop, or all at once in a living styleguide.
• Step 2: find the triggers. Human inputs come through event handlers; computer inputs, like a server's answer, come in the code that waits for them. Both set state.
• Steps 3 and 4: hold the looks in the fewest pieces of state. Replace booleans that clash with one status, and work out anything another piece of state already says.
• Step 5: make each handler set state to the next look, and nothing else. In TypeScript, a discriminated union can make impossible states impossible to write.

Coming next: Choosing the state structure. It turns the questions from Step 4 into five principles for any state: group it, don't let it contradict itself, and don't repeat, copy, or deeply nest it.