9 posts tagged with “state”

Does the world need another state management library? Probably not, but if you've been interested in XState, you're going to want to check this one out.

XState Store is a simple & tiny state management library largely inspired by XState. If you just need a way to update data in a store and subscribe to changes in the store, XState Store is for you. It is:

• Extremely simple. Provide initial context and transition functions to the createStore(…) function, and you're good to go.
• Extremely small. Less than 1kb minified and gzipped.
• XState compatible. Shares actor APIs with XState, making integration/migration easy if (when) you need to handle more complexity.
• Extra type-safe. Written in TypeScript, it provides strong event and snapshot types, automatically inferred from your context and transitions.
• Event-based. Works just like XState; send events to trigger transitions.
• Immer ready. Easily add Immer for "mutable" context updates with createStoreWithProducer(producer, …).

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.

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.

Statecharts are a visual language used to describe the states in a process.

You may have used similar diagrams in the past to design user flows, plan databases or map app architecture. Statecharts are another way of using boxes and arrows to represent flows, but with XState these flows are also executable code that can be used to control the logic in your applications.

State machines offer several API’s for expressing state. Like other tools, you can keep arbitrary values in a store (usually expressed as an object) called context.

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

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.

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.