The Stately team is very excited to announce a new feature we’ve been working on for quite some time! Join us in welcoming Stately Sky to the Studio. Lovingly built with PartyKit, Sky is our new serverless platform for running workflows within the Studio. With Sky, users may now run their statecharts as live machines in minutes, complete with XState v5 actors and multiplayer support.

It’s been a while since our last changelog update, so let’s get right to it!

You might have heard of “state machine” or “finite-state machine” before. If you look up state machine on Wikipedia, you’ll read that a state machine is described as a “mathematical model of computation,” followed by a bunch of symbols and computer science jargon that doesn’t immediately seem to apply to your team’s work.

However, state machines are really useful for describing almost any kind of logic, feature, user story, sequence, process, workflow, specification, and more.

State machines are great for modeling state in applications. However, we often need to persist and restore state across sessions - for example, when a user closes and reopens their browser. In this article, we’ll explore how to persist and restore state in XState so your frontend applications or backend workflows can pick up where it left off.

You can now open your machine in CodeSandbox or StackBlitz. These options show when you select either JavaScript or TypeScript export formats in the Code panel. When you open your machine in these external editors, it will be deployed as a demo app so you can jump quickly into prototyping and get an example of how to integrate your machine into your codebase.

Our team knew early on that users needed the ability to share machines in the Studio and build on each other’s work. We also needed the Studio to be an effective tool for teams to work together and share context. But how do we do that safely, making sure the right eyes were on the right machines? And how do we protect against accidental mishaps that have plagued devs since the dawn of the computer? Being a distributed dev team ourselves, we’ve shared these same pain points and decided to build a solution directly in the Studio. Enter Stately teams, our way to provide privacy and safety while allowing effortless collaboration.

The Stately team has had another busy week. The editor now has event schemas, and we’ve made many more improvements. Let’s dig in!

We’ve released many new features recently, but we’ve also made minor enhancements and bug fixes to improve your Stately experience.

As software architecture grows increasingly complex, developers and project managers often grapple with the challenge of visualizing and organizing application logic. This is where state machines and flows come into play. State machines are a powerful tool for modeling application logic, and flows are a great way to visualize and organize state machines. At Stately, we’re committed to making state machines and flows more accessible and easier to use.

But state machines, though powerful, have a learning curve that can be a bit intimidating. And then there’s the blank slate problem: where do you even start when modeling a flow? Furthermore, when flows get large, how can you apply broad changes in a more natural way while keeping the flow intact and logically correct? These are some of the challenges we set out to solve with our new experimental generative features.

New generative features​

In response to these challenges, we are thrilled to introduce two experimental beta features:

• The ability to generate a flow from plain text
• The ability to modify an existing flow from plain text

As a Stately Pro user, you can now auto-create machines from text descriptions with our new experimental feature, Generate flow. You can generate a flow for a new machine or use the flow description to describe how you want to modify your current flow.