Блог / JavaScript + Ajax / From Boolean Flags to Elegant State Machines: A Guide to Cleaner Code

From Boolean Flags to Elegant State Machines: A Guide to Cleaner Code

### Tired of wrestling with a tangled web of isLoading, isError, and isSuccess boolean flags? This article provides a practical guide to refactoring complex conditional logic into a clean, predictable, and scalable State Machine. Learn how to eliminate impossible states, improve code readability, and make your components more robust. We'll walk through a real-world example, transforming messy if/else chains into an elegant state-driven solution.

Meta Stop fighting boolean flags and messy if statements. Learn how the State Machine design pattern can help you manage complex application state, prevent bugs, and write cleaner, more maintainable code. A practical guide with JavaScript/TypeScript examples.

Keywords State Machine, Design Patterns, JavaScript, TypeScript, Refactoring, Clean Code, State Management, Finite State Machine, Software Architecture, Frontend Development, React, Vue, Svelte ---

Introduction We've all been there. You start with a simple component that fetches data. You add an isLoading flag. Then you need to handle failures, so you add an isError flag. Soon, you need to differentiate between the initial empty state and a successful fetch, leading to more flags and complex conditional logic. Your component's rendering logic becomes a minefield of if/else statements:

if (isLoading) {
  // Show spinner
} else if (isError) {
  // Show error message
} else if (data) {
  // Show data
} else {
  // Show empty state
}

This "boolean-driven development" seems innocent at first, but it quickly leads to fragile, bug-prone code. What happens when isLoading and isError are both true? You've created an *impossible state* that your UI must now account for, adding even more complexity. There is a better way. By adopting a classic computer science concept—the **Finite State Machine (FSM)**—we can tame this complexity, eliminate impossible states, and write code that is declarative, predictable, and a joy to maintain.

The Chaos of Unmanaged State: A Familiar Story Let's look at a typical data-fetching component. In a framework like React, the state management might look something like this:

import { useState, useEffect } from 'react';

const ProductDisplay = () => {
  const [product, setProduct] = useState(null);
  const [isLoading, setIsLoading] = useState(true); // Start loading immediately
  const [error, setError] = useState(null);

  useEffect(() => {
    fetchProduct()
      .then(data => {
        setProduct(data);
        // What do we do with isLoading here?
      })
      .catch(err => {
        setError(err);
        // What if it was already loading?
      })
      .finally(() => {
        setIsLoading(false);
      });
  }, []);

  // The rendering logic becomes a mess
  if (isLoading && !error) {
    return Loading product...;
  }

  if (error) {
    return Error: {error.message} ;
  }
  
  if (!isLoading && !product) {
      return No product found.;
  }

  return {product.name}
{product.};
};

This code has several problems: 1. **Impossible States:** It's possible for isLoading and error to be true simultaneously. How should the UI react? 2. **Implicit Logic:** The state transitions are scattered. Setting isLoading to false in a .finally() block is an implicit side-effect. 3. **Poor Scalability:** What if we need to add a "refetching" or "submitting" state? We'd have to add another boolean flag and update every single if statement.

What is a Finite State Machine (FSM)? A Finite State Machine is a model of computation that can be in exactly **one** of a finite number of *states* at any given time. It can change from one state to another in response to *events* or *conditions*; this change is called a *transition*.

The Core Concepts 1. **States:** A finite set of distinct conditions your application can be in. For our example, the states could be idle, loading, success, and error. Crucially, it can only be in *one* of these at a time. 2. **Events (or Transitions):** The actions that trigger a move from one state to another. For example, a FETCH event moves the machine from idle to loading. A RESOLVE event moves it from loading to success. 3. **Context:** An optional piece of data storage associated with the machine. In our example, this would be the place to store the fetched product data or the error message. Think of a traffic light. Its states are Green, Yellow, and Red. The event is a TIMER_EXPIRED. It can never be Green and Red at the same time. Its behavior is completely predictable. We want to bring that same predictability to our components.

Refactoring to a State Machine: The "After" Let's refactor our ProductDisplay component using a simple state machine. We won't even use a library at first to show how simple the concept is.

Defining Our States and Events

First, let's formally define the behavior we want:

* **States**: idle, loading, success, error

* **Events**: * FETCH: Triggered when we want to start fetching data. * RESOLVE: Triggered when the fetch succeeds. * REJECT: Triggered when the fetch fails. * RETRY: Triggered to try fetching again after an error.

Building the Machine

We can represent our machine's logic in a simple object. This object defines, for each state, which events are valid and what state they transition to.

// A simple state machine definition
const productMachine = {
  initial: 'idle',
  states: {
    idle: {
      on: { FETCH: 'loading' }
    },
    loading: {
      on: {
        RESOLVE: 'success',
        REJECT: 'error'
      }
    },
    success: {
      on: { FETCH: 'loading' } // Allow re-fetching
    },
    error: {
      on: { RETRY: 'loading' }
    }
  }
};

// A function to handle transitions
function transition(currentState, event) {
  const nextState = productMachine.states[currentState]?.on?.[event];
  return nextState || currentState; // If transition is not valid, stay in the same state
}

This is the entire brain of our component's logic, centralized and easy to read. You can see exactly how the component is supposed to behave just by looking at this object.

Integrating the Machine into Our Component

Now, we can replace our multiple boolean flags with a single state value.

import { useState, useEffect, useReducer } from 'react';

// Using a reducer is a great pattern for managing state machine transitions
const machineReducer = (state, event) => {
    // The state here is just the string name, e.g., 'idle'
    // The event is the string name, e.g., 'FETCH'
    return transition(state, event.type);
};

const ProductDisplay = () => {
  // One state to rule them all!
  const [currentState, dispatch] = useReducer(machineReducer, productMachine.initial);
  
  // Context is managed separately but tied to the state
  const [product, setProduct] = useState(null);
  const [error, setError] = useState(null);

  useEffect(() => {
    // Only run the effect when we enter the 'loading' state
    if (currentState === 'loading') {
      fetchProduct()
        .then(data => {
          setProduct(data);
          dispatch({ type: 'RESOLVE' });
        })
        .catch(err => {
          setError(err);
          dispatch({ type: 'REJECT' });
        });
    }
  }, [currentState]); // Re-run the effect if the state changes to 'loading'

  const handleFetch = () => dispatch({ type: 'FETCH' });
  const handleRetry = () => dispatch({ type: 'RETRY' });

  // Rendering logic is now clean and unambiguous
  return (
    
      {currentState === 'idle' && (
        
      )}

      {currentState === 'loading' && Loading product...}

      {currentState === 'error' && (
        
          Error: {error.message}
          
        
      )}

      {currentState === 'success' && (
        
          {product.name}
          {product.}
          
        
      )}
    
  );
};

Look at the difference! The rendering logic is now a simple, flat list of conditions. There are no overlapping if/else chains, and it's impossible to render a loading spinner and an error message at the same time.

The Benefits of Thinking in States Adopting this pattern provides immediate and long-term benefits: 1. **Predictability:** The component can only be in one well-defined state at a time. Impossible combinations of booleans are eliminated by design. 2. **Scalability:** Adding a new state, like 'refetching', is trivial. You just add it to the machine definition and handle its rendering. The existing logic remains untouched and safe. 3. **Readability & Maintainability:** The machine object serves as documentation. A new developer can understand the component's entire lifecycle just by reading it. 4. **Testability:** You can test the transition logic of your machine in complete isolation from the UI, leading to more robust and reliable unit tests.

Conclusion While a few boolean flags might seem harmless on a small component, they are a ticking time bomb of complexity. The State Machine pattern isn't just an academic concept; it's a powerful and practical tool for building robust, predictable, and maintainable user interfaces and application logic. By trading a handful of booleans for a single, explicit state, you centralize your logic, eliminate impossible scenarios, and make your code easier to reason about for yourself and your team. The next time you find yourself adding a second is... flag, take a moment to consider if a state machine could bring order to your chaos. For more advanced use cases, consider exploring libraries like [XState](https://xstate.js.org/), which provide powerful tools for building and visualizing complex state machines. --- For questions or feedback, feel free to reach out at: isholegg@gmail.com.

Якщо у вас виникли питання, вбо ви бажаєте записатися на індивідуальний урок, замовити статтю (інструкцію) або придбати відеоурок, пишіть нам на:
скайп: olegg.pann
telegram, viber - +380937663911
додавайтесь у телеграм-канал: t.me/webyk
email: oleggpann@gmail.com
ми у fb: www.facebook.com/webprograming24
Обов`язково оперативно відповімо на усі запитіння