menu

Statecharts

Statecharts are a precise, visual way of modeling the behaviour of complex reactive systems. They describe how things work, and can help you get your code doing exactly what you want.

Channels
Team
Posts
Chat
Members
Info
Show previous messages

July 11, 2019 at 12:17pm

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.

  • reply
  • like

July 11, 2019 at 11:13pm

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.

  • reply
  • like

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

  • reply
  • like

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

  • reply
  • like

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.

Edited
  • reply
  • like
  • reply
  • like

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?

Edited
  • reply
  • like

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

Edited
  • reply
  • like

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

  • reply
  • like

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

  • reply
  • like

This thread helped:

  • reply
  • like
  • reply
  • like

July 12, 2019 at 12:31pm

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.

like-fill
1
  • reply
  • like

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?

  • reply
  • like

Is there one?

  • reply
  • like

No, I was just planting a seed. :)

  • reply
  • like

July 18, 2019 at 12:20am

@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?
Edited
  • reply
  • like

July 20, 2019 at 10:37am

@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/

Edited
  • reply
  • like

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.

Edited
  • reply
  • like

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)

  • reply
  • like

@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: {/* ... */}
}
  • reply
  • like

@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?

  • reply
  • like

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.

  • reply
  • like

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 🙏

  • reply
  • like

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

  • reply
  • like