DEV Community: David K. 🎹

Release Notes: XState 4.22.0 & @xstate/react 1.5.0

David K. 🎹 — Tue, 06 Jul 2021 15:20:06 +0000

XState 4.22.0

In past releases, createModel(...) was introduced to make typing context and events easier in machines. Now, you can create a machine directly from the .createMachine(...) method on a created model:

const userModel = createModel({
  name: 'David'
});

const userMachine = userModel.createMachine({
  // no need to specify initial `context`!

  entry: (context, event) => {
    // context and event are fully typed from model
  }
});

This makes it even easier to create typed machines without having to specify type parameters. Keep in mind that the use of createModel(...) is completely optional, and meant as a helper. In the future, models will include ways to create and provide types for action objects, guards, and more.

In this version, you can also now spawn/invoke reducers, which are functions that return the next state given the current state and event. The source of a spawned/invoked reducer is created using fromReducer(reducer, initialState):

import { fromReducer } from 'xstate/lib/behaviors';

type CountEvent = { type: 'INC' } | { type: 'DEC' };

const countReducer = (count: number, event: CountEvent): number => {
  if (event.type === 'INC') {
    return count + 1;
  } else if (event.type === 'DEC') {
    return count - 1;
  }

  return count;
};

const countMachine = createMachine({
  invoke: {
    id: 'count',
    src: () => fromReducer(countReducer, 0)
  },
  on: {
    INC: {
      actions: forwardTo('count')
    },
    DEC: {
      actions: forwardTo('count')
    }
  }
});

If you've used Redux, Vuex, ngrx, or similar state management libraries that use reducers, this should feel familiar to you. It is now possible to reuse reducers directly inside of XState.

`@xstate/react` 1.5.0

See release

Just like useInterpret(...) takes in a machine and returns a service actor, there is a new useSpawn(...) hook that takes in any behavior and returns an actor for that behavior.

What is a behavior?
A behavior is a function that determines what happens next when an actor receives an event, depending on its current state. With state machines & statecharts, the behavior is formally and visually defined.

You can try this out with the previously mentioned new fromReducer(...) creator, which creates a "reducer behavior" from a reducer:

import { fromReducer } from 'xstate/lib/behaviors';
import { useActor, useSpawn } from '@xstate/react';

type CountEvent = { type: 'INC' } | { type: 'DEC' };

const countBehavior = fromReducer(
  (count: number, event: CountEvent): number => {
    if (event.type === 'INC') {
      return count + 1;
    } else if (event.type === 'DEC') {
      return count - 1;
    }

    return count;
  },
  0 // initial state
);

const Component = () => {
  const countActorRef = useSpawn(countBehavior);
  const [count, send] = useActor(countActorRef);

  return (
    <div>
      Count: {count}
      <button onClick={() => send({ type: 'INC' })}>Increment</button>
      <button onClick={() => send({ type: 'DEC' })}>Decrement</button>
    </div>
  );
};

For brevity, you can also combine the hooks:

const [count, send] = useActor(useSpawn(countBehavior));

On a more general note, this demonstrates that the most basic units in XState are behaviors and actors. Actors are live instances of behaviors. State machines and statecharts are specialized, powerful behaviors, and services are actors that have their behaviors described as those state machines/statecharts.

You don't need a library for state machines

David K. 🎹 — Wed, 20 Jan 2021 23:27:30 +0000

The finite state machine is one of the oldest models of computation in computer science. It's older than the web, older than any programming language you can think of, and probably older than you. Just ask Mealy (1955) or Moore (1956). Finite state machines (FSMs) can be implemented in any modern language using control-flow statements, yet there's most likely a state machine library (if not many) in all of those languages.

So do you need a library to create and interpret state machines in your programs?

No. But there are more things to consider.

You probably need state machines

If you're unfamiliar with finite state machines (FSMs), they are a visual and mathematical way of modeling stateful logic using 3 main building blocks:

Finite states, which represent different behaviors
Events, which represent something that happened that can change state
Transitions, which represent how the state can change and what actions are executed when an event is received

Anything that can be described as changes in state over time due to events, from component-specific logic to application flows and even the orchestration of multiple services can be described with state machines, to some extent.

A state machine might be a different, unfamiliar way of thinking about your application logic, but they're extremely useful. Instead of approaching logic from a "bottom-up" perspective (imperatively doing things based on events), they take a "top-down" approach and primarily consider behaviors, which describe how the logic will react to events in a given finite state (such as loading, editing, disabled, etc.).

Because of their explicit, declarative nature, state machines force you to think about the entire flow of your logic (including all the edge-cases), and make it virtually impossible to end up in an "impossible state", as long as your model doesn't allow it. Only defined transitions can happen; and if an unexpected transition happens, it means there is an implicit state machine where that transition does exist. The goal of state machines is to eliminate the implicit transitions so that we can know exactly what can happen in any state for any potential event.

State machines are not a solution for everything - just like anything else, they make sense for some use-cases (workflows, processes, modes, statuses, etc.) but not all use-cases. You shouldn't use state machines everywhere, or even implement them explicitly all of the time (that's what abstractions are for). They make a good refactor target, and they're great for visually modeling your logic with pencil and paper, even if you ultimately decide not to use them in your code. But when working with logic that deals with explicit states, events, and transitions (which, surprise, tends to be the majority of app logic), state machines are a brilliant, natural solution.

There are so many other benefits to thinking in terms of states, events, and transitions, but that's not the point of this post (but it is the point of another post I wrote). Let's say you're already convinced in using state machines in parts of your app. Should you reach for a library?

You don't need a library for state machines

Since state machines are not a new concept and can be implemented in any modern language using built-in language features, it follows that state machine libraries are not necessary. Again, all you need are the 3 building blocks:

Finite states
Events
Transitions

The transitions are what tie everything together. Transitions are represented by a state-transition function that looks like this, mathematically:

𝛅 : 𝑆 𝗑 𝛴 → 𝑆

...which might not make sense (even if you do speak Greek). This might be more understandable:

transition : (state, event) => nextState

In JavaScript, we can represent this as a reducer, which is a function that reduces values (events) to a single accumulated value (state):



function transition(state, event) {
  // state machine goes here, which
  // determines the next state based on the
  // current state + received event
  // ...

  return nextState;
}

Now, let's ~~draw the rest of the owl~~ implement the rest of the state machine!

Using `switch` statements

Typically, when we're determining behavior ("what happens next"), we tend to decide what should happen next based on the event. The finite state is an after-thought, if it's even a consideration at all. This leads to fragile logic, with if-statements strewn all over the place:



// ❌ Event-first approach
switch (event.type) {
  case 'DATA_RECEIVED':
    // defensive programming
    if (state.isLoading) {
      // do something
    } else {
      // ...
    }
  }
  // ...
}

In contrast, state machines group behavior by finite state and narrow down what happens next based on the event received:



// ✅ Finite-state-first approach
switch (state.status) {
  case 'loading':
    // narrow based on event
    switch (event.type) {
      case 'DATA_RECEIVED':
        // do something, and possibly
        // change the finite state
      // ...
    }
  // ...
}

As the author of the code, the event-first (bottom-up) approach might seem fine to you; after all, if it works, it works. One of the main advantages of taking a "finite-state-first" (top-down) approach and using state machines is that the logic is not only more clear (since it's grouped by finite state), it's more robust: you can ensure that an event won't be improperly handled in a state that it shouldn't be handled in. In other words, you prevent impossible states and impossible transitions without having to litter your code with if-statements and excessive defensive programming.

I also like to think of state machines as a formal way of communicating logic. If you were describing the above logic, here's how it would sound with an event-first approach:

When data is received, do something, but only if the "loading" flag is true.

And with a finite-state-first approach:

In the "loading" state, when data is received, do something.

Which one sounds more natural and easy to understand? To me, there is less cognitive load with the 2nd statement. Reactions to events are grouped by behavior (finite state) rather than being ungrouped.

Using `switch` statements with functions

Since finite states can be considered a way to group behavior, another way you can organize your switch statements is by "grouping" each finite state's behavior into a function:



// 'loading' behavior
function loadingState(state, event) {
  // switch only on the event
  switch (event.type) {
    case 'DATA_RECEIVED':
      return {
        ...state,
        status: 'success'
      }
    }
    // ...
  }
}

function dataMachine(state, event) {
  switch (state.status) {
    case 'loading':
      // handle the event with 'loading' behavior
      return loadingState(state, event);
    }
    // ...
  }
}

This approach is outlined in the Redux style guide recommendation: Treat Reducers as State Machines. It's a very organized approach, and each "behavior function" can be individually tested, since they are isolated, pure reducers.

Using objects

Using nested switch statements may feel verbose, and while using functions to organize these switch statements may look cleaner, it's more tedious. After all, a state transition can be considered a configuration of (at least) 2 things based on the event received:

The next finite state, if it changes
Any action(s) executed, if any

A simple, built-in way to represent such a configuration is an object. We can create an object structure where each "state node" represents a finite state with transitions for each event accepted by the state:



const machine = {
  initial: 'loading',
  states: {
    // A finite "state node"
    loading: {
      on: {
        // event types
        DATA_RECEIVED: {
          target: 'success',
          // actions: [...]
        }
      }
    },
    // ...
  }
};

// ...

This is much more succinct than the nested switch statements! From here, determining the next state based on the current finite state and received event is two key lookups (the finite state and the event type):



// ... 

function transition(state, event) {
  const nextStateNode = machine
    // lookup configuration for current finite state
    .states[state.status]
    // lookup next finite state based on event type
    .on?.[event.type]
    // if not handled, stay on current state
    ?? { target: state.status };

  return {
    ...state,
    status: nextStateNode.target
  }
}

transition({ status: 'loading' }, { type: 'DATA_RECEIVED' });
// => { status: 'success', ... }

You might be wondering why I didn't use an even simpler object here, which you definitely can do:



const transitions = {
  loading: {
    DATA_RECEIVED: 'success'
  },
  success: {/* ... */}
};

function transition(state, event) {
  const nextStateTarget = transitions[state.status][event.type]
    ?? state.status;

  return {
    ...state,
    status: nextStateTarget
  };
}

In fact, I would encourage the above implementation as sort of a "transition table lookup"; it works, and it's simple enough. However, state machines deal with more than just the next finite state; if we want to encode actions (state machine terminology for effects), we need a place to put them, so a little bit more structure is necessary.

For instance, if our DATA_RECEIVED event returns data that we want to save in our overall state, it might be convenient to place that "assign to state" action directly in the machine:



const machine = {
  initial: 'loading',
  states: {
    loading: {
      on: {
        // event types
        DATA_RECEIVED: {
          target: 'success',
          // represents what "effects" should happen
          // as a result of taking this transition
          actions: [
            { type: 'saveData' }
          ]
        }
      }
    },
    // ...
  }
};

function transition(state, event) {
  const nextStateNode = machine
    .states[state.status]
    .on?.[event.type]
    ?? { target: state.status };

  const nextState = {
    ...state,
    status: nextStateNode.target
  };

  // go through the actions to determine
  // what should be done
  nextStateNode.actions?.forEach(action => {
    if (action.type === 'saveData') {
      nextState.data = event.data;
    }
  });

  return nextState;
}

The implementation above is very small, accomplishes everything we want from a state machine (for this use-case, at least), and as a bonus, you can copy-paste the machine object code directly into the XState Visualizer, even though it's not using XState, or any libraries, at all! (Tip: wrap the object in Machine({ ... }) to get it working).

Kent C. Dodds made a similar implementation is his post Implementing a Simple State Machine Library in JavaScript. It also takes advantage of using objects for describing the state machine structure.

State machines aren't enough

So if we can get our basic state management needs met with a small, declarative, library-free state machine implementation (either using switch statements or objects), why do we need libraries such as XState?

This might be a bit of a shock coming from me, but I'll say it: state machines are not sufficient for managing and orchestrating state at scale. State machines suffer from a fundamental problem called state explosion: when the number of states in a state machine grow, the transitions between states also tend to grow, exponentially.

Thankfully, an extension to the traditional formalism of state machines, known as statecharts, was invented by Prof. David Harel and published in his paper Statecharts: A Visual Formalism for Complex Systems. The paper is full of diagrams and is quite readable; I strongly encourage you to read it.

You can think of statecharts as essentially being state machines (statecharts can be decomposed into FSMs) with some essential features for better state organization and real-world use-cases:

Hierarchy (nested states)
Orthogonality (parallel states)
History (remembered states)
State actions (entry, exit)
Guarded transitions
Extended state (contextual data)

Notably, the first two features (hierarchy and orthogonality) mitigate the state explosion problem by allowing state nodes to be grouped in a way that reduces the number of transitions necessary to fully express all possible transitions.

For example, if you were creating a state machine to represent editing and asynchronously saving some data, and you wanted to have shared behavior between some "idle" (before saving) and "error" (failure after saving) state (e.g., SUBMIT to try/retry), then instead of having a flat state machine:



{
  idleNormal: {
    on: {
      SAVE: {
        target: 'saving',
        actions: [{ type: 'saveAsync' }]
      }
    }
  },
  saving: {/* ... */},
  idleError: {
    on: {
      SAVE: {
        target: 'saving',
        actions: [{ type: 'saveAsync' }]
      }
    }
  },
  // ...
}

You can represent the shared behavior under the same parent state:



{
  idle: {
    // if child states don't handle these events,
    // handle it here, in the parent state
    on: {
      SAVE: {
        target: 'saving',
        actions: [{ type: 'saveAsync' }]
      }
    },
    initial: 'normal',
    states: {
      normal: {/* ... */},
      error: {/* ... */}
    }
  },
  saving: {/* ... */},
  // ...
}

Overall, the features of statecharts are very useful in many different situations:

Nested states are useful for grouping and refining behavior. Different "finite states" can all share behavior, while all having their own specific behavior.
Parallel states are useful for representing behaviors that can occur simultaneously, without directly affecting each other.
History states are useful for recalling which nested state the machine was previously in without having to specify all the possible "remembering" transitions.
State actions are useful for specifying actions that should always be executed on any transition that enters/exits a state without having to specify those actions in all incoming/outgoing transitions.
Guarded transitions are very important for conditionally taking transitions based on more than just the state and event type. They can take other data (extended state) and/or event data into consideration, as well.
Extended state is absolutely necessary. Not all state is finite; "infinite" state also needs to be quantified. Statecharts allow you to distinguish between finite and extended state.

There's even more features of classic statecharts, such as "activities" (actions that occur throughout a state), delays, eventless transitions, wildcard transitions, and more. And the more you work with statecharts, the more you realize just how essential most of these features actually are.

Sounds like it would be fun to implement these features on top of our state machines, right?

Implementing statecharts

I hope you have a lot of free time.

Since statecharts are more powerful than state machines, they're also harder to implement. If you're really curious and/or eager to implement them yourself, I strongly recommend following the W3 SCXML (Statechart XML) spec. They even include an algorithm in pseudocode for proper SCXML interpretation.

Even implementing something as seemingly straightforward as nested states is a daunting task. There are many rules about selecting transitions, resolving conflicting transitions, traversing the state node tree to determine which nodes are being exited/entered, selecting transitions in compound states if leaf nodes don't handle the event, determining action order, etc. etc.

It's not easy, and just like you would use a date library to deal with timezones, you definitely want to use a statechart library to deal with all the excellent features that statecharts support.

So do you need a library for statecharts?

Yes.

Closing thoughts

If you're satisfied manipulating state at any time and sprinkling if-statements to patch up edge-cases, you probably don't need explicit state machines.

If you want to use simple state machines to help organize app behavior and logic, you don't need a library.

If you have complex logic and want to take advantage of more powerful state machine features to better manage this logic, you need statecharts.

And you definitely need a library for statecharts. 😉

If you want to stay up to date with my stately musings and ramblings:

📬 Subscribe to The Stately Newsletter
💬 Join the Stately Discord
🐦 Follow me on Twitter at @davidkpiano

Thanks for reading!

Cover image by Susan Yin on Unsplash (I remember visiting this library in Stockholm! 🇸🇪)

Redux is half of a pattern (2/2)

David K. 🎹 — Fri, 22 May 2020 19:07:18 +0000

I wrote a form library once.

Once.

It was called React Redux Form, and using Redux for forms was a good idea, at the time (don't use it). In fact, my library was written as a response to Redux Form, and both libraries soon discovered that the idea of using a single global store to store all of your application state is a really, really bad idea.

When all of your forms live in one single store, state is easy to manage at first. And then, every single keypress starts to lag. It's a terrible user experience.

So what do you do?

Blur inputs
Add debounced updates
Memoize everything
Optimize selectors everywhere
Make controlled components uncontrolled
Use React.memo() on components
Use PureComponent for good measure
Use Suspense (??)
etc. etc.

In short, you go into panic mode and try to contain the spread of the global updates affecting every single connected component, even if those components don't need to rerender.

Some of you have gotten really good at solving this, and have become expert "selector, caching, and memoization" developers. That's fantastic.

But let's examine if those tactics should even be necessary. What if all state wasn't global?

// Detect dark theme var iframe = document.getElementById('tweet-1241756566048694272-779'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1241756566048694272&theme=dark" }

Local vs. global state

The first of Redux's three principles is that there is essentially a single source of truth for your whole application state:

The state of your whole application is stored in an object tree within a single store.

Source: Redux's three principles: single source of truth

The primary reason for this is that it makes many things easier, such as sharing data, rehydrating state, "time-travel debugging", etc. But it suffers from a fundamental disconnect: there is no such thing as a single source of truth in any non-trivial application. All applications, even front-end apps, are distributed at some level:

// Detect dark theme var iframe = document.getElementById('tweet-1116019772238454784-437'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1116019772238454784&theme=dark" }

And, in a contradictory way, even the Redux Style Guide advises against putting the entire state of your application in a single store:

[...] Instead, there should be a single place to find all values that you consider to be global and app-wide. Values that are "local" should generally be kept in the nearest UI component instead.

Source: Redux Style Guide

Whenever something is done for the sole purpose of making something easy, it almost always makes some other use-case more difficult. Redux and its single-source-of-truth is no exception, as there are many problems that arise from fighting against the nature of front-end apps being "distributed" instead of an idealistic atomic, global unit:

Multiple orthogonal concerns that need to be represented in the state somehow.

This is "solved" by using combineReducers.

Multiple separate concerns that need to share data, communicate with each other, or are otherwise tangentially related.

This is "solved" by more complex, custom reducers that orchestrate events through these otherwise separate reducers.

Irrelevant state updates: when separate concerns are combined (using combineReducers or similar) into a single store, whenever any part of the state updates, the entire state is updated, and every "connected" component (every subscriber to the Redux store) is notified.

This is "solved" by using selectors, and perhaps by using another library like reselect for memoized selectors.

I put "solved" in quotes because these are all solutions that are all but necessary due to problems that are caused solely by using a global, atomic store. In short, having a single global store is unrealistic, even for apps that are already using global stores. Whenever you use a 3rd-party component, or local state, or local storage, or query parameters, or a router, etc., you have already shattered the illusion of a single global store. App data is always distributed at some level, so the natural solution should be to embrace the distribution (by using local state) rather than fighting against it just for the sake of making some use-cases easier to develop in the short run.

Acting differently

So how can we address this global state problem? To answer that, we need to go back in time a little bit and take some inspiration from another old, well-established model: the actor model.

The actor model is a surprisingly simple model that can be extended slightly beyond its original purpose (concurrent computation). In short, an actor is an entity that can do three things:

It can receive messages (events)
It can change its state/behavior as a reaction to a received message, including spawning other actors
It can send messages to other actors

If you thought "hmm... so a Redux store is sort of an actor", congratulations, you already have a basic grasp of the model! A Redux store, which is based on some single combined-reducer thing:

✅ Can receive events
✅ Changes its state (and thus its behavior, if you're doing it right) as a reaction to those events
❌ Can't send messages to other stores (there's only one store) or between reducers (dispatching only happens outside-in).

It also can't really spawn other "actors", which makes the Reddit example in the official Redux advanced tutorial more awkward than it needs to be:

function postsBySubreddit(state = {}, action) {
  switch (action.type) {
    case INVALIDATE_SUBREDDIT:
    case RECEIVE_POSTS:
    case REQUEST_POSTS:
      return Object.assign({}, state, {
        [action.subreddit]: posts(state[action.subreddit], action)
      })
    default:
      return state
  }
}

Source: https://redux.js.org/advanced/async-actions#reducersjs

Let's dissect what is happening here:

We're taking only the relevant slice of state we need (state[action.subreddit]), which should ideally be its own entity
We are determining what the next state of only this slice should be, via posts(state[action.subreddit], action)
We are surgically replacing that slice with the updated slice, via Object.assign(...).

In other words, there is no way we can dispatch or forward an event directly to a specific "entity" (or actor); we only have a single actor and have to manually update only the relevant part of it. Also, every other reducer in combineReducers(...) will get the entity-specific event, and even if they don't update, every single one of them will still be called for every single event. There's no easy way to optimize that. A function that isn't called is still much more optimal than a function that is called and ultimately does nothing (i.e., returns the same state), which happens most of the time in Redux.

Reducers and actors

So how do reducers and actors fit together? Simply put, a reducer describes the behavior of an individual actor:

Events are sent to a reducer
A reducer's state/behavior can change due to a received event
A reducer can spawn actors and/or send messages to other actors (via executed declarative actions)

This isn't a cutting-edge, groundbreaking model; in fact, you've probably been using the actor model (to some extent) without even knowing it! Consider a simple input component:

const MyInput = ({ onChange, disabled }) => {
  const [value, setValue] = useState('');

  return (
    <input
      disabled={disabled}
      value={value}
      onChange={e => setValue(e.target.value)}
      onBlur={() => onChange(value)}
    />
  );
}

This component, in an implicit way, is sort of like an actor!

It "receives events" using React's slightly awkward parent-to-child communication mechanism - prop updates
It changes state/behavior when an event is "received", such as when the disabled prop changes to true (which you can interpret as some event)
It can send events to other "actors", such as sending a "change" event to the parent by calling the onChange callback (again, using React's slightly awkward child-to-parent communication mechanism)
In theory, it can "spawn" other "actors" by rendering different components, each with their own local state.

Reducers make the behavior and business logic more explicit, especially when "implicit events" become concrete, dispatched events:

const inputReducer = (state, event) => {
  /* ... */
};

const MyInput = ({ onChange, disabled }) => {
  const [state, dispatch] = useReducer(inputReducer, {
    value: '',
    effects: []
  });

  // Transform prop changes into events
  useEffect(() => {
    dispatch({ type: 'DISABLED', value: disabled });
  }, [disabled]);

  // Execute declarative effects
  useEffect(() => {
    state.effects.forEach(effect => {
      if (effect.type === 'notifyChange') {
        // "Send" a message back up to the parent "actor"
        onChange(state.value);
      }
    });
  }, [state.effects]);

  return (
    <input
      disabled={disabled}
      value={state.value}
      onChange={e => dispatch({
        type: 'CHANGE', value: e.target.value
      })}
      onBlur={() => dispatch({ type: 'BLUR' })}
    />
  );
}

Multi-Redux?

Again, one of Redux's three main principles is that Redux exists in a single, global, atomic source of truth. All of the events are routed through that store, and the single huge state object is updated and permeates through all connected components, which use their selectors and memoization and other tricks to ensure that they are only updated when they need to be, especially when dealing with excessive, irrelevant state updates.

And using a single global store has worked pretty well when using Redux, right? Well... not exactly, to the point that there are entire libraries dedicated to providing the ability to use Redux on a more distributed level, e.g., for component state and encapsulation. It is possible to use Redux at a local component level, but that was not its main purpose, and the official react-redux integration does not naturally provide that ability.

No Redux?

There are other libraries that embrace the idea of "state locality", such as MobX and XState. For React specifically, there is Recoil for "distributed" state and the built-in useReducer hook that feels a lot like a local Redux, specifically for your component. For declarative effects, I created useEffectReducer which looks and feels just like useReducer, but also gives you a way to manage effects.

For state that needs to be shared (not globally), you can use a pattern that is very similar to what React-Redux already uses, by making an object that can be subscribed to (i.e., "listened" to) and passed down through context:

// Detect dark theme var iframe = document.getElementById('tweet-1228700861024604160-421'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1228700861024604160&theme=dark" }

That will give you the best performance, as that "subscribable" object will seldom/never change. If that feels a bit boilerplatey for you and performance is not a huge concern, you can combine useContext and useReducer with not too much effort:

const CartContext = createContext();

const cartReducer = (state, event) => {
  // reducer logic
  // try using a state machine here! they're pretty neat

  return state;
};

const initialCartState = {
  // ...
};

const CartContextProvider = ({ children }) => {
  const [state, dispatch] = useReducer(cartReducer, initialCartState);

  return <CartContext.Provider value={[state, dispatch]}>
    {children}
  </CartContext.Provider>;
};

export const useCartContext = () => {
  return useContext(CartContext);
};

And then use it in your components:

const CartView = () => {
  const [state, dispatch] = useCartContext();

  // ...
};

Not too bad, right? In general, this is not a problem that can be solved in Redux without going against-the-grain, since Redux is fundamentally a single, atomic global store.

What do others think?

I ran a non-scientific poll on Twitter to see where most app state lives, and how developers feel about it:

// Detect dark theme var iframe = document.getElementById('tweet-1227615817640087553-994'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1227615817640087553&theme=dark" }

From this, I gather two things:

Whether you distribute state locally, or contain all state in a single store, you will be able to accomplish app state requirements successfully.
However, more developers are discontent with the majority of app state being global instead of local, which also might hint to why the majority of developers are happy using local state instead.

What do you think? Share your thoughts in the comments!

Conclusion

Thinking in terms of "actors", in which your application is organized by lots of smaller actors that all talk to each other by passing messages/events to each other, can encourage separation of concerns and make you think differently about how state should be localized (distributed) and connected. My goal for this post is to help you realize that not all state needs to be global, and that other patterns (such as the Actor Model) exist for modeling distributed state and communication flow.

The Actor Model is not a panacea, though. If you're not careful, you can end up having a spaghetti-like state management problem, where you have completely lost track of which actor is talking to another actor. Anti-patterns are present in any solution that you choose, so it helps to research best practices and actually model your app before you start coding.

If you want to learn more about the Actor Model, check out The Actor Model in 10 Minutes by Brian Storti, or any of these videos:

Please keep in mind that this is post reflects my opinions based on what I've researched, and is in no way meant to be authoritative on the way you should do things. I want to make you think, and I hope that this post accomplished that goal. Thanks for reading!

If you enjoyed this post (or even if you didn't and just want to hear more of my state management ramblings), subscribe to the Stately Newsletter for more content, thoughts, and discussion 📬

Photo by Steve Johnson on Unsplash

// Detect dark theme var iframe = document.getElementById('tweet-1237091703087079425-819'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1237091703087079425&theme=dark" }

Redux is half of a pattern (1/2)

David K. 🎹 — Mon, 20 Jan 2020 18:51:08 +0000

Redux is fantastic.

Some of you might disagree, so let me tell you why.

Over the last few years, Redux has popularized the idea of using message-passing (also known as event-driven programming) to manage application state. Instead of making arbitrary method calls to various class instances or mutating data structures, we now can think of state as being in a "predictable container" that only changes as a reaction to these "events".

This simple idea and implementation is universal enough to be used with any framework (or no framework at all), and has inspired libraries for other popular frameworks such as:

Vuex for Vue
NgRx for Angular

However, Redux has recently come under scrutiny by some prominent developers in the web community:

// Detect dark theme var iframe = document.getElementById('tweet-1191487232038883332-760'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1191487232038883332&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1195126928799227905-437'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1195126928799227905&theme=dark" }

If you don't know these developers, they are the co-creators of Redux themselves. So why have Dan and Andrew, and many other developers, all but forsaken the use of Redux in applications?

The ideas and patterns in Redux appear sound and reasonable, and Redux is still used in many large-scale production apps today. However, it forces a certain architecture in your application:

// Detect dark theme var iframe = document.getElementById('tweet-1025408731805184000-291'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1025408731805184000&theme=dark" }

As it turns out, this kind of single-atom immutable architecture is not natural nor does it represent how any software application works (nor should work) in the real-world.

Redux is an alternative implementation of Facebook's Flux "pattern". Many sticking points and hardships with Facebook's implementation have led developers to seek out alternative, nicer, more developer-friendly APIs such as Redux, Alt, Reflux, Flummox, and many more.. Redux emerged as a clear winner, and it is stated that Redux combines the ideas from:

However, not even the Elm architecture is a standalone architecture/pattern, as it is based on fundamental patterns, whether developers know it or not:

Rather than someone inventing it, early Elm programmers kept discovering the same basic patterns in their code. It was kind of spooky to see people ending up with well-architected code without planning ahead!

// Detect dark theme var iframe = document.getElementById('tweet-1202580315652448263-878'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1202580315652448263&theme=dark" }

In this post, I will highlight some of the reasons that Redux is not a standalone pattern by comparing it to a fundamental, well-established pattern: the finite state machine. This is not an arbitrary choice; every single application that we write is basically a state machine, whether we know it or not. The difference is that the state machines we write are implicitly defined.

I hope that some of these comparisons and differences will help you realize how some of the common pain points in Redux-driven applications materialize, and how you can use this existing pattern to help you craft a better state management architecture, whether you're using Redux, another library, or no library at all.

What is a finite state machine?

(Taken from another article I wrote, The FaceTime Bug and the Dangers of Implicit State Machines):

Wikipedia has a useful but technical description on what a finite state machine is. In essence, a finite state machine is a computational model centered around states, events, and transitions between states. To make it simpler, think of it this way:

Any software you make can be described in a finite number of states (e.g., idle, loading, success, error)
You can only be in one of those states at any given time (e.g., you can’t be in the success and error states at the same time)
You always start at some initial state (e.g., idle)
You move from state to state, or transition, based on events (e.g., from the idle state, when the LOAD event occurs, you immediately transition to the loading state)

It’s like the software that you’re used to writing, but with more explicit rules. You might have been used to writing isLoading or isSuccess as Boolean flags before, but state machines make it so that you’re not allowed to have isLoading === true && isSuccess === true at the same time.

It also makes it visually clear that event handlers can only do one main thing: forward their events to a state machine. They’re not allowed to “escape” the state machine and execute business logic, just like real-world physical devices: buttons on calculators or ATMs don’t actually do operations or execute actions; rather, they send "signals" to some central unit that manages (or orchestrates) state, and that unit decides what should happen when it receives that "signal".

What about state that is not finite?

With state machines, especially UML state machines (a.k.a. statecharts), "state" refers to something different than the data that doesn't fit neatly into finite states, but both "state" and what's known as "extended state" work together.

For example, let's consider water 🚰. It can fit into one of four phases, and we consider these the states of water:

liquid
solid (e.g., ice, frost)
gas (e.g., vapor, steam)
plasma

Water phase UML state machine diagram from uml-diagrams.com

However, the temperature of water is a continuous measurement, not a discrete one, and it can't be represented in a finite way. Despite this, water temperature can be represented alongside the finite state of water, e.g.:

liquid where temperature === 90 (celsius)
solid where temperature === -5
gas where temperature === 500

There's many ways to represent the combination of finite and extended state in your application. For the water example, I would personally call the finite state value (as in the "finite state value") and the extended state context (as in "contextual data"):

const waterState = {
  value: 'liquid', // finite state 
  context: {       // extended state
    temperature: 90
  }
}

But you're free to represent it in other ways:

const waterState = {
  phase: 'liquid', // finite state
  data: {          // extended state
    temperature: 90
  }
}

// or...

const waterState = {
  status: 'liquid', // finite state
  temperature: 90   // anything not 'status' is extended state
}

The key point is that there is a clear distinction between finite and extended state, and there is logic that prevents the application from reaching an impossible state, e.g.:

const waterState = {
  isLiquid: true,
  isGas: true, // 🚱 Water can't be both liquid and gas simultaneously!
  temperature: -50 // ❄️ This is ice!! What's going on??
}

And we can extend these examples to realistic code, such as changing this:

const userState = {
  isLoading: true,
  isSuccess: false,
  user: null,
  error: null
}

To something like this:

const userState = {
  status: 'loading', // or 'idle' or 'error' or 'success'
  user: null,
  error: null
}

This prevents impossible states like userState.isLoading === true and userState.isSuccess === true happening simultaneously.

How does Redux compare to a finite state machine?

The reason I'm comparing Redux to a state machine is because, from a birds-eye view, their state management models look pretty similar. For Redux:

state + action = newState

For state machines:

state + event = newState + effects

In code, these can even be represented the same way, by using a reducer:

function userReducer(state, event) {
  // Return the next state, which is
  // determined based on the current `state`
  // and the received `event` object

  // This nextState may contain a "finite"
  // state value, as well as "extended"
  // state values.

  // It may also contain side-effects
  // to be executed by some interpreter.
  return nextState;
}

There are already some subtle differences, such as "action" vs. "event" or how extended state machines model side-effects (they do). Dan Abramov even recognizes some of the differences:

// Detect dark theme var iframe = document.getElementById('tweet-1064661742188417029-520'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1064661742188417029&theme=dark" }

A reducer can be used to implement a finite state machine, but most reducers are not modeled as finite state machines. Let's change that by learning some of the differences between Redux and state machines.

Difference: finite & extended states

Typically, a Redux reducer's state will not make a clear distinction between "finite" and "extended" states, as previously mentioned above. This is an important concept in state machines: an application is always in exactly one of a finite number of "states", and the rest of its data is represented as its extended state.

Finite states can be introduced to a reducer by making an explicit property that represents exactly one of the many possible states:

const initialUserState = {
  status: 'idle', // explicit finite state
  user: null,
  error: null
}

What's great about this is that, if you're using TypeScript, you can take advantage of using discriminated unions to make impossible states impossible:

interface User {
  name: string;
  avatar: string;
}

type UserState = 
  | { status: 'idle'; user: null; error: null; }
  | { status: 'loading'; user: null; error: null; }
  | { status: 'success'; user: User; error: null; }
  | { status: 'failure'; user: null; error: string; }

Difference: events vs. actions

In state machine terminology, an "action" is a side-effect that occurs as the result of a transition:

When an event instance is dispatched, the state machine responds by performing actions, such as changing a variable, performing I/O, invoking a function, generating another event instance, or changing to another state.

This isn't the only reason that using the term "action" to describe something that causes a state transition is confusing; "action" also suggests something that needs to be done (i.e., a command), rather than something that just happened (i.e., an event).

So keep the following terminology in mind when we talk about state machines:

An event describes something that occurred. Events trigger state transitions.
An action describes a side-effect that should occur as a response to a state transition.

The Redux style guide also directly suggests modeling actions as events:

However, we recommend trying to treat actions more as "describing events that occurred", rather than "setters". Treating actions as "events" generally leads to more meaningful action names, fewer total actions being dispatched, and a more meaningful action log history.

Source: Redux style guide: Model actions as events, not setters

When the word "event" is used in this article, that has the same meaning as a conventional Redux action object. For side-effects, the word "effect" will be used.

// Detect dark theme var iframe = document.getElementById('tweet-1218698479872040960-494'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1218698479872040960&theme=dark" }

Difference: explicit transitions

Another fundamental part of how state machines work are transitions. A transition describes how one finite state transitions to another finite state due to an event. This can be represented using boxes and arrows:

This diagram makes it clear that it's impossible to transition directly from, e.g., idle to success or from success to error. There are clear sequences of events that need to occur to transition from one state to another.

However, the way that developers tend to model reducers is by determining the next state solely on the received event:

function userReducer(state, event) {
  switch (event.type) {
    case 'FETCH':
      // go to some 'loading' state
    case 'RESOLVE':
      // go to some 'success' state
    case 'REJECT':
      // go to some 'error' state
    default:
      return state;
  }
}

The problem with managing state this way is that it does not prevent impossible transitions. Have you ever seen a screen that briefly displays an error, and then shows some success view? If you haven't, browse Reddit, and do the following steps:

Search for anything.
Click on the "Posts" tab while the search is happening.
Say "aha!" and wait a couple seconds.

In step 3, you'll probably see something like this (visible at the time of publishing this article):

After a couple seconds, this unexpected view will disappear and you will finally see search results. This bug has been present for a while, and even though it's innocuous, it's not the best user experience, and it can definitely be considered faulty logic.

However it is implemented (Reddit does use Redux...), something is definitely wrong: an impossible state transition happened. It makes absolutely no sense to transition directly from the "error" view to the "success" view, and in this case, the user shouldn't see an "error" view anyway because it's not an error; it's still loading!

You might be looking through your existing Redux reducers and realize where this potential bug may surface, because by basing state transitions only on events, these impossible transitions become possible to occur. Sprinkling if-statements all over your reducer might alleviate the symptoms of this:

function userReducer(state, event) {
  switch (event.type) {
    case 'FETCH':
      if (state.status !== 'loading') {
        // go to some 'loading' state...
        // but ONLY if we're not already loading
      }

    // ...
  }
}

But that only makes your state logic harder to follow because the state transitions are not explicit. Even though it might be a little more verbose, it's better to determine the next state based on both the current finite state and the event, rather than just on the event:

function userReducer(state, event) {
  switch (state.status) {
    case 'idle':
      switch (event.type) {
        case 'FETCH':
          // go to some 'loading' state

        // ...
      }

    // ...
  }
}

You can even split this up into individual "finite state" reducers, to make things cleaner:

function idleUserReducer(state, event) {
  switch (event.type) {
    case 'FETCH':
      // go to some 'loading' state

      // ...
    }
    default:
      return state;
  }
}

function userReducer(state, event) {
  switch (state.status) {
    case 'idle':
      return idleUserReducer(state, event);
    // ...
  }
}

But don't just take my word for it. The Redux style guide also strongly recommends treating your reducers as state machines:

[...] treat reducers as "state machines", where the combination of both the current state and the dispatched action determines whether a new state value is actually calculated, not just the action itself unconditionally.

Source: Redux style guide: treat reducers as state machines

I also talk about this idea in length in my post: No, disabling a button is not app logic.

Difference: declarative effects

If you look at Redux in isolation, its strategy for managing and executing side-effects is this:

¯\_(ツ)_/¯

That's right; Redux has no built-in way of handling side-effects. In any non-trivial application, you will have side-effects if you want to do anything useful, such as make a network request or kick off some sort of async process. Importantly enough, side-effects should not be considered an afterthought; they should be treated as a first-class citizen and uncompromisingly represented in your application logic.

Unfortunately, with Redux, they are, and the only solution is to use middleware, which is inexplicably an advanced topic, despite being required for any non-trivial app logic:

Without middleware, Redux store only supports synchronous data flow.

Source: Redux docs: Async Flow

With extended/UML state machines (also known as statecharts), these side-effects are known as actions (and will be referred to as actions for the rest of this post) and are declaratively modeled. Actions are the direct result of a transition:

When an event instance is dispatched, the state machine responds by performing actions, such as changing a variable, performing I/O, invoking a function, generating another event instance, or changing to another state.

_Source: (Wikipedia) UML State Machine: Actions and Transitions

This means that when an event changes state, actions (effects) may be executed as a result, even if the state stays the same (known as a "self-transition"). Just like Newton said:

For every action, there is an equal and opposite reaction.

Source: Newton's Third Law of Motion

Actions never occur spontaneously, without cause; not in software, not in hardware, not in real life, never. There is always a cause for an action to occur, and with state machines, that cause is a state transition, due to a received event.

Statecharts distinguish how actions are determined in three possible ways:

Entry actions are effects that are executed whenever a specific finite state is entered
Exit actions are effects that are executed whenever a specific finite state is exited
Transition actions are effects that are executed whenever a specific transition between two finite states is taken.

Fun fact: this is why statecharts are said to have the characteristic of both Mealy machines and Moore machines:

With Mealy machines, "output" (actions) depends on the state and the event (transition actions)
With Moore machines, "output" (actions) depends on just the state (entry & exit actions)

The original philosophy of Redux is that it did not want to be opinionated on how these side-effects are executed, which is why middleware such as redux-thunk and redux-promise exist. These libraries work around the fact that Redux is side-effect-agnostic by having third-party, use-case specific "solutions" for handling different types of effects.

So how can this be solved? It may seem weird, but just like you can use a property to specify finite state, you can also use a property to specify actions that should be executed in a declarative way:

// ...
case 'FETCH':
  return {
    ...state,

    // finite state
    status: 'loading',

    // actions (effects) to execute
    actions: [
      { type: 'fetchUser', id: 42 }
    ]
  }
// ...

Now, your reducer will return useful information that answers the question, "what side-effects (actions) should be executed as a result of this state transition?" The answer is clear and colocated right in your app state: read the actions property for a declarative description of the actions to be executed, and execute them:

// pretend the state came from a Redux React hook
const { actions } = state;

useEffect(() => {
  actions.forEach(action => {
    if (action.type === 'fetchUser') {
      fetch(`/api/user/${action.id}`)
        .then(res => res.json())
        .then(data => {
           dispatch({ type: 'RESOLVE', user: data });
        })
    }
    // ... etc. for other action implementations
  });
}, [actions]);

Having side-effects modeled declaratively in some state.actions property (or similar) has some great benefits, such as in predicting/testing or being able to trace when actions will or have been executed, as well as being able to customize the implementation details of executing those actions. For instance, the fetchUser action can be changed to read from a cache instead, all without changing any of the logic in the reducer.

Difference: sync vs. async data flow

The fact is that middleware is indirection. It fragments your application logic by having it present in multiple places (the reducers and the middleware) without a clear, cohesive understanding of how they work together. Furthermore, it makes some use-cases easier but others much more difficult. For example: take this example from the Redux advanced tutorial, which uses redux-thunk to allow dispatching a "thunk" for making an async request:

function fetchPosts(subreddit) {
  return dispatch => {
    dispatch(requestPosts(subreddit))
    return fetch(`https://www.reddit.com/r/${subreddit}.json`)
      .then(response => response.json())
      .then(json => dispatch(receivePosts(subreddit, json)))
  }
}

Now ask yourself: how can I cancel this request? With redux-thunk, it simply isn't possible. And if your answer is to "choose a different middleware", you just validated the previous point. Modeling logic should not be a question of which middleware you choose, and middleware shouldn't even be part of the state modeling process.

As previously mentioned, the only way to model async data flow with Redux is by using middleware. And with all the possible use-cases, from thunks to Promises to sagas (generators) to epics (observables) and more, the ecosystem has plenty of different solutions for these. But the ideal number of solutions is one: the solution provided by the pattern in use.

Alright, so how do state machines solve the async data flow problem?

They don't.

To clarify, state machines do not distinguish between sync and async data flows, because there is no difference. This is such an important realization to make, because not only does it simplify the idea of data flow, but it also models how things work in real life:

A state transition (triggered by a received event) always occurs in "zero-time"; that is, states synchronously transition.
Events can be received at any time.

There is no such thing as an asynchronous transition. For example, modeling data fetching doesn't look like this:

idle . . . . . . . . . . . . success

Instead, it looks like this:

idle --(FETCH)--> loading --(RESOLVE)--> success

Everything is the result of some event triggering a state transition. Middleware obscures this fact. If you're curious how async cancellation can be handled in a synchronous state transition manner, here's a couple of guiding points for a potential implementation:

A cancellation intent is an event (e.g., { type: 'CANCEL' })
Cancelling an in-flight request is an action (i.e., side-effect)
"Canceled" is a state, whether it's a specific state (e.g., canceled) or a state where a request shouldn't be active (e.g., idle)

To be continued

It is possible to model application state in Redux to be more like a finite state machine, and it is good to do so for many reasons. The applications that we write have different modes, or "behaviors", that vary depending on which "state" it's in. Before, this state might have been implicit. But now, with finite states, you can group behavior by these finite states (such as idle, loading, success, etc.), which makes the overall app logic much more clear, and prevents the app from getting stuck in an impossible state.

Finite states also make clear what events can do, depending on which state it's in, as well as what all the possible states are in an application. Additionally, they can map one-to-one to views in user interfaces.

But most importantly, state machines are present in all of the software that you write, and they have been for over half a century. Making finite state machines explicit brings clarity and robustness to complex app logic, and it is possible to implement them in any libraries that you use (or even no library at all).

In the next post, we'll talk about how the Redux atomic global store is also half of a pattern, the challenges it presents, and how it compares to another well-known model of computation (the Actor model).

Cover photo by Joseph Greve on Unsplash

XState: version 4.7 and the future

David K. 🎹 — Mon, 09 Dec 2019 17:18:36 +0000

XState version 4.7 has just been released. This is a minor version bump, but a major reworking of the internal algorithms, a lot of new capabilities, bug fixes, and a better TypeScript experience. It also paves the road for even more utilities, like @xstate/test and @xstate/react, as well as compatibility with other 3rd-party tools across the ecosystem, and even across languages.

What is XState?

XState is a JavaScript (and TypeScript) library for creating state machines and statecharts, and interpreting them. State machines enforce a specific set of "rules" on logic structure such that:

There are a finite number of states (such as "loading" or "success"), which is different than context (related data with potentially infinite possibilities, such as email or age)
There are a finite number of events (such as { type: 'FETCH', query: "..." } that can trigger a transition between states.
Each state has transitions, which say, "Given some event, go to this next state and/or do these actions".

You don't need a state machine library to do this, as you can use switch statements instead:

switch (state.status) {
  case 'idle': // finite state
    switch (event.type) {
      case 'FETCH':
        return {
          ...state,
          status: 'loading',
          query: event.query
        };
      // ...
    // ...
  // ...
}

But let's be honest, writing it like this is arguably a bit cleaner:

const machine = Machine({
  initial: 'idle',
  states: {
    idle: {
      on: {
        FETCH: {
          target: 'loading',
          actions: assign({ query: (_, event) => event.query })
        }
      }
    },
    // ...
  }
});

And it also makes it possible to directly copy-paste this machine code into a visualizer, like XState Viz, and visualize it, like was done at the end of the No, disabling a button is not app logic article:

View this viz on XState Viz

Then there are statecharts, which are an extension of finite state machines created by David Harel in 1989 (read the paper 📑). Statecharts offer many improvements and mitigate many issues of using flat finite state machines, such as:

Nested states (hierarchy)
Parallel states (orthogonality)
History states
Entry, exit, and transition actions
Transient states
Activities (ongoing actions)
Communication with many machines (invoked services)
Delayed transitions
And much more

These are things that you definitely do not want to implement yourself, which is why libraries like XState exist. And this brings us to...

What is new in XState 4.7?

This minor release has been worked on for months, with a huge amount of help from Mateusz Burzyński (also known as AndaristRake) 👏. The reason it took so long was because we are internally reworking the algorithms to be simpler, fit the SCXML spec, and be compatible with a growing number of tools in the ecosystem. This refactoring also makes adding new capabilities much easier, and will hopefully encourage more contributors to help with this project. As a nice side-effect, it also eliminates a few edge-case bugs that had workarounds, but might have caused a suboptimal developer experience in previous versions.

Refactored internal algorithms

How difficult can it be to create a statechart library? A lot more difficult than it seems, especially if you want to conform to the long, but well-established SCXML spec. There's even libraries for integrating SCXML code directly with JavaScript, such as Jacob Beard's excellent SCION tools, which I highly recommend you check out. It was a huge inspiration for XState, and XState is tested against much of the same code.

SCXML specifies an algorithm for SCXML interpretation, which is written in pseudocode, but directly transferable to many popular languages. This algorithm was followed more closely in the refactor, which simplified a lot of the code base and removed the need for ad-hoc data structures such as StateTree, which was used to keep track of which state nodes were "active" for a given transition (now it's just a set).

As a result, the core code base is a little smaller, the algorithms are a little bit faster (determining the next state is basically an O(1) lookup, O(n) worst-case), and the code base is a lot nicer to work with and contribute to. We will continue to improve the algorithms used as we move towards 5.0.

Typestates

Typestates are really useful for developers. They're popular in Rust, and this article on The Typestate Pattern in Rust describes them elegantly:

Typestates are a technique for moving properties of state (the dynamic information a program is processing) into the type level (the static world that the compiler can check ahead-of-time).

Without learning Rust or diving into the Wikipedia article, let's present a classic example: loading data. You might represent the state's context in this way:

interface User {
  name: string;
}

interface UserContext {
  user?: User;
  error?: string;
}

This type-safe declaration allows you to defensively program effectively, but it can be a bit annoying when you are 100% sure that user is defined:

if (state.matches('success')) {
  if (!state.context.user) {
    // this should be impossible!
    // the user definitely exists!
    throw new Error('Something weird happened');
  }

  return state.context.user.name;
}

In 4.7, XState allows you to represent your states with Typestates so that you can tell the compiler that you know how the context should be in any given state:

This is very useful and improves the developer experience, but should be used as a strong guide, and not as a guarantee. It works by using discriminated unions in TypeScript to define your states, but the way it is implemented requires TypeScript version 3.7 and higher. There's still some quirks to work out, as we're basically trying to trick TypeScript into knowing some extra information about our state machines that is otherwise difficult/impossible to infer in a statically typed language. (Maybe one day JavaScript will have a dependently-typed flavor.)

Better service experience

XState makes invoking external "services" a first-class citizen. If this is a foreign concept, for now, just understand that it answers the question "how can many state machines communicate with each other?", and the answer is by using events as the main communication mechanism. In 4.7, the developer experience for this is improved:

Invoked services can now be referenced on the state.children object by their ID. So if a state invokes some service with id: 'fetchUser', then that invocation will be present on state.children.fetchUser.
The new forwardTo() action creator allows you to forward events to invoked services, which cuts down a lot of boilerplate:

on: {
  SOME_EVENT: {
    actions: forwardTo('someService')
  }
}

SCXML has this notion of a sessionid, which is a unique identifier for each invoked service. XState 4.7 becomes more SCXML-compatible by keeping a reference of this in state._sessionid, which corresponds to the SCXML _sessionid variable.
XState can use that _sessionid to determine which service sent an event, so it can respond with an event back, using the new respond() action creator:

const authServerMachine = Machine({
  initial: 'waitingForCode',
  states: {
    waitingForCode: {
      on: {
        CODE: {
          actions: respond('TOKEN', { delay: 10 })
        }
      }
    }
  }
});

const authClientMachine = Machine({
  initial: 'idle',
  states: {
    idle: {
      on: { AUTH: 'authorizing' }
    },
    authorizing: {
      invoke: {
        id: 'auth-server',
        src: authServerMachine
      },
      entry: send('CODE', { to: 'auth-server' }),
      on: {
        TOKEN: 'authorized'
      }
    },
    authorized: {
      type: 'final'
    }
  }
});

You can make your own custom action creators too, and implement patterns that you might be familiar with already if you've worked with microservices.

Wildcard descriptors

If you've ever wanted to transition from a state if any (unspecified) event is received? Well, you're in luck, because XState now supports wildcard descriptors, which are a type of event descriptor (SCXML) that describes a transition for any event in a given state:

const quietMachine = Machine({
  id: 'quiet',
  initial: 'idle',
  states: {
    idle: {
      on: {
        WHISPER: undefined,
        // On any event besides a WHISPER, transition to the 'disturbed' state
        '*': 'disturbed'
      }
    },
    disturbed: {}
  }
});

quietMachine.transition(quietMachine.initialState, 'WHISPER');
// => State { value: 'idle' }

quietMachine.transition(quietMachine.initialState, 'SOME_EVENT');
// => State { value: 'disturbed' }

Much, much more

See https://github.com/davidkpiano/xstate/releases/tag/v4.7.0 for an overview of the latest updates in this minor version.

The future of XState

All this leads to the big question: what are the future plans/goals for XState? The first important thing to realize is that XState is not just another state management library, and state management was never its only goal. XState strives to bring two things to the JavaScript ecosystem:

State machines/statecharts, for modeling the logic of any individual component
Actor model, for modeling how components communicate with each other and behave in a system

All of these are very old, very useful, and battle-tested concepts. The benefits they provide cannot be understated, and highlight the future plans for XState and related tooling:

Better visualization tools, including an updated visualizer, dev tools for Firefox and Chrome (work in progress!), dev tools for VS Code, and integration with other graphical viz tools such as PlantUML and GraphViz
Full SCXML compatibility, which will allow statecharts authored in XState to be reusable in other languages that have SCXML tooling, as it is a truly language-agnostic spec
A catalog of examples, to demonstrate common patterns and best practices for many use-cases
Analytics, testing, and simulation tools

As well as some initial ideas for XState version 5.0:

Better type safety and a more seamless TypeScript experience
Static analysis tools for compile-time hints/warnings and run-time optimizations
A more "functional", and completely optional, syntax for defining states and transitions more naturally (developer experience)
Higher-level state types such as "task" and "choice" to make it easier to define workflows and remove some boilerplate

We're also listening to ideas that you present to us in the XState Wish List thread, so post what you would like to see!

More information

If you're curious about XState or statecharts in general, there are many fantastic resources, including:

The World of Statecharts by Erik Mogensen
Statecharts community on Spectrum
XState docs
Other tutorials made by many excellent developers in the community

No, disabling a button is not app logic.

David K. 🎹 — Wed, 13 Nov 2019 13:51:47 +0000

I'm going to start this post with an excerpt from the book "Constructing the User Interface with Statecharts", written by Ian Horrocks in 1999:

User interface development tools are very powerful. They can be used to construct large and complex user interfaces, with only a relatively small amount of code written by an application developer. And yet, despite the power of such tools and the relatively small amount of code that is written, user interface software often has the following characteristics:

the code can be difficult to understand and review thoroughly:

the code can be difficult to test in a systematic and thorough way;

the code can contain bugs even after extensive testing and bug fixing;

the code can be difficult to enhance without introducing unwanted side-effects;

the quality of the code tends to deteriorate as enhancements are made to it.

Despite the obvious problems associated with user interface development, little effort has been made to improve the situation. Any practitioner who has worked on large user interface projects will be familiar with many of the above characteristics, which are symptomatic of the way in which the software is constructed.

In case you didn't do the math, this was written over 20 years ago and yet it echoes the same sentiments that many developers feel today about the state of app development. Why is that?

We'll explore this with a simple example: fetching data in a React component. Keep in mind, the ideas presented in this article are not library-specific, nor framework-specific... in fact, they're not even language specific!

Trying to make `fetch()` happen

Suppose we have a DogFetcher component that has a button that you can click to fetch a random dog. When the button is clicked, a GET request is made to the Dog API, and when the dog is received, we show it off in an <img /> tag.

A typical implementation with React Hooks might look like this:

function DogFetcher() {
  const [isLoading, setIsLoading] = useState(false);
  const [dog, setDog] = useState(null);

  return (
    <div>
      <figure className="dog">{dog && <img src={dog} alt="doggo" />}</figure>

      <button
        onClick={() => {
          setIsLoading(true);
          fetch(`https://dog.ceo/api/breeds/image/random`)
            .then(data => data.json())
            .then(response => {
              setDog(response.message);
              setIsLoading(false);
            });
        }}
      >
        {isLoading ? "Fetching..." : "Fetch dog!"}
      </button>
    </div>
  );
}

This works, but there's one immediate problem: clicking the button more than once (while a dog is loading) will display one dog briefly, and then replace that dog with another dog. That's not very considerate to the first dog.

The typical solution to this is to add a disabled={isLoading} attribute to the button:

function DogFetcher() {
  // ...

  <button
    onClick={() => {
      // ... excessive amount of ad-hoc logic
    }}
    disabled={isLoading}
  >
    {isLoading ? "Fetching..." : "Fetch dog!"}
  </button>

  // ...
}

This also works; you're probably satisfied with this solution. Allow me to burst this bubble.

What can possibly go wrong?

Currently, the logic reads like this:

When the button is clicked, fetch a new random dog, and set a flag to make sure that the button cannot be clicked again to fetch a dog while one is being fetched.

However, the logic you really want is this:

When a new dog is requested, fetch it and make sure that another dog can't be fetched at the same time.

See the difference? The desired logic is completely separate from the button being clicked; it doesn't matter how the request is made; it only matters what logic happens afterwards.

Suppose that you want to add the feature that double-clicking the image loads a new dog. What would you have to do?

It's all too easy to forget to add the same "guard" logic on figure (after all, <figure disabled={isLoading}> won't work, go figure), but let's say you're an astute developer who remembers to add this logic:

function DogFetcher() {
  // ...

  <figure
    onDoubleClick={() => {
      if (isLoading) return;

      // copy-paste the fetch logic from the button onClick handler
    }}
  >
    {/* ... */}
  </figure>

  // ...

  <button
    onClick={() => {
      // fetch logic
    }}
    disabled={isLoading}
  >
    {/* ... */}
  </button>

  // ...
}

In reality, you can think about this as any use-case where some sort of "trigger" can happen from multiple locations, such as:

a form being able to be submitted by pressing "Enter" in an input or clicking the "Submit" button
an event being triggered by a user action or a timeout
any app logic that needs to be shared between different platforms with different event-handling implementations (think React Native)

But there's a code smell here. Our same fetch logic is implemented in more than one place, and understanding the app logic requires developers to jump around in multiple parts of the code base, finding all of the event handlers where there are tidbits of logic and connecting them together mentally.

DRYing up the splashes of logic

Okay, so putting logic in our event handlers is probably not a good idea, but we can't exactly put our finger on the reason why yet. Let's move the fetch logic out into a function:

function DogFetcher() {
  const [isLoading, setIsLoading] = useState(false);
  const [dog, setDog] = useState(null);

  function fetchDog() {
    if (isLoading) return;

    setIsLoading(true);
    fetch(`https://dog.ceo/api/breeds/image/random`)
      .then(data => data.json())
      .then(response => {
        setDog(response.message);
        setIsLoading(false);
      });
  }

  return (
    <div>
      <figure className="dog" onDoubleClick={fetchDog}>
        {dog && <img src={dog} alt="doggo" />}
      </figure>

      <button onClick={fetchDog}>
        {isLoading ? "Fetching..." : "Fetch dog!"}
      </button>
    </div>
  );
}

Adding features and complexity

Now let's see what happens when we want to add basic "features", such as:

If fetching a dog fails, an error should be shown.
Fetching a dog should be cancellable.

I hesitate to call these "features" because these types of behaviors should be naturally enabled by the programming patterns used, but let's try to add them anyhow:

function DogFetcher() {
  const [isLoading, setIsLoading] = useState(false);
  const [error, setError] = useState(null);
  const [canceled, setCanceled] = useState(false);
  const [dog, setDog] = useState(null);

  function fetchDog() {
    setCanceled(false);
    setError(null);
    setIsLoading(true);

    fetchRandomDog()
      .then(response => {
        // This should work... but it doesn't!
        if (canceled) return;

        setIsLoading(false);
        setDog(response.message);
      })
      .catch(error => {
        setIsLoading(false);
        setCanceled(false);
        setError(error);
      });
  }

  function cancel() {
    setIsLoading(false);
    setCanceled(true);
  }

  return (
    <div>
      {error && <span style={{ color: "red" }}>{error}</span>}
      <figure className="dog" onDoubleClick={fetchDog}>
        {dog && <img src={dog} alt="doggo" />}
      </figure>

      <button onClick={fetchDog}>
        {isLoading ? "Fetching..." : "Fetch dog!"}
      </button>
      <button onClick={cancel}>Cancel</button>
    </div>
  );
}

This looks like it should work -- all of our Boolean flags are being set to the correct values when things happen. However, it does not work because of a hard-to-catch bug: stale callbacks. In this case, the canceled flag inside the .then(...) callback will always be the previous value instead of the latest canceled value, so cancelling has no effect until the next time we try to fetch a dog, which isn't what we want.

Hopefully you can see that even with these simple use-cases, our logic has quickly gone out-of-hand, and juggling Boolean flags has made the logic buggier and harder to understand.

Reducing complexity effectively

Instead of haphazardly adding Boolean flags everywhere, let's clean this up with the useReducer and useEffect hooks. These hooks are useful because they express some concepts that lead to better logic organization:

The useReducer hook uses reducers, which return the next state given the current state and some event that just occurred.
The useEffect hook synchronizes effects with state.

To help us organize the various app states, let's define a few and put them under a status property:

An "idle" status means that nothing happened yet.
A "loading" status means that the dog is currently being fetched.
A "success" status means that the dog was successfully fetched.
A "failure" status means that an error occurred while trying to fetch the dog.

Now let's define a few events that can happen in the app. Keep in mind: these events can happen from anywhere, whether it's initiated by the user or somewhere else:

A "FETCH" event indicates that fetching a dog should occur.
A "RESOLVE" event with a data property indicates that a dog was successfully fetched.
A "REJECT" event with an error property indicates that a dog was unable to be fetched for some reason.
A "CANCEL" event indicates that an in-progress fetch should be canceled.

Great! Now let's write our reducer:

function dogReducer(state, event) {
  switch (event.type) {
    case "FETCH":
      return {
        ...state,
        status: "loading"
      };
    case "RESOLVE":
      return {
        ...state,
        status: "success",
        dog: event.data
      };
    case "REJECT":
      return {
        ...state,
        status: "failure",
        error: event.error
      };
    case "CANCEL":
      return {
        ...state,
        status: "idle"
      };
    default:
      return state;
  }
}

const initialState = {
  status: "idle",
  dog: null,
  error: null
};

Here's the beautiful thing about this reducer. It is completely framework-agnostic - we can take this and use it in any framework, or no framework at all. And that also makes it much easier to test.

But also, implementing this in a framework becomes reduced (pun intended) to just dispatching events. No more logic in event handlers:

function DogFetcher() {
  const [state, dispatch] = useReducer(dogReducer, initialState);
  const { error, dog, status } = state;

  useEffect(() => {
    // ... fetchDog?
  }, [state.status]);

  return (
    <div>
      {error && <span style={{ color: "red" }}>{error}</span>}
      <figure className="dog" onDoubleClick={() => dispatch({ type: "FETCH" })}>
        {dog && <img src={dog} alt="doggo" />}
      </figure>

      <button onClick={() => dispatch({ type: "FETCH" })}>
        {status === "loading" ? "Fetching..." : "Fetch dog!"}
      </button>
      <button onClick={() => dispatch({ type: "CANCEL" })}>Cancel</button>
    </div>
  );
}

However, the question remains: how do we execute the side-effect of actually fetching the dog? Well, since the useEffect hook is meant for synchronizing effects with state, we can synchronize the fetchDog() effect with status === 'loading', since 'loading' means that that side-effect is being executed anyway:

// ...
  useEffect(() => {
    if (state.status === "loading") {
      let canceled = false;

      fetchRandomDog()
        .then(data => {
          if (canceled) return;
          dispatch({ type: "RESOLVE", data });
        })
        .catch(error => {
          if (canceled) return;
          dispatch({ type: "REJECT", error });
        });

      return () => {
        canceled = true;
      };
    }
  }, [state.status]);
// ...

The fabled "disabled" attribute

The logic above works great. We're able to:

Click the "Fetch dog" button to fetch a dog
Display a random dog when fetched
Show an error if the dog is unable to be fetched
Cancel an in-flight fetch request by clicking the "Cancel" button
Prevent more than one dog from being fetched at the same time

... all without having to put any logic in the <button disabled={...}> attribute. In fact, we completely forgot to do so anyway, and the logic still works!

This is how you know your logic is robust; when it works, regardless of the UI. Whether the "Fetch dog" button is disabled or not, clicking it multiple times in a row won't exhibit any unexpected behavior.

Also, because most of the logic is delegated to a dogReducer function defined outside of your component, it is:

easy to make into a custom hook
easy to test
easy to reuse in other components
easy to reuse in other frameworks

The final result

Change the <DogFetcher /> version in the select dropdown to see each of the versions we've explored in this tutorial (even the buggy ones).

Pushing effects to the side

There's one lingering thought, though... is useEffect() the ideal place to put a side effect, such as fetching?

Maybe, maybe not.

Honestly, in most use-cases, it works, and it works fine. But it's difficult to test or separate that effect from your component code. And with the upcoming Suspense and Concurrent Mode features in React, the recommendation is to execute these side-effects when some action triggers them, rather than in useEffect(). This is because the official React advice is:

If you’re working on a data fetching library, there’s a crucial aspect of Render-as-You-Fetch you don’t want to miss. We kick off fetching before rendering.

https://reactjs.org/docs/concurrent-mode-suspense.html#start-fetching-early

This is good advice. Fetching data should not be coupled with rendering. However, they also say this:

The answer to this is we want to start fetching in the event handlers instead.

This is misleading advice. Instead, here's what should happen:

An event handler should send a signal to "something" that indicates that some action just happened (in the form of an event)
That "something" should orchestrate what happens next when it receives that event.

Two possible things can happen when an event is received by some orchestrator:

State can be changed
Effects can be executed

All of this can happen outside of the component render cycle, because it doesn't necessarily concern the view. Unfortunately, React doesn't have a built-in way (yet?) to handle state management, side-effects, data fetching, caching etc. outside of the components (we all know Relay is not commonly used), so let's explore one way we can accomplish this completely outside of the component.

Using a state machine

In this case, we're going to use a state machine to manage and orchestrate state. If you're new to state machines, just know that they feel like your typical Redux reducers with a few more "rules". Those rules have some powerful advantages, and are also the mathematical basis for how literally every computer in existence today works. So they might be worth learning.

I'm going to use XState and @xstate/react to create the machine:

import { Machine, assign } from "xstate";
import { useMachine } from "@xstate/react";

// ...

const dogFetcherMachine = Machine({
  id: "dog fetcher",
  initial: "idle",
  context: {
    dog: null,
    error: null
  },
  states: {
    idle: {
      on: { FETCH: "loading" }
    },
    loading: {
      invoke: {
        src: () => fetchRandomDog(),
        onDone: {
          target: "success",
          actions: assign({ dog: (_, event) => event.data.message })
        },
        onError: {
          target: "failure",
          actions: assign({ error: (_, event) => event.data })
        }
      },
      on: { CANCEL: "idle" }
    },
    success: {
      on: { FETCH: "loading" }
    },
    failure: {
      on: { FETCH: "loading" }
    }
  }
});

Notice how the machine looks like our previous reducer, with a couple of differences:

It looks like some sort of configuration object instead of a switch statement
We're matching on the state first, instead of the event first
We're invoking the fetchRandomDog() promise inside the machine! 😱

Don't worry; we're not actually executing any side-effects inside of this machine. In fact, dogFetcherMachine.transition(state, event) is a pure function that tells you the next state given the current state and event. Seems familiar, huh?

Furthermore, I can copy-paste this exact machine and visualize it in XState Viz:

View this viz on xstate.js.org/viz

So what does our component code look like now? Take a look:

function DogFetcher() {
  const [current, send] = useMachine(dogFetcherMachine);
  const { error, dog } = current.context;

  return (
    <div>
      {error && <span style={{ color: "red" }}>{error}</span>}
      <figure className="dog" onDoubleClick={() => send("FETCH")}>
        {dog && <img src={dog} alt="doggo" />}
      </figure>

      <button onClick={() => send("FETCH")}>
        {current.matches("loading") && "Fetching..."}
        {current.matches("success") && "Fetch another dog!"}
        {current.matches("idle") && "Fetch dog"}
        {current.matches("failure") && "Try again"}
      </button>
      <button onClick={() => send("CANCEL")}>Cancel</button>
    </div>
  );
}

Here's the difference between using a state machine and a reducer:

The hook signature for useMachine(...) looks almost the same as useReducer(...)
No fetching logic exists inside the component; it's all external!
There's a nice current.matches(...) function that lets us customize our button text
send(...) instead of dispatch(...)... and it takes a plain string! (Or an object, up to you).

A state machine/statechart defines its transitions from the state because it answers the question: "Which events should be handled from this state?" The reason that having <button disabled={isLoading}> is fragile is because we admit that some "FETCH" event can cause an effect no matter which state we're in, so we have to clean up our ~mess~ faulty logic by preventing the user from clicking the button while loading.

Instead, it's better to be proactive about your logic. Fetching should only happen when the app is not in some "loading" state, which is what is clearly defined in the state machine -- the "FETCH" event is not handled in the "loading" state, which means it has no effect. Perfect.

Final points

Disabling a button is not logic. Rather, it is a sign that logic is fragile and bug-prone. In my opinion, disabling a button should only be a visual cue to the user that clicking the button will have no effect.

So when you're creating fetching logic (or any other kind of complex logic) in your applications, no matter the framework, ask yourself these questions:

What are the concrete, finite states this app/component can be in? E.g., "loading", "success", "idle", "failure", etc.
What are all the possible events that can occur, regardless of state? This includes events that don't come from the user (such as "RESOLVE" or "REJECT" events from promises)
Which of the finite states should handle these events?
How can I organize my app logic so that these events are handled properly in those states?

You do not need a state machine library (like XState) to do this. In fact, you might not even need useReducer when you're first adopting these principles. Even something as simple as having a state variable representing a finite state can already clean up your logic plenty:

function DogFetcher() {
  // 'idle' or 'loading' or 'success' or 'error'
  const [status, setStatus] = useState('idle');
}

And just like that, you've eliminated isLoading, isError, isSuccess, startedLoading, and whatever Boolean flags you were going to create. And if you really start to miss that isLoading flag (for whatever reason), you can still have it, but ONLY if it's derived from your organized, finite states. The isLoading variable should NEVER be a primary source of state:

function DogFetcher() {
  // 'idle' or 'loading' or 'success' or 'error'
  const [status, setStatus] = useState('idle');

  const isLoading = status === 'loading';

  return (
    // ...
    <button disabled={isLoading}>
      {/* ... */}
    </button>
    // ...
  );
}

And we've come full circle. Thanks for reading.

Cover photo by Lucrezia Carnelos on Unsplash

DEV Community: David K. 🎹

Release Notes: XState 4.22.0 & @xstate/react 1.5.0

XState 4.22.0

@xstate/react 1.5.0

You don't need a library for state machines

You probably need state machines

You don't need a library for state machines

Using switch statements

Using switch statements with functions

Using objects

State machines aren't enough

Implementing statecharts

So do you need a library for statecharts?

Closing thoughts

Redux is half of a pattern (2/2)

Local vs. global state

Acting differently

Reducers and actors

Multi-Redux?

No Redux?

What do others think?

Conclusion

Redux is half of a pattern (1/2)

What is a finite state machine?

What about state that is not finite?

How does Redux compare to a finite state machine?

Difference: finite & extended states

Difference: events vs. actions

Difference: explicit transitions

Difference: declarative effects

Difference: sync vs. async data flow

To be continued

XState: version 4.7 and the future

What is XState?

What is new in XState 4.7?

Refactored internal algorithms

Typestates

Better service experience

Wildcard descriptors

Much, much more

The future of XState

More information

No, disabling a button is not app logic.

Trying to make fetch() happen

What can possibly go wrong?

DRYing up the splashes of logic

Adding features and complexity

Reducing complexity effectively

The fabled "disabled" attribute

The final result

Pushing effects to the side

Using a state machine

Final points

`@xstate/react` 1.5.0

Using `switch` statements

Using `switch` statements with functions

Trying to make `fetch()` happen