Reacting to Input with State

How declarative UI compares to imperative

When you design UI interactions, you probably think about how the UI changes in response to user actions. Consider a form that lets the user submit some feedback:

• When you type something into a form, the “Submit” button becomes enabled.
• When you press “Submit”, both form and the button become disabled, and a spinner appears.
• If the network request succeeds, the form gets hidden, and the “Thank you” message appears.
• If the network request fails, an error message appears, and the form becomes enabled again.

In imperative programming, the above corresponds directly to how you implement interaction. You have to write the exact instructions to manipulate the UI depending on what just happened. Another way to think of this: imagine riding next to someone in a car and telling them turn by turn where to go. They don’t know where you want to go, they just follow your commands. (And if you get the directions wrong, you end up in the wrong place!) It’s called imperative because you have to “command” each element, from the spinner to the button, telling the computer how to update the UI.

In this example of imperative UI programming, the form is built without React. It’s made with the built-in browser DOM:

Manipulating the UI works well enough for isolated examples, but it gets exponentially more difficult to manage in more complex systems. Imagine updating a page full of different forms like this one. Adding a new UI element or a new interaction would require carefully checking all existing code to make sure you haven’t introduced a bug (for example, forgetting to show or hide something).

React was built to solve this problem.

In React, you don’t directly manipulate the UI—meaning you don’t enable, disable, show, or hide components directly. Instead, you declare what you want to show, and React figures out how to update the UI. Think of getting into a taxi and telling the driver where you want to go instead of telling them exactly where to turn. It’s the driver’s job to get you there, and they might even know some shortcuts you hadn’t considered!

Thinking about UI declaratively

You’ve seen how to implement a form imperatively above. To better understand how to think in React, you’ll walk through reimplementing this UI in React below:

1. Identify your component’s different visual states
2. Determine what triggers those state changes
3. Represent the state in memory using useState
4. Remove any non-essential state variables
5. Connect the event handlers to set the state

Step 1: Identify your component’s different visual states

In computer science, you may hear about a “state machine” being in one of several “states”. If you work with a designer, you may have seen visual mockups for different states. Designers work with visual states all the time. React stands at the intersection of design and computer science, so both of these ideas are sources of inspiration.

First, you need to visualize all the different “states” of the UI the user might see:

• Empty: Form has a disabled “Submit” button.
• Typing: Form has an enabled “Submit” button.
• Submitting: Form is completely disabled. Spinner is shown.
• Success: “Thank you” message is shown instead of a form.
• Error: Same as Typing state, but with an extra error message.

Just like a designer, you’ll want to “mock up” or create “mocks” for the different states before you add logic. For example, here is a mock for just the visual part of the form. This mock is controlled by a prop called status with a default value of 'empty':

You could call that prop anything you like, the naming is not important. Try editing status = 'empty' to status = 'success' to see the success message appear. Mocking lets you quickly iterate on the UI before you wire up any logic.

Here is a more fleshed out prototype of the same component, still “controlled” by the status prop:

import FeedbackForm from './FeedbackForm.js';

let statuses = [
  'empty',
  'typing',
  'submitting',
  'success',
  'error',
];

export default function App() {
  return (
    <>
      {statuses.map(status => (
        <section key={status}>
          <h4>FeedbackForm ({status}):</h4>
          <FeedbackForm status={status} />
        </section>
      ))}
    </>
  );
}

Step 2: Determine what triggers those state changes

State changes can generally be triggered from two different sources:

• Human triggers like clicking a button, typing in a field, navigating a link.
• Computer triggers like a network response arriving, a timeout completing, an image loading.

All triggers must set state variables to update the UI. For the form you’re developing, the following triggers will need to change state:

• Changing the text input (human) should switch it from the Empty state to the Typing state or back, depending on whether the text box is empty or not.
• Clicking the Submit button (human) should switch it to the Submitting state.
• Successful network response (computer) should switch it to the Success state.
• Failed network response (computer) should switch it to the Error state with the corresponding error message.

Notice that human inputs often require event handlers!

To help visualize this flow, try drawing each state on paper as a labeled circle, and each change between two states as an arrow. You can sketch out many flows this way and sort out bugs long before implementation.

Step 3: Represent the state in memory using useState

Next you’ll need to represent the visual states of your component in memory using useState. Simplicity is key: each piece of state is a “moving piece”, and you want as few “moving pieces” as possible. More complexity leads to more bugs!

Start with the state that absolutely must be there. For example, you’ll need to store the message for the input, and the error (if it exists) to store the last error:

const [message, setMessage] = useState('');
const [error, setError] = useState(null);

Then, you need to store which of the visual states described earlier you want to display. There’s usually more than a single way to represent that in memory, so you’ll need to experiment with it.

If you struggle to think of the best way immediately, start by adding enough state that you’re definitely sure that all the possible visual states are covered:

const [isEmpty, setIsEmpty] = useState(true);
const [isTyping, setIsTyping] = useState(false);
const [isSubmitting, setIsSubmitting] = useState(false);
const [isSuccess, setIsSuccess] = useState(false);
const [isError, setIsError] = useState(false);

Your first idea likely won’t be the best, but that’s ok—refactoring state is a part of the process!

Step 4: Remove any non-essential state variables

You want to avoid duplication in the state content so you’re only tracking what is essential. Spending a little time on refactoring your state structure will make your components easier to understand, reduce duplication, and avoid unintended meanings. Your goal is to prevent the cases where the state in memory doesn’t represent any valid UI that you’d want a user to see. (Like an error message with a disabled input preventing the user from correcting the error!)

Here are some questions you can ask your state variables:

• Does this state cause a paradox? For example, isTyping and isSubmitting can’t both be true. A paradox usually means that the state is not constrained enough. There are four possible combinations of two booleans, but only three correspond to valid states. To remove the “impossible” state, you can combine these into a status that must be one of three values: 'typing', 'submitting', or 'success'.
• Is the same information available in another state variable already? Another paradox: isEmpty and isTyping can’t be true at the same time. By making them separate state variables, you’re risking that you’ll have a bug where they go out of sync. Fortunately, you can remove isEmpty and instead check message.length === 0.
• Can you get the same information from the inverse of another state variable? isError is not needed because you can check error !== null instead.

After this clean-up, you’re left with 3 (down from 7!) essential state variables:

const [message, setMessage] = useState('');
const [error, setError] = useState(null);
const [status, setStatus] = useState('typing'); // 'typing', 'submitting', or 'success'

You know they’re essential, because you can’t remove any of them without breaking the functionality.

Step 5: Connect the event handlers to set the state

Lastly, create event handlers to set the state variables. Below is the final form in React, with all event handlers wired up:

Although this code is longer than the original imperative example, it is much less fragile. Expressing all interactions as state changes lets you later introduce new visual states without breaking existing ones. It also lets you change what should be displayed in each state without changing the logic of the interaction itself.