# Putting the "Act" in Reactive: From Observables to Actors

Canonical: https://davidk.dev/talks/putting-the-act-in-reactive-from-observables-to-actors/
Video: https://www.youtube.com/watch?v=lnmDFEriZ7Q
Speaker: David Khourshid (@DavidKPiano), creator of XState
Type: Conference talk · Event: RxJS Live! London · Year: 2021 · Duration: 38:31 · Views: 1573 (as of 2026-10-19)
Topics: Actor model, Reactive programming, Event-driven architecture, XState

## Summary
Can a half-century-old model of computation reduce complexity, improve performance, and make our applications exponentially more scalable and visually clear? The Actor Model can hold the key to simplifying the reactive apps we work on. Learn how RxJS observables and state machines can be used together make our apps more predictable, faster, and testable, with plenty of demos that will inspire you

## Key takeaways (quoted from the transcript)
- You know, we could represent observables as actors, and I haven't really seen too many people talk about that, so that's why I wanted to talk about that today. (5:00)
- Let's take the actors that will call them individually, you could think of these as entities, but you know, we're talking about the actor model, so I'm going to call them actors. (9:00)
- An actor can be thought of as an entity that can send or receive messages, so they react to messages, meaning that when they get a message, and only when they get a message, they can do something. (11:00)
- You can also send a reference of an actor to some other actor so that the actor you send a message to can communicate with that actor. (18:00)
- Just like an actor can only send messages to other actors via their address, and so, just like an email inbox. (22:00)

## Chapters
- 0:00 Introduction
- 4:00 First of all, they're composable, you know…
- 6:00 When you're done, or when the coffee is given to the…
- 11:00 Commonly said that everything is an actor…
- 16:00 You can also send a reference of an actor to some…
- 28:00 Observables, like I talked about…
- 30:00 Espresso, so you could consider the cafe machine invoking that espresso…
- 32:00 If I need to create another to do that will spawn…

## Transcript
[1:00] All right, thank you for having me. So we've had a really long day of talks, with a lot of code, lot of operators, a lot of reactive stuff. So this talk, I want to be mainly educational. And, first of all, I'm really excited to be back at RxJS live. I love RxJS, I've been using it for a long time. But today I want to talk to you about something a little bit different.

[1:00] And so that's why the title of my talk is putting the act in reactive, going from observables to actors. And how they might seem like different things, but they're really not so. First of all, my name is David Khourshid, I'm at Stephen K. Piano online and I'm a bit different than most of the speakers. I don't really do Angular too much, I do, React, and basically, whatever Microsoft makes me do, yeah, so that's me.

[2:00] I also played the piano, piano, it's not my last name, so that's why the piano is in there. And there's one other thing about me that might actually get me kicked off of this conference. And that's, that I don't like operators, so, I love RxJS, but the operators. There's an insane amount of operators and they're really useful. And knowing how to use all the operators to do exactly what you want is like being a professional juggler, right?

[2:00] You could see, hopefully I'm still sharing my screen, let's make sure that all right, yeah, so I don't really like operators, and the reason why is because, even though you, you have a lot of operators. And you could be an expert at just manipulating and piping all these operators together to do the thing that you want. And I've seen people do some really, really cool stuff with it. It's still opaque to any other developer that looks at your code, even if they're experienced in RxJS.

[3:00] And the reason is because we are trying with operators to describe the logic of each of our entities, like, you know, fetching to do's or something. We're trying to describe it with these weird data structures called operators that are very linear, but we have to manipulate them to it. It's sort of like a Rubik's or another Rubik's cube, but like one. Of those Rube Goldberg machines, so, but I do like observables, and so I.

[3:00] I was reading the the introduction again on Reactivex..io, which really got me started with RxJS.

[4:00] And, in the intro, it was talking about just how awesome. Observables are. First of all, they're composable, you know, you can make observables out of observables, you know, using operators or whatever else. Observables are also flexible. But one thing that caught my eye was the point that observables are less opinionated. So let's dive into that a little bit. If you look at the documentation in the intro, it says that observables are really they're.

[4:00] They're sort of agnostic to the underlying implementation, and one thing that they mention is that it doesn't matter how they're implemented. And you could even use actors such as from Ekka. More on that in a minute. But it doesn't matter how the observable works inside, it's really this, this black box you could think of, where you could subscribe, and, you know, do things with it. But how it's implemented doesn't really matter.

[5:00] And this is especially true if you are looking at ReactiveX and the RX extensions in the Java space or in any other language. That does things like support threads, and that's why I, you know, we don't really talk about threads too much in RxJS. But concurrency is a major concern, you know, in other languages and other platforms, and that's why this, this transparency is really, really powerful. And, you know, we could represent observables as actors, and I haven't really seen too many people talk about that, so that's why I wanted to talk about that today.

[5:00] But there's one limitation of observables where I think actors fit really well to fill that gap, and that's that. Observables. We could subscribe to values coming from observables, but if we want to directly send a value to an observable, that's not really a native concept in observables. So so what do we do here?

[6:00] Well, this sort of goes to show that observables don't really model real life exactly, which is why we get into that operator juggling. So I want to describe how things work, you know, in a real life example, you know, from better times when there wasn't a pandemic completely interrupting our lives, so. Suppose you go to your favorite cafe, you sit down, you get some work done, right? And we're going to use the dotted line to represent the timeline of events that could happen.

[6:00] Some of you might recognize this as a sequence diagram, and you'd be correct. So you walk up to the cashier, right? And you ask for a coffee, so, the cashier has to tell the barista, Hey, this person ordered a coffee. This is what the order is, and all of that information is sent so that you know the barista can start making it. In the meantime, the cashier tells you that it'll be, you know, three pounds, three euros, three dollars, wherever you are in the world.

[6:00] And so you get your credit card out and you pay the three euros now. The payment process itself is a series of events, from securely sending the credit card information to a payment gateway, getting confirmation that the payment went through. Maybe adding a tip, registering reward points if they're a frequent customer, and basically whatever else a payment platform can do. So, when you've made your payments, that cashier gives you a receipt and then you wait a few minutes while the barista prepares your coffee.

[7:00] And so, so when you're done, or when the coffee is given to the cashier, the cashier then gives you the coffee and everything is good. What's important to know is that each one of these events happen in real time and they happen a sync. And let's just make sure we're sharing the screen. Sorry, I think that yes, there are supposed to be slides, but they aren't showing all right. Let's debug this real quick, there we go.

[8:00] Okay, so I'm gonna, I'm gonna go through this real quick again. First of all, I don't like operators, and observables are less opinionated, which is one of their strong points. And so this was what I was talking about in the documentation that, observables can be implemented. With so many different things, such as actors. And that's what I'm going to talk about. So again, going through here, this is a sequence diagram that outlines the interaction between a customer, a cashier and a barista in getting coffee.

[8:00] So first you would get your coffee, the instructions would go. To the barista, you would get a, an invoice for, you know, it's three years or three dollars. And then you would pay it. You would get a receipt and eventually you would get your coffee. And so this is a very events driven way of thinking about, just the interaction between these three people, all right? So let's take the actors that will call them individually, you could think of these as entities, but you know, we're talking about the actor model, so I'm going to call them actors.

[9:00] So there's this idea called eventual consistency that says that in a distributed system, everything observing a value will eventually get the latest value as long as that value doesn't have any new updates. So in software, where you typically want to know the value as soon as possible, this can be a bit frustrating, but in real life, it makes sense. Like if something happened somewhere in the world, which, you know, has happened far too many times in 2020.

[9:00] Not everyone's going to know about it immediately. Some might post about it on Twitter, or it might show up on the news, but eventually, everyone who cares to know will know about it. But the key point is that it doesn't happen immediately, and it happens to communication. So, you know, let's take a little bit of a nicer example. Like, when you enter the cafe, you want a coffee, right? The barista doesn't know that, you know?

[10:00] Although they could probably guess you walked into a coffee shop. You probably want a coffee. But long story short, they cannot read your mind, but they will eventually know that you want a coffee, if they care to ask, what would you like? And then the fact that you want a copy is part of your internal private state, so again, no one can read your mind. And you could choose to share that state by saying, I would like a coffee, please.

[10:00] And you know, instead of tea, you could say I want some tea, but that doesn't change the fact that you wanted coffee first. So the statements that you say are immutable, you can't say, you know, hey, forget what I just said, give me a t. Instead, you would be sending another message saying that he wants t. So your internal states could be mutable, whatever you could change it however you want.

[11:00] But the state that you share with any other actor is immutably shared. That's a core principle of the actor model. And so, if all goes well, barista gives you your coffee and then you say thanks. And all of this is done with message passing, which we could see illustrated here. We could consider each individual in this scenario to be an actor which is communicating with each other to achieve, you know, some certain outcome.

[11:00] And this is how things work in real life, and this is also how things work in the actor model, all right, so what is an actor exactly? In short, an actor is an abstraction that describes pretty much everything you'll hear. Commonly said that everything is an actor, and just like with object-oriented programming, where everything's an object, with the actor model, everything is an actor. So an actor can be thought of as an entity that can send or receive messages, so they react to messages, meaning that when they get a message, and only when they get a message, they can do something.

[12:00] And we'll talk about what they could do pretty soon. In terms of programming, an actor can send a message to another actor that it has reference to, so sending a message is, you know, could be thought of as just a function call. And so just like you can talk with people that you know are that you are in contact with, actors can only talk to other actors that they know about. So, just like with emails or phone calls, you can include a reference to yourself.

[12:00] Like, if you send an email, you have that email that the other person could reply to. And, the recipients actor can decide to reply to you using your email address. So when an actor receives a message, it could also decide what to do with that message. In this case, when the actor is greeted, it can send back a message of some sort to the to the sending actor, so all of this is message communication.

[13:00] Now, the actor model is absolutely nothing new, in fact, the actor model is even older than. You know, I talk a lot about statecharts, it's older than statecharts, it's older than. A lot of programming models that you might be familiar with, including a functional reactive programming itself. It was first formulated, arguably, in 1973, by Carl Hewitt, Peter Bishop and Richard Steiger, in a paper titled A Universal Modular actor. Formalism for artificial intelligence, which sounds like paper that you would see today, it's also a bit of a mouthful, but yeah, it's interesting that they were talking about, you know, artificial intelligence way back then.

[13:00] So, it was influenced by the small talk language that was created by Alan key, who you may know as a computer scientist, who coined the term object-oriented programming. But what's interesting is that Allen key envisioned object-oriented programming, which is commonly viewed as that everything is an object model. With something that's more of a message passing approach, and that's what the small talk language emphasized, allen key said that the original vision of object-oriented programming was actually basically the actor model.

[14:00] So while many computer science models are mathematical models, the actor model is based on physics, like general relativity and quantum mechanics. That goes above my head, so what I'd like to do is refer to it as instead being related to real life, which it very much is. There's, there's quite a few programming languages which embrace this actor model, there's Erlang, created by Joe Armstrong. Rest in peace. It's probably one of the most well known, and it's heavily used in telecommunications and in apps you might know, like WhatsApp.

[14:00] It's used, pretty much everywhere there. And this is where the actor model shines. In a distributed concurrence computing environment, elixir is built on top of the Erling virtual machine, and you could basically think of it as Ruby for Erlang. Also, a pretty popular language, Akka is built on Scala, and Akka is probably the most popular actor model implementation. There's even an Akka..js and then Akka..net. And if you're familiar with RxJava, then Accustreams integrates with RXJava.

[15:00] So Pony is also another lesser known object-oriented actor model based language, too. So definitely recommend you looking those up. Okay? So actors, actors have a few very basic rules, and I promise it's not a lot. In fact, it's going to seem pretty natural to you. And these rules, by the way, have remained unchanged for 50 years. So. These rules are sort of what make the actor model work so well in, in distributed and concurrent systems.

[16:00] And trust me, you're not going to get JavaScript fatigue.

[16:00] Learning about these rules with any other library because they are unchanged, they are set in stone. The first rule is about locality. All computation is performed within an actor. So, like, like I said, everything is an actor, because the actor is a fundamental unit of computation. And you can model pretty much everything in programming as actors, even individual values, but that quickly becomes really unpragmatic, and since all computation is performed within an actor, it can also contain its own behavior and states, which can be thought about as the same thing.

[16:00] And we'll talk about that a little bit later. But basically, actors can be stateful and have their own local states, which is private. So then how can one actor read another actor's date? While actors can only communicate through messages and nothing else? So messages are immutable? Which provides a guarantee of no shared states between actors. Which, my hero, shared state, shared mutable state is the root of, you know, all, evil and programming.

[17:00] So if one actor wants to read, another actor states it needs to ask it via a message. Just like you can't read someone else's mind, you have to ask them what they're thinking. The receiving actor can then choose whether or not to send back a message that contains the desired states or not. And so you could think about actors. Sort of the same way as communicating between, like, a client, and the server and HTTP, it's pretty much the same idea.

[17:00] So actors are also reactive, which means that they react to incoming messages, and there are three things an actor can do when it receives a message. First of all, it can change its states and or its behavior. So remember that a LE enactor can have local, isolated states, and that includes data and logic. That determines what the extra actor should do in response to a message that's on my screen. So, for example, you could send an increment message to an actor, and it could change its internal states to its current counts.

[18:00] Plus one, it can also determine that the counter has reached its max, and it could. Change its behavior so that it does nothing if another increment message comes in. So an actor can also send messages to other actors that it cares about, or knows about. And this makes sense in real life, too, you can only talk to people that you have direct contact with. So, just like you could send someone's Twitter handle or email address to someone.

[18:00] You can also send a reference of an actor to some other actor so that the actor you send a message to can communicate with that actor. And probably one of the most interesting things to me about the actor model is that actors can create or spawn a finite number of other child actors. And so these child actors are pretty much just like every other actor. They follow the same rules and they have their own isolated states in behavior.

[19:00] So, remember, an actor can only know of some external state if it receives it via a message or if it's born with it. Because initiating an actor is sort of like a message itself, so that is the parent itself can, can create a child actor that already has some relevant data from its inception. Just like real life, it's like DNA or genetics, or however you want to think about that. So, even though actors all follow the same rules, they can behave a little bit differently in reaction to a message that they receive.

[19:00] And this is called an actor's behavior it's what determines what immediately happens next due to a message. A finite steam machine, of course, is a great way of describing the behavior of an actor. Since it's an event driven approach to modeling logic, and by the way, I use message and events interchangeably, so you could consider them, basically the same thing for now. So with the state machine, the finite state represents the qualitative states, and in different finite states, events can do different things or transition to another finite state.

[20:00] And C machines can also have extended state, which represents the quantitative data associated with the machine. Both of these combine make up an actor's overall state, which is why an actor's behavior can be expressed in its dates. And if you're not using a state machine, please watch my previous talk from RxJS live I talk. A lot about state machines, and so there's just a lot of really good reasons why you should be using state machines.

[20:00] And yes, you could use them in RXJS2. So, whereas an actor represents its internal logic, an actor system represents the connections between all of the other actors. An actor system has a single root actor, which is known as a guardian actor. And in ACCA, this is how they know it, as there's also root actor. It's known as, but it's basically the main actor, so every single actor from the root actor has exactly one parent.

[21:00] So an actor system forms a hierarchy or a tree structure. And remember that a any actor can spawn child actors, and those child actors can themselves spawn child actors. And on and on, and so that's how it can form this spanning tree. And each actor has a unique address that identifies it for simplicity in some actor model implementations. This address represents the hierarchical path to the actor, such as cafe manager one, slash employee one.

[21:00] You could tell directly, where, where that actor lives now. Addresses can't be used to access the actor instance directly. So, just like if you have my email address, you can't access my email, or at least I really, really hope not, you can only send me a message using my email address. Just like an actor can only send messages to other actors via their address, and so, just like an email inbox. Those messages arrive in the actor's mailbox, and that's how an actor can process one message at a time.

[22:00] Now, in terms of relation to RxJS, mailboxes are actually really interesting because they guarantee that only one message is sent at a time, just like RxJS schedulers. So here's why when an actor receives a message, it needs to process that message to determine what happens next. How the state will change, what the next behavior is, if it needs to spawn new actors or send messages to other actors, etc. And so when it's done processing that message, it can process another message and return the next state.

[23:00] So what happens if an actor is processing a message and then it receives another message while it's probably processing the previous one? So this can lead to race conditions or impossible states, or worse. It could actually. Make the actor crash. And so that's why. By using a mailbox, we can hold all the messages in a queue. And that way, the actor can dequeue each of those messages one by one and process the state one at a time.

[23:00] So that way, if another message comes in, it's sends to the mailbox before it's sent to the actor, and the actor can process each message, on its own. And so that's why mailboxes are also very useful for back pressure, and if you want to learn more about back pressure. I think J. Phelps gave a talk at that at the previous RxJS live, which is really good, so definitely recommend that. And mailboxes are typically a first in, first out cue, but that's not a strict requirement.

[24:00] It could be a priority queue, for instance, mailboxes. And actors, pretty much, tend to have at least once delivery guarantee, and not necessarily in order guarantee. So you will get your message. It just might not be in the order that you know or the time that you expect, so just consider everything to be async. And you could also consider a mailbox to be an actor itself. Now, remember, an actor instance can't be accessed directly, we can only communicate with an actor using an address or, in other words, some sort of reference to the actor.

[24:00] And so this is what gives actors what's called location transparency, and it allows the actor to act as a black box of sorts. Because we don't need to care where the actor is, we just need to access, you know, something that references that actor and that actor?Eth will take care of forwarding the message to the actual location of the actor. And if you think about it, this means that we could also swap out the after implementation while our program is running, and it's still going to work exactly the same.

[25:00] And so that's why this location transparency also enables another powerful feature, which is false tolerance. So if this actor fails for whatever reason, whether it's a shaky network or some other fatal error. Sure, you could juggle operators around and have like a retry operator or something like that. But you could also have, in some actor models, a strategy for reviving that actor, or. Even letting it fail gracefully, um. One such strategy is to just restart the actor if it fails, or replace the behavior with some sort of fallback behavior.

[25:00] All of this without changing the actor f at all. So it's going to be as if nothing happened. So, if you squint, hopefully you'll see various parts of your code, especially the ones where you're passing messages back and forth. In RxJS, you could really see how, how everything is an actor in a way. I was recently working with the post message API on something I'm going to show you pretty soon, and I realized that.

[26:00] The way that windows communicate with each other, whether it's an iframe, a pop-up window, or a Dev tools panel, is with message passing. And I mean, it's even in the name you have post message right there. So we could spawn a window by calling window.open, and, you know, that could be considered. Another actor, and then the parent window actor can send a message to the spawn child window. By calling post message on, you know, message.source.postmessage.

[26:00] And so that reference can be, or, sorry, the window can send popup.postmessage and that, pop-up window can send a message back to the parents. So you could consider these to be basically two actors communicating with each other, which is pretty cool. And then the window can decide what to do when it receives that message. So in RxJS, how we would implement an actor is, well, you, you would have a source of some sort, whether it's from a subject or other observables.

[27:00] And typically, what I would do is I would merge these together and then you could pipe them through a scan operator. So, as far as me, hitting operators, uh. This is also something I briefly talked about at the last RxJS live. But you can, you could consider Scan pretty much a the most powerful operator in my opinion. Because it takes a reducer in an initial state, and it returns the next state.

[27:00] And so this alone is a really powerful method that can encompass so many different use cases. And it's really what the actor model is based on, in a way that reducer, signifies the actors behavior in RxJS.

[28:00] So let's talk about the. Differences real quick before we get into code. An actor can send any events in any event, and it could receive any events. Promises, can send either a resolved or a rejected value, so they could only send one event. And like, Copay talked about, promises, really, you know, they can't send multiple events. So they're automatically less powerful than observables, but promises can also receive. If you squint, they could sort of receive a message called in the board controller signal that allows the promise to be aborted.

[28:00] Now, observables, like I talked about, they can only send messages unless you use RxJS subjects. And sort of, you know, juggle around a few operators, and if you squint, then it could sort of look like an actor. But otherwise, observables, for most use cases, are just they. They only send messages to whoever is subscribed to them. Now I made XState, which, is a library that's primarily for state machines and statecharts. And so, just going to go over this quickly you.

[29:00] You could look up more at x8.js..org or check out the repo. But basically, X8 allows you to take a machine which is just a fancy reducer, interpret it into a service and you could send messages to it. And the cool thing is that this is perfectly integrated with RxJS. Just using from, I mean, this looks a bit funny. Import from but I mean, that's, that's the best name that you could come up with, so it works.

[29:00] I mean, so, you have con states from service and you could subscribe to those state changes, but you could also send messages to those services as well. And, unlike a subject, it's not going to be.

[30:00] Whenever you send the message, it subscribes and relays that message. But instead, it's going to decide what to do, and then it's going to change its state based on that message. So everything is an actor. That notion is true for XData as well. XD can invoke and spawn child actors, which is considered sort of an advanced part of the library. Invoking an actor is done in the invoke property, where you give it an ID, you give it its behavior, and so basically this is saying, invoke a child actor with espresso machine behavior, so that.

[30:00] We can make coffee, and when we're done with that, then we transition to the delivering coffee state. And so that would be sending a message like, Don Dunbo. Espresso, so you could consider the cafe machine invoking that espresso machine, so spawning it as an actor. And that espresso machine. Can then communicate back with the parents, all via message passing. So, a machine can also send messages to that actor directly. And so this is one of the, you know, differences between just plain observables and also machines, or actors.

[31:00] Rather, is that you have a cafe machine, and let's say that the espresso machine is currently making a coffee. But the customer says, I want to change my order. Then we could send a change order event to the espresso machine, and the espresso machine can decide what to do. So. Also, an espresso machine doesn't always have to send, you know, the same value back every time, uh. It could also send a, for example, a machine broken event, and then the cafe machine.

[31:00] Due to its behavior, it could determine what should I do if the machine is broken? And then they could do those, compensatory steps there.

[32:00] So, yeah, sometimes we need to spawn actors dynamically, and so that's why in XState's V4 we have the spawn function again, this is a little bit advanced X8. So I'm breezing through this. But long story short, we could spawn multiple actors and put them inside the internal state of this machine, and then we could send events to those individual actors. So in RxJS, you could imagine this the same as, as creating many observables, and you could subscribe to all of those observables.

[32:00] But the difference here is that you could also send messages, to each of these entities. So in X85, we're going to be taking this. Everything is an actor thing to the next level. By simplifying how it creates actors, and also a lot of TypeScript integration, with just having a lot safer types for actors. In version 4, it treated promises, observables, callbacks and other machines special by internally adapting them to the actors.

[33:00] And this made general use cases easy, but other use cases harder. So in version 5, this is going to be explicit, you could see. This invoke observable function, which takes a function that returns an observable and turns that into an actor. And so these helper functions are going to make it easy to invoke actors or spawn them. Just the same. And so, what I've been working on, too, is a is a new library based on, course, very old ideas.

[33:00] Called X actor, which it's not separate from XState, it's basically XState, the actor model parts. And just to give you a brief overview of how this is going to look. If you, if you're used to using the scan operator, you're going to find yourself right at home with this library. So you create a behavior such as this counter, and it's basically a reducer, same as you would have in scan, and you give it an initial state as well.

[34:00] Then you create a system with that behavior. Remember, the behavior defines the behavior of an actor, and then you could send that system whatever you want. And so, you could also spawn actors by providing, the behavior into context.spawn, and so you could dynamically create actors inside of here too. So it's, it, it's not going to be like, scan in that. Everything is in this giant state object, just like, you know, Redux or NGRX, but rather, everything is distributed.

[34:00] States and these little entities of state are actors that you could communicate with, and I'll show you an example of that pretty soon. And, of course, with integration with RxJS again, the systems and the actors that you create using both X-Acto and XState are both subscribable. They, they conform to the observable interface, and they also have symbol observable and all of the other acrobatics needed to make. RxJS recognize them, so you could just pass them into from RxJS, and you have an observable that you could use anywhere in your application.

[35:00] So I, I'm still working on this library, but you could go to GitHub..com. David K. Piano XState or, sorry, Slash X actor and, you know, give it a star. And I'll be pushing some updates there soon. But I wanted to show you one more thing. So just to illustrate the actor model in a sense, we have this, you know, this to. Do MVC machine and this is using XState. So one of the reasons that I find the actor models so important is because we need to understand how different parts of our applications communicate with each other.

[36:00] So if we consider this to do's application as an actor and each to do as an individual actor, then it's really useful to, to visualize the communication between them. So let's say I created to do what happens. Is this new to do actor? You could see here? It has its own internal states, and, you could send messages directly to it, and the parents and child actors can communicate with each other. So if we go to this, we could see that, you know, it does have its own state, and we could even let's complete that.

[36:00] And so this is just a state machine representing, that state. And when I complete that, it actually sends a message back to the parent. So if I need to create another to do that will spawn a new actor like you see here. And so if we modify this, it's sending events to itself, but then, of course, it needs to communicate back to the parents. And so, this tool is from statecharts..io, it's called XDateInspect, and so anywhere you're using XState and pretty soon X actor.

[37:00] If you don't want the full state machine and statechart implementation. You'll be able to visualize that too in this live sequence diagram that I have over here. But yeah, that's, you know, visualization is so important to me and I. I first fell in love with marble diagrams, and, from that, I wanted everything to be visualized, which is why I created this. So, with that said, thank you so much RxJS sly for having me.

[37:00] And I hope that you take your newfound knowledge of the actor model, in all of your applications, and um.