5 posts tagged with “Redux”

It’s been about a year since we’ve released Stately Studio 1.0, and a lot has happened. Stately Studio is essentially a visual software modeling tool that strives to make it easy to create, manage, and use state machines, no matter how complex they may get. Primarily, it served as a powerful set of devtools for XState (an open-source library for creating state machines, statecharts and actors in JavaScript and TypeScript). You could import XState code to a state diagram, modify it visually in an intuitive drag-and-drop canvas, and export to XState. Eventually, we added more export options: JSON, Markdown, Mermaid diagrams, and stories.

But Stately Studio has bigger ambitions than just being a suite of devtools for XState. We’ve frequently heard that these state diagrams are an important source of truth for critical app logic, serving as documentation for the entire team that stays up-to-date with your code. But a reliable source of truth for app logic is a need for all apps, not just those that use state machines directly.

That’s why we’re so excited to release Stately Studio 2.0, which aims to meet developers where they are, no matter which libraries, frameworks, or even languages they use. There are many benefits to modeling app logic with state diagrams and the actor model, and we want to enable developers to take advantage of those benefits to build more robust, feature-rich, and maintainable app logic faster.

XState can be used wherever JavaScript runs, whether on the backend or frontend. Because the code it creates can be visualized, it’s great at handling complex use cases - being able to see what a complex piece of code does can be extremely useful.

Let’s look at each use case one-by-one.

Many React applications follow the Flux architecture popularised by Redux. This setup can be characterised by a few key ideas:

1. It uses a single object at the top of your app which stores all application state, often called the store.
2. It provides a single dispatch function which can be used to send messages up to the store. Redux calls these actions, but I'll be calling them events - as they're known in XState.
3. How the store responds to these messages from the app are expressed in pure functions - most often in reducers.

This article won't go into depth on whether the Flux architecture is a good idea. David Khourshid's article Redux is half a pattern goes into great detail here. For the purposes of this article, we're going to assume that you like having a global store, and you want to replicate it in XState.

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.

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".