The ubiquitous waiting/loading/error(msg)/success(data)
Lots of frameworks and state management libraries already lean towards helpful design, in languages with async and ADTs as first-class citizens you've got a real leg up, but at the end of the day it comes down to preventing impossible states.
You can't have an error message when in the success state, you can't have success data while loading or waiting.
By preventing this at compiletime, it also means the UI can't ever show bogus data (i.e. it's impossible to have a success screen with the error message dangling at the bottom because somebody forgot to clear it)
Statecharts are language-agnostic, whereas your proposed solution appears to be tailored specifically for TypeScript or other strongly typed languages. In this context, Statecharts offer a more versatile and generalized solution compared to your suggestion.
general is not always better though. There's a tradeoff to other things like readability.
If a TS typed switch statement, say, offers the same guarantees of covering all options yet is just run of the mill JS that anyone can read and instantly grok, and covers 99% of usecases in run of the mill web dev product work, then to me that's an argument that it's the better solution.
I agree with you, as mention in another comment (https://news.ycombinator.com/item?id=35331199), that if you can cover all the cases with conditionals and you don't have nested states, don't use Statecharts. Just like distributed architectures are not for everything but more advanced use cases, so is Statecharts. It's a tool to help you manage great number of states, not just a couple.
Yes, sorry if that wasn't clear, but the transitions here are also typically restricted. For example, business logic may dictate that you can't go from waiting to success, you must go through loading and fetch fresh data. This prevents the problem of displaying stale data, at compiletime
As a huge proponent of Statecharts, I agree. If what you're doing is really simple and only have a few amount of states (as conditionals introduce those states no matter if you use state machines, statecharts or conditions), it makes sense to keep things simple.
But once you start having much more than that, or nested states, Statecharts makes it really easy to build reliable, performant and easy to change flows.
I can see that. Do you have some examples of common UI usecases which are the other side of the line here and for which statechart based code is better?
Ultimately every UI is a collection of various (often contradictory) states.
Example: Even typing into a text box on Hacker News is a new UI state: you have a different set of shortcuts, the keyboard works slightly differently, the browser has to keep track of the input if you suddenly press back and then forward again (some browsers maintain input in these cases), undo has to work within the scope of the textbox etc.
The more complex your UI becomes, the more contradictory states become, and need to be tracked. We're posting something over XHR/WebSockets? X amount of elements on the page have to be disabled, some state has to updated with save progress etc. We are logged in/logged out? We need to show a different state. There's an error in some part of the app? We need to block user from doing something and show errors etc.
If you can split those into actual states and allow interface and actions based on the current state, it becomes easier to reason about what is going on ini your app
> What everyday UI thing is better done with this than other methods?
All of them.
> Why is it better?
Because it specifies a workflow that actually matches what you want to do instead of employing a pile of ad-hoc rules that quickly become an unmaintainable mess.
If you have animations and async calls and multiple screens/pages, you have an application with application states which transition in response to inputs. That's what state machines are designed to handle.
Storyboards are state machines. Navigation components are state machines. UI binding layers like redux are state machines.
I hope you take this in good faith, but one often encounters claims in programming that a particular solution approach is universally better than alternatives for all usecases, often without accompanying concrete usecase examples, and the latter is exactly what I'm trying to dig out.
I am not saying you're wrong, but if you're right this would be the first case I've seen of it in my career so far :-)
User onboarding, setup wizards, feature announcements, or, more generally, the modeling (and maybe implementation) of incremental, progressive user flows. The only caveat is that they tend to require the machine's state to be persisted so that the user doesn’t experience the same state(s) again.
Truthfully, using state machines at runtime for the use cases above is sometimes too heavy. That distinction is actually a big input to what I’ve been building at Dopt.
Our platform lets you build state machines that are initialized per user in your application via our SDKs—you design the machines in the platform, and we provide APIs to let you transition them based on user interaction/input. We’ve taken a bunch of inspiration from Xstate and statecharts. I actually wrote up a blog about how we took inspiration from the latter https://blog.dopt.com/state-machines-and-their-influence-on-...
The real benefit for our project was being able to statically define, and therefore export the business process the app would follow. Once it's exportable, it's validatable and configurable.
IMO the JSON was hard to read, but we had a plan to build a GUI config builder that exported the state flows.
Ah yes, I can see this. I've also seen this kind of 'universally understandable spec of behaviour' attempted from the other direction with things like plain-language cucumber test definitions.
Emphasis on attempted, not sure I've ever seen it actually work as envisioned. Can see how bringing this directly into the code could remove some hurdles though.
Must say though I am a little skeptical on the readability / comprehensibility of the JSON format as you point out, but it's certainly a cool idea.
I use it for in component logic in vue. Used to have a collection of boolean or enum variables that represent the state of the component and change according to actions e.g. const isLoadingUser = ref(true). This works but often leads to unforeseen states being possible and just isn't very clear. In contrast, with xstate you define all states and legal transitions and wire everything up to send events, you can write guards that prevent transitions. I transitioned all my complicated multi stage forms to xstate and since doing so they've become substantially more robust. I highly recommend trying to out.
This is only incidental to your actual question (unless you’re into making widget toolkits), but have you seen the state diagram for a button widget[1]?
Almost everything can be written as a state machine and arguably it’s very useful to do so, for example let’s take a note taking app, you can probably list a set of transitions that can happen to change the state of the app. Keeping the state changes separate from the UI is a good thing. In a way redux is a state machine too. Try it out on a project and see if it works for you!
ChatGPT it, it’ll do a better job than I will and it’ll be relevant to your requirements.
It’s the same situation as redux though but with more formality and it’ll draw you a nice diagram too.
“Hey ChatGPT, can you show me an example of using XState typescript library to separate business logic from UI code in a computer program and discuss why XState might be useful for this purpose?”
The example it gives is really incredible… and obviously you can refine what it’s doing in context for your own understanding.
For example, the browser extension Redux DevTools implements "time travelling" by taking snapshots of the entire state on every state change. This is enabled by the fact that in Redux, state changes are separate from the UI. This same principle can be used for undo/redo history.
Another example is sending and receiving state changes from anywhere other than the UI, such as via WebSockets in a collaborative editing environment.
Got it, makes sense. At least in React this has been the long-understood default expected pattern though right? Like, you pass down props from something higher up. Is this a property of state machines or a library like this one?
Not trying to be pedantic I promise, I really want to see the value of this, but not sure I can without an example clearly comparing this against just a few if statements or something in pure JS, for something 'everyday'.
State machines make sense to me in a theoretical sense for something with a pretty complex tree of state transitions like a game but for the 99% run of the mill UI work you get in building web products I am not sure I see anything that brings value worth the tradeoff of having to learn yet another library.
That's true, keeping state and state changes separate from the UI is the default expected pattern in React, particularly with Redux. Or at least it was before hooks, which obfuscated the whole situation in my opinion.
And it's true that this separation of state and UI is just a general design pattern, which can be implemented with a plain object and switch statement, or a small class with a few methods - it doesn't have to be state machines.
So I'm with you in your conclusion, or skepticism perhaps - I prefer to apply the minimal pattern that achieves the same thing, rather than having to learn another state management library like Xstate or even Redux. But then again, I can see the value of such a library in a group/company environment, where you want everyone to learn and follow certain ways of organizing things, where new members can read the documentation, and understand how to add and change existing code in a predictable pattern.
This is not my understanding of React - can you elaborate?
Its original value prop was one way data flow and pure functional UI based on passed in props. It allows for side effects, to get certain things done pragmatically, but in my view does not encourage them in any way.
Fair enough, but what's a rudimentary usecase for 'the modern web'?
What everyday UI thing is better done with this than other methods? Why is it better?