Welcome to the very first issue of the Stately Newsletter! I’m really excited to begin an open, thought-provoking discussion on how we manage state in the ever-evolving, modern software and web ecosystem.
Who am I?
But enough about me. This newsletter is about you. I want to have an open discussion with you about the state management problems you face in your day-to-day work. We’ll be exploring all sorts of past research and new insights about different state concepts, techniques, tools, and more that will help you be productive.
So feel free to reply to this email with any topics you would like to discuss. I’m all ears! 🎧
Speaking of the initial issue, I want to talk briefly about what an initial state is. For those familiar with finite state machines, this is the default state that a machine is in, since it always has to be in exactly one state. It’s the “starting” state, and all other states should be reachable from that starting state.
Consider an app that you’ve recently worked on. What is the initial state of it? It might be a login screen, or a splash page, or a loading spinner, or the main app itself.
Some of you might say “it depends” – for instance, the app might initially be on the dashboard if the user is already logged in; otherwise, it might be on the login screen.
But here’s the interesting thing - it does not depend! Your app can only have one initial state, and that initial state is always the same. Always.
Before you disagree, let’s work the previous example through. You might think “well, the initial state is either the dashboard or the login screen, it depends…” – but that “it depends” state itself is the initial state!
When you turn on any sort of machine, it might conditionally show an initial screen, but the first (invisible) thing that it does is decide which screen to show. This can be instantaneous; this can take time. But the circuitry never changes when you turn it off and back on again (sorry to disappoint if you thought this was how all IT problems were solved).
Hopefully that gives a little more insight on how you should model your app states. The initial state should always be the same state.
🎹 I recently discovered midi.city, which is a really cool online synthesizer built by Jack Anderson. He told me that the app migrated to XState from Redux + Redux-Observable. There are so many UI details in here and non-trivial state transitions (try horizontally scrolling the keyboard ⌨️↔️, and watch the key bindings update!), on top of it being really fun to play with.
We’re working really hard on the upcoming XState version 5. There won’t be many breaking changes, but there will be some subtle ones (it is a major release, after all). The main goals for the new version are:
- Simplification. With the “everything is an actor” mentality, communication between machines (and anything else) will be a lot more clear… and even visualizable. Sequence diagrams, anyone?
- Minification. With simplification and modularization, the next version should be a lot smaller. One of the goals is for you to be able to import only the features that you need.
- Visualization. A new visualizer (and dev tools) is also in the works, which will be compatible with V5, as well as machines authored in XState V4.
- Implementation. The internal algorithms have been completely simplified and rewritten to more closely adhere to the SCXML spec. This will make XState machines more easily portable to other libraries in other languages that implement that spec.
There are many other planned updates for XState V5, and some important fixes planned for V4 soon, of course.