State machine advent: Why state machines don't scale (8/24)

Up until this point, we've seen a lot of advantages of using state machines. We can visualize our code in graphs, ensure that events drive our state changes and eliminate impossible states. In today's post, we'll take a critical look at state machines and showcase their biggest problem.

Let's say we want to model the behavior of a video chat using a single state machine. Users should be able to disable/enable both their camera and microphone.

This leaves us with 4 possible states as seen below.

1. 
audio disabled
video disabled

2.
audio disabled
video enabled

3.
audio enabled
video disabled

4. 
audio enabled
video enabled

Upon defining our state machine, we realize that there is a lot of repetition and our code looks very messy.

const videoChatMachine = Machine({
  id: 'videoChat',
  initial: 'audioDisabledVideoDisabled',
  states: {
    audioDisabledVideoDisabled: {
      on: {
        ENABLE_VIDEO: 'audioDisabledVideoEnabled',
        ENABLE_AUDIO: 'audioEnabledVideoDisabled'
      }
    },
    audioDisabledVideoEnabled: {
      on: {
        DISABLE_VIDEO: 'audioDisabledVideoDisabled',
        ENABLE_AUDIO: 'audioEnabledVideoEnabled'
      }
    },
    audioEnabledVideoDisabled: {
      on: {
        ENABLE_VIDEO: 'audioEnabledVideoEnabled',
        DISABLE_AUDIO: 'audioDisabledVideoDisabled'
      }
    },
    audioEnabledVideoEnabled: {
      on: {
        DISABLE_VIDEO: 'audioEnabledVideoDisabled',
        DISABLE_AUDIO: 'audioDisabledVideoEnabled'
      }
    },
  }
});

Looking at the graph of the state machine helps but we also only had to model 4 possible states.

Introduce one more feature to the video chat such as screen sharing which again could either be enabled or disabled, and we'll suddenly have to model 8 possible states and look at one hell of a confusing graph.

State machines are very limited because they can only model sequential states. The phenomenon of an exponentially growing amount of state nodes (and subsequently transitions) is known as state explosion. It's one of the sole reasons why state machines do not scale.

Similar to how Microsoft introduced TypeScript to fix some of JavaScripts problems, a really smart computer scientist named David Harel has created a superset of state machines to fix the problem of state explosions and other limitations of state machines. We'll introduce what David came up with tomorrow in detail. If you are already curious today, you can read about the solution in his academic paper.

About this series

Throughout the first 24 days of December, I'll publish a small blog post each day teaching you about the ins and outs of state machines and statecharts.

The first couple of days will be spent on the fundamentals before we'll progress to more advanced concepts.