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.

React expects and recommends you to use side-effects.

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.