Statecharts

Right; at the end of the day, XState (and really any state machine library) is just an event emitter - you send it events, it calculates state transitions and emits those states (and possibly effects). All frameworks have a way of handling these "event emitter" objects... just in different ways.

Ok. If all of the machine and chart logic can be pure and all UI Actors are, by necessity, impure and stateful perhaps Xstate can be totally decoupled. Remaining as part of the app core.

That means that Svelte has full control over its domain and hands control back to Xstate and app logic, so to speak, via messages.

So, Xstate never has to pass a machine into the UI (unlike how the dev suggested).

Is it possible to treat all interactions from Xstate to the UI as a side-effect? The Dev did indicate that this worked really well and I thought perhaps he did not design ALL of the app around this mechanism.

If the only interaction with the UI was via side effects we could maybe solve the coupling problem experienced by the Dev. What do you think?

However, I think this might benefit from a unidirectional data flow design between pure app logic and impure stateful UI.

Which means making Xstate the single source of truth for the entire app. Much like Redux.

Except for the UI state, which can remain in the UI Actors.

This thread helped:

The Actor model is unidirectional. An actor has its own local state, which it can send (unidirectionally) to another actor (or it can send messages, etc.) That receiving actor can never update that local state directly (not bidirectional) - but it can send messages to that actor, which might decide to update its own local state.

There is never a single source of truth, not even in a Redux application. That's why the actor model is so important to consider.

Which one of you brainiacs is working on the Firefox Xstate Dev Tool that shows me the state of the different parallel machines and shows me the context state?

Is there one?

No, I was just planting a seed. :)

@davidkpiano hi David, could we think of:

• Services/Interpreters as Sagas
• FSMs and FSCs as Process Managers (PMs)...

Where:

• Sagas are pure, stateless and have high level control of the FSM and FSC PMs;
• PMs are somewhat impure, stateful and take commands from Interpreters and execute app code?

@davidkpiano is it possible to build and Xstate app with the decoupling discussed in this article: http://www.thinkloop.com/article/extreme-decoupling-react-redux-selectors/

He writes: "There are no backend services, or state containers or ajax requests or business logic in the view object - only a hierarchy of components responding to passed in data."

This is how I want to use Svelte and Xstate but it seems like neither library promotes this model.

Hey folks! We're in the process of evaluating a stack for a new product. Roughly speaking, it will need to execute effects based on specific state transitions. Our data source is Kafka. For example, when we receive a user message, we want to compare it to the one we have in cache, and if it changes state from "invited" to "joined" we want to trigger a welcome e-mail through Mailgun. Conceptually this sounds like something XState would be well suited to, but I'm not entirely sure how I would structure this. Can someone shine some light on whether XState is the right thing to use here, and if so, roughly how I would model this (given state x and new state y, trigger an effect for that transition)

@steven-langbroek Great question. There are two effect models:

• Mealy machines have effects based on current state and input; i.e., the transition. This would be "transition actions"
• Moore machines have effects based only on the current state. This would be "entry" and "exit" actions.

Since you're basing the effect on transitioning from one state to another, that would be the Mealy model, and you'd place effects on the transition:

states: {
  invited: {
    on: {
      JOIN: {
        target: 'joined',
        // transition actions
        actions: 'sendWelcomeEmail'
      }
    }
  },
  joined: {/* ... */}
}

Hey David! Right, ok. I'll see if I can whip up a prototype for my teammates. If I get stuck, mind if I share a CodeSandbox?

Ok, so maybe I'm misunderstanding something here. The thing with Kafka is, you don't receive events, you have an existing state, and you receive a message, which is a new, full state.

Ok, so I've clearly got a kink in my thinking here, I'll start prototyping, if I have concrete questions I'll come back with those. Sorry 🙏

Sure, feel free to share a CodeSandbox @steven-langbroek