Recently, I have written about simplifying an event sourced application.

The article starts with code from a talk by Jakub Pilimon and Kenny Bastani. And it ends with building a model for events in the code: how they are applied, and under which conditions.

The sample application is about Credit Card management. You can:

• Assign a credit limit. But only once, otherwise the application throws an IllegalStateException.
• Withdraw money. But you can't make more than 45 withdrawals in a certain cycle. Or you'll get an exception as well.
• Repay money

I played around with the CreditCard class. I had a feeling that something might be wrong with the withdraw method. So I wrote a test that checks for the correct behavior.

@Test(expected = IllegalStateException.class)
public void withdrawWithoutLimitAssignedThrowsIllegalStateException() {
    CreditCard card = new CreditCard(UUID.randomUUID());
    card.withdraw(BigDecimal.ZERO);
}

The test attempts to withdraw an amount of zero. But no credit limit has been assigned before. The application should reject this, and throw an IllegalStateException.
Instead, the application threw a NullPointerException.

The application assumed that the limit had been assigned before.
Now: this is a sample application. If it covered all cases it probably wouldn't be as understandable as it is.

Let's pretend we're dealing with a real world application. What if the required order of commands/events depends on a multitude of conditions and states?

If you have ever tried to implement this with conditional statements only, you probably know it's easy to lose the overview. But there is a standard solution for managing complicated flows and changes in behavior.

State machine to the rescue

In computer science, state machines have been around for decades. They are well understood in theory. They are battle proven in practice. They are the de facto standard for dealing with state dependent behavior.

So I decided to create a UML state machine model for the sample application. I asked myself first: Do I want to deal with commands or events in the state machine?

Commands are about something the application should do in the future.
Events are about something that has happened in the past.

I wanted to prevent withdrawals without a credit limit assigned.
So the state machine model needed to deal with commands.

The syntax of a transition in the diagram is command[condition] / commandHandler(). It means: when a command object has been received, and the condition is fulfilled if present, handle the command and go to the next state.

The model fixes what is allowed to happen, and what not. For example: repaying is only possible after withdrawing.

But that precision has a price. If you want the state machine model to be executed and to control the behavior at runtime, you need to model every possible transition from every state. Including its condition, if there are two transitions with the same event.

That's why there is a lot more repetition in the state machine than in the original code with the if statements. A way to reduce the amount of repetition is to use super states and sub states:

It is easy to define state dependent behavior in a state machine model. But a state independent rule like in any state (when condition X holds), do Y leads to several transitions. For example, I needed to add requestToCloseCycle to every super state.

You need people with the right skills to create the models. And it's not easy to communicate about the models with non-technical stakeholders. It's not the way they normally speak about user journeys.

Saying goodbye

It seems there are two options so far.

In the left corner: the if statement. Easy to start with. Low overhead. Best fit for applications that have no complicated flows of behavior. But it's easy to lose the overview when the behavior gets complicated.

In the right corner: the executable state machine model. Powerful. Proven. Precise. Gives you an overview of the behavior. But it's hard to define state independent rules. And state machine models are difficult to communicate about with non-technical stakeholders.

I stand in the third corner. I have found an alternative to state machines.
A solution that

• enables you to define conditions. But you don't have to in most cases.
• makes state dependent and independent rules equally easy to specify.
• uses language that all stakeholders can relate to.

Before I dig into the details, here's the sample state machine model rewritten using that solution:

Model model = Model.builder()
  .useCase(useCreditCard)
    .basicFlow()
        .step(assigningLimit).user(requestsToAssignLimit).systemPublish(assignedLimit)
        .step(withdrawingCard).user(requestsWithdrawingCard).systemPublish(withdrawnCard).reactWhile(accountIsOpen)
        .step(repaying).user(requestsRepay).systemPublish(repay).reactWhile(accountIsOpen)

    .flow("Withdraw again").after(repaying)
        .step(withdrawingCardAgain).user(requestsWithdrawingCard).systemPublish(withdrawnCard)
        .step(repeating).continuesAt(withdrawingCard)

    .flow("Cycle is over").anytime()
        .step(closingCycle).on(requestToCloseCycle).systemPublish(closedCycle)

    .flow("Limit can only be assigned once").condition(limitAlreadyAssigned)
        .step(assigningLimitTwice).user(requestsToAssignLimit).system(throwsAssignLimitException)

    .flow("Too many withdrawals").condition(tooManyWithdrawalsInCycle) 
        .step(withdrawingCardTooOften).user(requestsWithdrawingCard).system(throwsTooManyWithdrawalsException)
.build();
return model;

As you can see, the model is in the code. A model runner executes this model. The runner reacts to commands/events, similar to a state machine.

The basic flow is the "happy day scenario". The steps of a user to reach her goal. The other flows cover alternative and error scenarios.

A flow can define an explicit condition for its first step to run - e.g. after(...), anytime() or condition() in the sample.
If a flow has an explicit condition, the flow starts when the condition is fulfilled and the runner is currently in a different flow.
If a flow has no explicit condition (e.g. the basic flow in the sample), the first step runs after the runner has started, when no step has been run so far.

Starting with the second step of a flow, each step has an implicit condition. That condition is: run the step after the previous step in the same flow, unless a different flow with an explicit condition can start.
So in contrast to state machines, you don't need to specify the conditions after the first step.

Internally, state depending behavior is realized by checking a condition.
Every step contains its complete condition that defines exactly when the step can run. That's how requirements as code can treat state dependent and independent behavior alike.

Have a look at further examples to dig deeper.

When to use requirements as code

Many applications have dynamic internal behavior. This is true for distributed applications in particular. They need to deal with the fact that "the other party" is not available.

But from a user's perspective, these applications look quite predictable and regular. When I want to watch a show on Netflix or Amazon Prime, I follow the exact same steps each time until I can watch it. It looks like one step just follows the other.

That's the sweet spot for requirements as code, if used as an alternative to a state machine: defining the visible behavior of an application.

How the Credit Card application works now

• A client sends a command to the CreditCardAggregateRoot
• The CreditCardAggregateRoot uses the event repository to replay all the events for the credit card, to restore it
• The CreditCardAggregateRoot uses the above model to dispatch the command to a command handling method
• The command handling method produces an event and applies it to the CreditCard instance.
• The event handling model of the CreditCard instance dispatches the event to a state changing method

Conclusion

I hope you enjoyed my article. I also want to invite you to look at the library that I used throughout the article. Try it out in practice, and let me know the result.

If you want to keep up with what I'm doing or drop me a note, follow me on LinkedIn or Twitter. To learn about agile software development, visit my online course.
Last edited April 27, 2020: updated event sourcing process

Statecharts and state machines offer a promising path for designing and managing complex state in apps. For more on why statecharts rock, see the first article of this series.

But if statecharts are such an excellent solution for managing UI & state in Javascript (JS), why isn’t there more momentum behind them?

One of the main reasons statecharts have not grown in popularity within the front-end world is that best practices have yet to be established. It’s not abundantly clear how to use state machines with popular component-based UI libraries such as React, Vue, or Angular.

While it may be too early to declare best practices for statecharts in JS, we can explore some patterns used by existing state machine integration libraries.

Statechart machine

Statecharts work both for visual design and as the underlying code for a graph-based state machine.

Bear in mind that we’re in the early days of using statecharts with JS, and it may be worth experimenting with a variety of libraries or even developing your own. That being said, XState is currently leading the pack for statechart machine libraries in JS.

_[https://gist.github.com/ShMcK/769a179f89f1d7db1f83363cc2e42399](https://gist.github.com/ShMcK/769a179f89f1d7db1f83363cc2e42399" rel="noopener" target="blank" title=")

The above state machine code can generate a much more readable statechart diagram when passed as JSON to the XState Visualizer.

You can even work the other way, starting by visually designing and then exporting to an XState configuration using sketch.systems. We don’t have all the pieces in one place yet, but there are no serious technical barriers to an open source solution.

Now that we have an idea of what XState does, let’s look at what it doesn’t do.

XState Tagline: “stateless finite state machines and statecharts”.

So what does it mean for a state machine to be stateless?

Stateless machines

Stateless machines offer an unopinionated blueprint for state management — a kind of “roll your own” solution that doesn’t dictate where or how state in your application is stored.

Much like a presentational component, a stateless machine is made of pure functions, is immutable, and maintains no state. It tracks no past, current, or future — but it can be used to help you calculate each.

Managing your state can be as easy as storing it in a local state variable.

Stateless machines don’t give you much out of the box. To trigger a transition, we must always pass in the current state node in to find the next. XState can let you know which actions should be fired on each state change, but you’ll have to find a way to manage the actions yourself.

If you’re interested in a more complete solution, consider making your state machine stateful.

Stateful machines

A stateful machine tracks your node position on the state graph and manages the firing of actions. There is no need to pass in the current state on transitions — it tracks your current state node.

As a summary, the instance of the stateful machine above:

• determines the green state position at “Ringing”
• limits the possible purple’active transition events to CANCEL or SNOOZE
• fires the startRing action on entry
• fires the stopRing action on leaving the state

Of course, there is more than one way to create a stateful machine. We’re back to the question of where to manage state:

• within the existing component state?
• in a connected state machine?

Let’s explore some design patterns with examples, starting with stateful components.

Stateful components

A stateful component, as you might imagine, manages state within the component, or within a wrapping higher-order component. In React, this would be as state. Storing state within a UI library ensures that changes won’t be missed and will trigger re-renders.

This is the approach of a library called React-Automata that uses a higher-order component initiated by withStatechart.

React-Automata offers several patterns for using statecharts with components:

• state from props
• conditional rendering from a context
• state from actions

We’ll go over each pattern and consider the pros and cons.

State from Props

Passing state directly into components seems like the most obvious solution.

In React-Automata, state can be passed by accessing it on the machineState prop — a reference to the actual state machine.

But be wary, this is by no means best practice. In the example above, the integration has coupled the statechart to the component, leading to a poor separation of concerns.

Consider that the statechart and components can allow for a clean divide as they solve different problems:

• statecharts: when things happen, for example, enter state, actions fired
• components: how and what happens, for example, the view, user interactions

Alternatively, you could decouple the component from the state machine by conditionally rendering with a default of no render.

Certainly, there must be a more natural way to set up conditional rendering without having to turn all your renders into if/else and switch statements.

Conditional rendering from a context

State accessed by a context doesn’t need to be passed directly.

React-Automata provides a pattern for conditional rendering of child components using React’s context and a <State> component. Note that the value property can match on a string, array of strings, or even a glob-based pattern.

If the state value matches Ringing, the children inside of the State component will render. Otherwise, nothing.

State from context can help clarify the number of possible finite state view combinations. As in the case above, it’s clear there are only two possible configurations.

If view configurations start to get out of hand, React-Automata offers a render prop pattern that passes in a boolean based on the value.

Similarly, it’s possible to conditional render based on context actions.

Conditionally rendering based on state or actions maintains a coupling between the statechart and components, but less explicitly through context. How might you give components their isolated state apart from statecharts?

State from actions

It’s possible to use statecharts to update the internal state of a linked component using actions as triggers.

React-automata checks the methods on a component and calls the functions if the names match the actions being fired.

As an example, the onEntry action startRing is fired as the state machine enters Ringing, causing the AlarmClock state to change to ringing. On leaving the Ringing state, stopRing is fired, and ringing is set to false.

Note that, although of these methods are called with params, the methods already have access to whatever they need from machineState through props.

Using internal component state managed through actions leads to a strong decoupling of components from state charts. However, it can also create a degree of clutter or confusion in components. It is not explicitly clear how or when methods will be called without examining the names of actions in the statechart. For this reason, I often call my actions and methods enterX or exitX in order to make it explicitly clear why and where they are being fired.

External state machines

Another option worth considering is storing state outside of your UI framework. As with other state management libraries like Redux, components can be connected to an external state machine and updated with “on state change” and “on action” events.

As an example, XStateful is a wrapper around XState that handles state, transitions, emitting events, triggering actions, and more.

XStateful works well with a React connector called XStateful-React.

XStateful-React has much in common with React-Automata. But there is at least one signficant difference — the state machine instance is not managed within any component.

So how does external state from reducers work in XStateful?

State and data

Applications often require more than just the state node in a state graph— they require data as well. Often this data needs to be synced across components, in a way that can be frustrated if it must be passed from the uppermost shared parent.

There are existing popular solutions for syncing data, such as Redux, or my state management wrapper for Redux. Unfortunately, these don’t play well with many state wrappers such as React-Automata due to an open issue with passing refs in React Redux (see this open issue with connect() and React.forwardRef).

A complete state solution should manage both state and data.

XStateful offers just such a state and data solution using a state reducer pattern, similar to Redux.

State machine subscribers listen and update changes based on actions emitted from the state machine. Note that XState refers to data as extended state, or extstate.

This particular Reducer pattern may seem unfamiliar, however, it’s heavily used in projects such as ReasonReact.

Data can also be accessed in conditional renders on the property cond.

Be careful with using state to conditionally render components, as it creates a non-deterministic set of possible states. No longer are you limited to the number of states, but now to the number of state and data combinations. You lose out on deterministic features, discussed later in the testing section.

This data can be passed into your component using a render prop pattern.

There is less of a need for state management tools like Redux if data can be stored within a complete state machine tool like XStateful.

Testing

State machines also offer a better path for front-end testing.

The deterministic nature of state machines creates the possibility of simplified front-end testing.

In React-Automata you can autogenerate snapshot tests using testStatechart, a method that takes the XState configuration and the component.

testStatechart runs through the state graph and creates a Jest snapshot test for each possible configuration of the component. It will toggle on and off your various <State />, <Action /> components, leading to a recording of all possible conditional rendering combinations.

Devtools

Devtools play an active role in what makes a library developer-friendly — debugging can be the hardest or most straightforward part of your job.

In this respect, React-Automata offers a helpful integration via Redux Devtools. Each connected component becomes a named instance in the devtools, and each transition and action are displayed chronologically as actions are presented in Redux devtools.

XState offers an entirely new set of variables to track. Consider the following example by Erik Mogensen on the kinds of information an XState debugger may track.

This is not to say that state machine devtools need to look like our existing devtools. State machine devtools present an opportunity for a more visual debugging experience.

Conclusion

While we’re still in the early days of statecharts in JS, there are enough options available to start developing applications on top of XState. We can learn from these development patterns to both improve available libraries and to create tools to support the enormous potential of visual-based programming.

Having developed applications with statecharts over the past three months, I’ve personally found these new patterns to be a breath of fresh air. Collaboration has become much more comfortable, as team members can visually grasp the underlying logic of a significant and growing system.

My hope is that this article will help others find statechart-based development more approachable. If you found it helpful, give a clap and pass it on :)

A roadmap for developing applications with state machines & statecharts

_Photo by [Unsplash](https://unsplash.com/photos/lRssALOk1fU?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="_blank" title="">rawpixel on <a href="https://unsplash.com/search/photos/map?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener" target="blank" title=")

Why does state management seem particularly tricky in JavaScript? Is it the inherent complexity of modern apps, or just the tools? How do other fields of engineering develop reliable and predictable systems? Is it possible to draw a system and transform it into code, and vice versa?

Let’s explore a paradigm shift in state management towards visually designing systems with state machines & statecharts.

Concepts > Libs

State management has been on my mind for a while now. I’ve experimented with various state management libraries: Flux, Reflux, Redux, Dva, Vuex, Mobx, and also my own.

There’s no point arguing which is the 10x solution. State libs are different flavors with the same ingredients. They are a piece of the puzzle—they make it easier to sync and connect data.

The solutions that require our focus next concern the bigger picture:

We need to get better at planning & designing systems.

Break All The Things

Think of a user interface that you would consider elegant. Something built to withstand a barrage of random user interactions — you know, the kind of unpredictability that occurs when a user pushes a button more times than expected, interacts with inputs in an unexpected order or otherwise leads you to question your faith in humanity. Real life is hard on systems.

I’ll predict the project you’re thinking of.

Well… you’re probably not thinking of something built for the web, where the philosophy seems to be “move fast and break things”.

Judging by the frequency of updates, you’re probably not thinking of mobile either.

You’re probably not even thinking of something built recently. We don’t necessarily seem to be getting better at building reliable products.

I think I know what you’re thinking of…

Am I right? ….No?

You might not even recognize this as the Sony Walkman of the 1980s.

As a kid, I received a cassette player like this from a friend who had upgraded to a portable CD player. I understand that some younger readers may find the mention of both of these devices unfamiliar — think of the Walkman as an iPhone, but with larger buttons and greater destructive potential. My primary mission: break it.

I would try all combinations of buttons to see what might happen:

• Try to eject while the tape was fast forwarding
• Hold fast-forward and rewind down at the same time

Try as I might, the Sony Walkman held up better than most websites do today.

Engineering Interfaces

Electronics like the Walkman withstood the gauntlet of user testing without any capacity to hide or disable elements of the user interface. Any button could be pressed at any time, anything could happen. And yet it seemed unbreakable.

It led me to wonder:

Perhaps electronics offer a better paradigm for how we can build interfaces on the web.

What can we learn from the ancient design process of electronics? How can we better engineer applications? Marty, we need to go back to the future!

Electronics & The Web

Can electronics teach us a better way to create applications in the browser?

Consider that components produced one of the most significant shifts in web development over the past five years. Perhaps there are other concepts we can borrow from electronic engineering?

As web developers, we’ve had it good. Like. Really good. Found a bug? Deploy an update to your server within the hour.

Other fields of engineering aren’t so forgiving. A problem in hardware often results in a device going in the trash. Embedded developers must be careful to ensure a firmware update doesn’t drain the battery or crash all existing devices.

Web developers have the luxury to be reckless.

Not to mention, app developers have rarely faced the same resource limitations as the creators of electronic devices. When was the last time your primary focus was performance and memory usage, rather than just making the damn thing work? A threshold of 60 frames per second is a low bar. But the bar is rising as we start building increasingly complex apps to run on less powerful mobile and IoT devices. We are bordering on an engineering problem that low-level engineers have experienced for decades.

Constraints breed creativity. Limitations lead to better design.

To see how embracing limitations can lead to better design, we’ll need to drive back towards basic state management fundamentals.

Ye Old/New State Management Fundamentals

The direction of conversations in the web community tends to lean towards NPM packages rather than fundamental computer science principles.

Engineers aren’t asking “which library is better? as much as they’re asking “how do we design a better system”?

We can start with some basic principles of good design:

• distinguish between indeterminate data and finite states
• limit possible transitions from one state to another
• design visually

I’ll work through these along with my own path, and 8 realizations that followed.

1. State !== Data

In programmatic systems, the difference between state and data is blurry. They both live in memory, and so are treated the same.

In React, state and data share the same name and mechanisms:

• getting: this.state
• storing : this.state = {}
• updating: this.setState(nextState)

In electronics, there is less confusion over the distinction between state and data.

State represents a finite number of modes that the system can be in — often defined by the circuitry itself. For our Walkman, think “Playing”, “Stopped”, “Ejected”. Like a “mode” or “configuration”, state is countable.

Data, on the other hand, is stored in memory with a nearly infinite set of possible settings. For our Walkman, think of the track that is playing, “Song 2”. Data, like music, may have infinite possibilities.

Whatever this DataLoader component below does, the state can only generate a limited set of views: “loading”, “loaded”, or “error”.

Separating state and data can lead to less confusion, and allows us to construct applications based on finite state machines.

2. State is Finite

Electronics developers have long known that a predictable interface is one with a limited and controlled number of states. Without a controlled number of states, systems become difficult to debug and impossible to thoroughly test.

In a finite state machine, states are explicitly defined. Transitions are the set of possible events you can trigger to move between states.

As an example, triggering a transition with the event “STOP” will move the state to “Stopped”.

In React, we could define a basic Walkman as having at least two states: “Stopped” or “Playing”.

Check out this CodeSandbox.

In a finite state machine, the system is always in one of the possible configurations. The view has no possibility of being anything but “Playing” or “Stopped”. Testing both can give us confidence the system works the way it should.

3. Manage Complexity in State Machines

Let’s look at what happens when we start adding two new states to the state machine example: “Rewinding” & “FastForwarding”.

When states are equivalent, they are deceptively easy to add. Each state is like its module that can be developed and tested in isolation. But be careful, state transitions should not always be possible.

We should worry about uncontrolled transitions between states.

Maybe you caught it. We introduced a bug above. Take a minute and see if you can discover what went wrong.

4. Guard Transitions

It seems the cassette tape is all tangled up as we’ve allowed users to jump between rewinding and fastForwarding without stopping the tape in between.

As a solution, we can add guards to our state transitions. Guards are conditions that must be met for a transition to occur. As an example, we can ensure that the events FASTFORWARD , REWIND , & PLAY can only trigger when the state is “Stopped”.

Unexpected state transitions are bound to happen unless we rethink the way we plan and design our state management.

As we add additional states like ejected, we have to think through which state transitions can be allowed and under which conditions. With a Walkman, you can eject the tape by pressing stop while the tape is in the stop mode. To add this functionality, we have to add even more guards and determine which transitions are possible.

The likelihood of unhandled state combinations multiplies as additional states are added. This is not a scalable solution. Each additional state results in a check of all transition guards.

It starts to feel more like state is managing you.

The problem with managing guards stems from the way state is being represented: “Stopped”, “Playing”, “Rewinding”.

The ideal data structure for state is not a string or an object.

But then what is it?

5. State is a Graph

The ideal data structure to represent state is often a graph. State graphs, commonly known as state diagrams, provide an intuitive way to design, visualize, and control state transitions at each node.

This is not new news — electronic engineers have been using state diagrams to describe complex systems for decades.

Let’s look at an example on the web. AWS Step Functions provide a visual interface for graphing the workflow of an application. Each node controls a lambda — a remote function called in the cloud — with the output of each function triggering the input of the next.

AWS Step Functions

In the example above, it’s clear to see how a user’s actions move through each step, including possible errors and how to handle them. Adding additional steps doesn’t result in exponential increases in complexity.

An engineer might remark how much Step Functions have in common with PLC (Programmatic Logic Controller) Block Diagrams. A designer might remark how much they have in common with workflow diagrams. Shouldn’t the way we design state have more in common with the way we plan applications?

6. Scaffold on State Graphs

State graphs become the scaffolding for your application.

As an example, a state graph of our walkman could produce a more visually understandable and approachable representation.

Walkman State Graph

Without delving into code concerning guards, we can tell there should be no possibility to jump from “Rewinding” to any other state but “Stopped”. Rather than outlining all the transitions your interface shouldn’t do, you lay out what it can do. Development shifts from a defensive bottom-up coding approach to a top-down designing approach. This shift alone is 10x.

State graphs are more intuitive, more accessible to debug, and more able to absorb changes in requirements. Alongside state machines, changes in each state can be isolated from their neighboring states. Not to mention that much of the complex transition “guard” logic can be encompassed in a visually comprehensible format.

Unfortunately, state graphs can be a ticking time bomb.

Densely connected graphs don’t scale. Consider what would happen if we added another 4 states to the graph above. Readability reduces and repetition increases, with entangled arrows pointing in all directions competing for space. This spaghettification of a state graph is known as a state explosion.

Luckily, there is a way to reduce the visual complexity of designing complex state graphs using a formalized way of describing systems: let’s explore statecharts.

7. Master Statecharts

I first learned about statecharts from Luca Matteis’ presentation on How to model the behavior of Redux apps using statecharts at the Vancouver React Meetup. The next day at work, I brought up this “new” paradigm for state management, only to find many of my engineering co-workers were already familiar with the concept. I work at an IOT based company alongside many hardware and embedded developers. We’re hiring ;)

The concept of a statechart dates back to 1987 when mathematician David Harel published a paper on visually describing complex systems, such as the below example of a quartz watch.

Statecharts are both intuitive and easy to master once you understand the language.

Statecharts introduce a variety of new state types:

• initial state — the starting state marked by a dot with an arrow.
• nested states — states that have access to the transitions of their parent.
• parallel states — two non-touching states represented by dotted lines.
• history state — a state that remembers and can return to its previous value.

Besides, statecharts can encompass how and when transitions & actions are triggered:

• transition — a function that triggers a state change based on a named event. “Stopped” → transition(‘Play’) → “Playing”
• guard — a condition that must be met for a transition to occur. For example, “play” cannot be triggered if no tape is present, or if the tape is at its end. “Stopped” → transition(‘Play’) [hasTape] → “Playing”. Multiple transitions can be possible, given an order.
• action— triggers that occur based on a state change. For example, triggering a tape to start playing when the state enters “playing”. Actions may occur onEntry and/oronExit.

Rewriting the Walkman example as a statechart removes the redundancy found in the state graph. Notice how there is no longer a need for repetition with “STOP” events. Statecharts are scalable — it’s not hard to add additional parallel states such as “Recording” and “Volume”.

Statecharts are more than just a concept for visually describing applications.

Statecharts can generate the state machines that underly an application.

You can convert visuals to code, and vice versa. View your application logic as a chart, or draw it.

8. Statechart Tools

Statecharts offer a promising future for genuinely designing systems — and not just on paper. While tools have been around for other programming languages, JavaScript is just now starting to show a boom in statechart tooling.

C & Java developers have tooling available for coding with and alongside statecharts. As an example, Yakindu Statechart Tools brings together the worlds of visual design and code. I recently learned Yakindu also includes a Typescript code generator.

The same tooling is finally becoming available for JavaScript as well.

Sketch Systems provides a way of designing systems in markdown that can then be used to prototype in JavaScript. While Sketch Systems does not yet support actions or guards, I’ve found it very useful for prototyping and testing state charts.

_[https://bit.ly/2lZhqOB](https://bit.ly/2lZhqOB" rel="noopener" target="blank" title=")

Sketch Systems allows you to export your charts to XState, a statechart-based JavaScript library with its visualization and clickable state prototyping tool.

_[https://bit.ly/2uJydt9](https://bit.ly/2uJydt9" rel="noopener" target="blank" title=")

Imagine more advanced tooling within your editor. Imagine your workflow as you toggle between visually designing and manually coding your application logic. It’s worth the work we’ll have to put in as a community to advance the tooling, libraries, and editor plugin’s we want to better support using statecharts.

Conclusion

Complexity snuck up on us in the JavaScript community. I don’t think we were ready for it. I’ll admit it took me a long time to get good at planning applications. I’d sketch out a component tree and some state shape. Watch prototypes iterate into production. But how could I be any good at planning applications without a formalized visual language to design state diagrams?

For a long time, I’ll confess that I approached state management more like a mystifying art. I was unaware that there was much to be learned from other areas of computer science with a long history of building and managing complex systems. I grew to understand that there’s value in looking to the past, as well as looking sideways at the fields of engineering around us.

We can learn from engineers who have pioneered and developed decades old solutions for creating complex — yet predictable — systems. We can build upon tools & libraries as an ecosystem to support the visual design of application logic. And we will do it because JavaScript needs all of this.

The future of designing applications in JavaScript is looking brighter than ever. This article has all been very high level and likely left more questions than answers. In part 2, I’d like to look more in-depth at patterns for using statecharts with components.