# Getting Started with XState in Angular & SolidJS Canonical: https://davidk.dev/talks/getting-started-with-xstate-in-angular-solidjs/ Video: https://www.youtube.com/watch?v=1N0VUT_0n54 Speaker: David Khourshid (@DavidKPiano), creator of XState Type: Livestream · Event: Build IT Better S01E06 (This Dot Media) · Year: 2023 · Duration: 30:47 · Views: 597 (as of 2026-10-19) Topics: XState, Visual modeling ## Summary Build IT Better is back with Tracy Lee and Ben Lesh, featuring David Khourshid from XState and Stately! David will be sharing the challenges in implementing XState in Angular, and SolidJS and will walk us through what XState is, and how to use it in different libraries. He'll also discuss the nuances and trade-offs in choosing technologies for building the diagraming tool for a state machine edito ## Key takeaways (quoted from the transcript) - A while ago, I created this library called XState, which makes it easy to visualize application logic written as state machines. (1:00) - Where you actually have to manipulate things via drag and drop, you have to visualize things, you have a canvas to work on, the complexity goes way up, and, there's definitely no one-size-fits all. (8:00) - SVG is really flexible, but of course it's a learning curve, and even back then I wasn't in SVG expert. (16:00) - Of foreign object with HTML inside, he inverted that, so there was an HTML elements, with everything absolutely positioned as HTML elements inside, and then inside those HTML elements were separate SVG elements. (20:00) - I think it's always just been a great way for, I like, recommended XState when I talk about building an inclusive development teams, because it kind of takes the pressure off of, you know, an architect or somebody. (29:00) ## Chapters - 0:00 Introduction - 4:00 About 70 of what we do is weird problems… - 10:00 Just because Angular treats like the units in Angular is the… - 16:00 If you were to just use SVG or HTML… - 24:00 We couldn't use anything like Reacts flow because our requirements were… - 26:00 I think I think the elevator has a broken state machine… ## Transcript [0:00] Hey everybody and welcome to this episode of build it better. My name is Tracy. You can follow me on Twitter at Ladyleet. I'm one of your co-hosts today, and I am joined by Ben Lash. I'm at Ben Lash on Twitter. Yes, and today we have, David Khourshid. Some people call him David K. Piano, because, and Stately welcome David. Hey, thanks for having me. Yes, we are so, so, so excited to have you and to dig into fun things. [0:00] So maybe tell us a little bit about yourself and like, tell us a little bit about just X, date and Stately, and then we can dive into the hard questions. Sure, so I've been the developer for I lost count over 12 years now. And before, or currently. Like I. I was a musician, so I studied piano at the University of Central Florida, and so that's why shows here David K. Piano. That's a stuck, and I just kept it, uh. [1:00] But a while ago, I created this library called XState, which makes it easy to visualize application logic written as state machines. Just because I'm really passionate about the entire team, understanding what the heck is going on in your application, instead of that being stuck in the developer's head? And uh? So about a year and a half ago, I formed a company that is called Stately, and now we do this as a business, just making application logic accessible to entire teams. [1:00] So exciting, very cool. So the distinction, the distinction between Stately and XState is that like XState the library, and Stately is the company kind of around the ideas that the library represents, right? Exactly. So Staley is like the tools and services for, you. Creating executable diagrams, of course, XState of first class citizen, where you could create steam machines and statecharts. With Steely. But, we're looking broader. So allowing people to create all sorts of diagrams which aren't just pretty pictures, there are actually diagrams that reflect the actual logic in your applications. [2:00] All right, but they can be pretty pictures though, right? Oh, of course, yeah, yeah, prettiness is definitely a core, mission of ours. That's good. Otherwise I would not be down, Tracy. Would you be down if they? Were not pretty. They have no. But I'm down for anything David does. But I'm I'm just generally excited because I feel like this is, just really. Kind of one of the trends you're seeing these days, right? [2:00] Like the tools and kind of the startups that we're seeing get funded, right and just kind of. Like this new way to do development, like just all these, all these things to just help make the developer experience better. I was really going to change how we do development in the next five to seven years, I would say, and it's gonna change how I feel like development teams are managed. You know, the visibility that we get into, like what's actually happening, so things aren't as like nebulous in a sense, right? [3:00] And hopefully making, just like your mission, right? Like making things just more accessible for people who, you know, maybe aren't, like, you know, the rock stars or the whatever. Like to know what our Earth is going on, right? Yeah, I need things to be accessible for me, to be honest, to know what's going on there. There's that, all right. So one question I have about this because it's like, when you have diagrams to do all your state management stuff and like, that kind of configures your state management. [4:00] You're almost like writing code with no code, right? [4:00] Like, so like, almost not, really, you still have to. You know, there's there's boxes to fill in there. Like you can't just be like, Oh yeah, this is going to do my data fetching and stuff for me too, right? Uh? But like, I'm wondering is, has there been, have you seen any adoption with this? Towards? Like the no code like front end stuff? Or someone's like, I would like to do as much of this visually as possible. [4:00] And then maybe I just fill out the data access bits or whatever. Is that. Is that a thing that you've seen with your stack at all? So that's exactly the use case, whether it's a developer or a project manager who's creating these flows, or machines, as we call them. They're basically taking that and delivering it to the development team, not handoff. It's more of a collaborative thing, but they're delivering it, um. [4:00] As as code, and so basically, they're saying, here's the general, higher level, human readable view of what the logic of the app should be. Please fill in the details. And so this I, I. I think there's a distinction between no code and code. Where no code, in my view, is actually more like no control. Because a lot of people are scared of no code in that. Yeah, you could track these boxes around. [5:00] It's really simple, but it's as soon as your use case gets complex enough, where no code can't really satisfy it. Then you have to jump into code. Or you have to do some sort of crazy work around, just to get past that, that restriction from no code, so that's why this is more like visually augmented code, where you're using these visual diagrams as a way to abstract the different parts of your code. [5:00] Which, you know, could be whatever you want, and, in the future, just whatever language you want. And you're using that as the foundation for just putting all of your application logic in neat boxes, that's pretty cool, all right. Well, the when you're building this, there's a lot, there's a lot involved with this, like I have done things where I had to build, like visual layout, things like with the web. Like, that's a huge, it's a huge pain. [6:00] But anytime you get outside of the bounds of like, I'm building a forum, I'm displaying text, like I'm just playing a table, like on the web. It's automatically a pain in the ass to deal with whatever, with whatever you're doing. So, and then, of course, there's a whole like, developing a state machine, building stuff in open source. You know, there's the company side of things. But I'm wondering if during the development, during your development time on this, did you ever run into, like, a weird, gnarly problem? [6:00] Because the reason I ask is one of the things that I like to talk about with people. When we go to conferences and you get to, you get to sit around with a bunch of other open source authors. Is like, they'll bring up some weird thing that happened. And it's not the usual, like, here's my library and here's how it works, it's like most. Of the people at the table probably know those things. [7:00] And instead, it's like, there's this weird Quirk that we had to work around. That happens with this edge case that we hit because we have millions of people using this, and here's what it is like. Is there any, like, really strange problems that you had to solve during the development of all of this stack of stuff? That come to mind when you? I would say one of the most exciting things about working at Stately is. [7:00] About 70 of what we do is weird problems, like there are far more weird problems than there are normal problems. It's not like we're creating a SAS where, okay, you create a back end, you create the front end, and that back end. Nowadays, it's just a, a wrapper. For open API, you know, to send stuff out to ChatGPT, and then boom, there's your data. Please pay us ten dollars a month for, this generated AI versus like, no, that like, we are doing something much, much more complex. [7:00] And you were talking about forms. Of course, forms on the web are tricky, and I would argue that most, most applications are basically just glorified multi-step forms. Really, you know, you have buttons, you have fields, you have data that you display, and you could click and go to a different screen and all of that. But as soon as you move away from that and you get into the type of app where now you have, more visual aspects. [8:00] So you're going from, I guess, a 1D thing to a 2D thing, or even a 3D thing. Where you actually have to manipulate things via drag and drop, you have to visualize things, you have a canvas to work on, the complexity goes way up, and, there's definitely no one-size-fits all. It's not like, oh, you have a React app, we could just bolt something on top of Next.js, or you have a View app, we could put something on top of next. [8:00] Like, there's nothing like that. There's many libraries that you could work from, but we've. We've run into so many interesting and unique use cases that, we've, yeah, we've iterated on many different solutions. And that, yeah, so that's just all. To say that there's a ton of weird problems that we've run into, it's like a really good thing to put on your recruiting page. Oh, yeah, and they are, in fact, I, I like to joke that, so I. [9:00] I worked at Microsoft for four and a half years and I remember just pulling so many all-nighters, studying algorithms like leads, code and all of that. To, you know, to interview for the company and eventually get in. Just because I didn't have a computer science background, so I had to really upskill on that. And the number of times I've actually used that stuff at Microsoft, zero. But the number of times that we've actually had to use like, really algorithmic stuff like graph, traversal, optimization problems. [9:00] Like, there's so many instances of that when working at Stately. Like, we actually have to use the algorithms that developers say, like, Oh, there's no use case for these. [10:00] All right, right, yeah, yeah. If you get far enough off the reservation, every now and then, you'll find yourself writing a binary search or something like, wait, I didn't think I actually had to do this ever, but here I am. Right, no, that's that's cool, when it when it comes to, you know, bolting XState or whatever on top of a A framework is, are there any? Is there any one framework that's particularly difficult and one that's like, easier to deal with when it comes to XState? [10:00] Like, given that they're all a little different, or, yeah, so all Frameworks are a little different. We do have official wrappers for most, or I don't want to say most of them, because there's so many. But a lot of them like, React and View, and uh. So the way that, like, XState is consumed, you're basically subscribing to it, and, you know, coming from the RxJS world, it's a pretty familiar concept. You're subscribing to something. [11:00] And you could also send it events, so it's sort of like a bi-directional thing, it's this object where it could send and receive events, and that's pretty much it. It's basically like Redux, but in a more flexible way. I guess you could think of it, and so with a lot of Frameworks that you know integrate with. Things like Redux, E.t.c. It. It's actually pretty easy to just, bolt on XState, so, that's why I view and reacts were pretty straightforward. [11:00] Recently, we've released XState solid, and so that was a little bit of a challenge, just because solid expects to, you know, to observe the entire object that's using proxy magic to do that. And since we had our own like state objects that weren't really built for that, it became a little bit challenging to do, that. And I guess another challenge, just because of unfamiliarity, is Angular. But here's the funny thing we don't have an official wrapper for Angular. [11:00] No one on the team knows ingular really that well, but that hasn't stopped people from using X8 with Angular. And actually, when one of our team members, Matish, tried out Angular and basically just learned it to, see, like, how hard would it be to add X data in inside of Angular? It took all of 10 minutes. Because the, the thing that you get from interpreting a state machine is observable already, so you could just pass that around, uh. [12:00] Use Chrome with RxJS and subscribe to it and then send it events, and it's super easy. Yay, RxJS. Yeah, saves the day. No, yeah. So I was just wondering, because, you know, like an RX, like observables, just work was felt like that's a that's a thing. Or they, you know, someone said that they just work with solid, but I haven't tried that, or even I haven't even tried solid. I'm sorry to tell folks out there, but yeah, there's there. [12:00] But then, you know, ironically, I work in React all the time, which is like the least, ergonomic way to use RXGI. So that's that's why I was curious if there was if there was one. Or like, a framework that worked especially well with X8 and one that was like, a little. You required a little bit more, manual finagling to get it wired up. But it sounds like, if you already have wrappers for it, then yeah, yeah, and I mean, even just without rappers, uh. [13:00] Philosophically, Angular would be the easiest way to work with that state, even though I don't have much Angular experience. It's. Just because Angular treats like the units in Angular is the observable. And so an inter, an actor that we call. It's basically that you could subscribe to it, you could send it, events, everything is contained inside that, that's awesome, that's awesome. Do you have your own observable implementation under the head? Sort of extremely light. [13:00] So we're basically, you know, just listening for observers, so you have a complete next error, you know, that object, and then we have it on an observer's set. I guess we could do more optimizations like ref counting and things like that to make sure that we, you know, we garbage collect properly and all that sort of stuff. But yeah, it's a very, very light implementation that's compatible with RxJS. Okay, that's awesome, that's awesome. [14:00] Yeah, I'm always curious about that, like, there's a. The one of the talks I give recently isn't really about RX, it's just about how everyone's using observables. And a lot of libraries don't even realize they're using it. Like you, exactly. Yeah, you don't know that you're using one. So, cool. So what did you like, feel like you just, like, is there anything you just really pounded your head over? Or like weird things, you kind of had to, like debug, or like weird workarounds you've had to do. [14:00] Maybe even talking about, like all these different use cases, right? Like, I'm just so curious, how does it? It's like, you know, especially when you're building a product, right? Like, you know, what are all the weird edge cases that you've been like? Okay, and then, you know, are there some interesting ones that you can share, how, like, how you solve them? Yeah, so I'll talk about one, which is really a collection of a lot of them. [15:00] Just because I've wasted months, if not years, of my life, just, figuring this kind of thing out. And it's the diagramming portion of that, of basically the editor, and in a way the visualizer, too, uh. So when I started prototyping, like, what would a diagramming tool for state machines and statecharts, where you could actually edit it, like, what would that look like? I started that about like two or three years ago, you know, I was still. [15:00] Working at Microsoft, so this was early mornings, late nights, weekends, all that stuff, just playing around with it. And I've had so many different prototypes of how this would work. And so when you're building a diagramming tool, there's many different directions you could go. [16:00] There's canvas, you could use a straight up canvas, which is going to be your most performant option, but you really lose out on benefits of accessibility and styling, like those are the two big things that you really don't get out of the box with canvas. You can't style canvas elements with CSS, you can't add accessibility attributes to any of the elements unless you do a lot of extra work. And even then, there's no way you're going to be 100 compatible with. [16:00] If you were to just use SVG or HTML, there's also SVG now. SVG is really flexible, but of course it's a learning curve, and even back then I wasn't in SVG expert. So you're really learning things, you know, one at a time. And, that there's. There's a lot of, difficulty with that, too, in terms of, faking your own way of doing zooming and panning, and um. Also, performance is always a concern as well. [17:00] So for the longest time, I actually chose SVG because again, I wanted the ability to style, I want the ability to I have accessibility attributes. And also there's this cool little elements that I literally realized would cause us a lot of trouble. Called foreign objects, so for an object, works pretty well. Because we also wanted the states and the events and just every element inside of the diagram to be interactive, because, after all, this is an executable diagram. [17:00] We didn't just want to be a plain SVG thing, we wanted people to add buttons, add descriptions, change text, formatting. All without us having to, you know, calculate every little thing and do extra work for that. So we were just like, Okay, let's stick it in for an object, so we use that, and we used a resize observer, which we're so glad it exists. Because, when you have things in HTML elements, SVG doesn't know the size of them. [18:00] HTML it automatically calculates the size. So you can't just put a text or whatever in SVG and expect it to. Do the wrapping correctly and expect the, the rectangle to size appropriately to it. SVG doesn't have that concept. So that's why we opted for using foreign object and putting HTML inside of there. And adding a resize observer in order to make sure that we have the sizes correctly so we could tell SVG this is the size of the foreign objects. [18:00] Can you please draw a rectangle around that? So, we did that for a while, and it actually worked pretty well until there were more and more people asking for Safari supports. And since I primarily develop in Chrome and sometimes Firefox, I rarely open Safari. So when I opened it, I just realized it does not work at all. And so, I was like, Okay, foreign object is working, is acting a little bit weird, things are not sized correctly, things are like, straight up hidden. [19:00] So I search Stack Overflow because there's always an answer on Stack Overflow, you know, for these kinds of things, especially Safari support. And the consensus. And basically every answer was, hey, this is a 12 year old bug or something like that, and there is no solution like it. It just straight up said, you're, you're not going to be able to fix this problem. So we had to go back to the drawing board. [19:00] And at the same time, my friend, and you probably know him, Steven Ruiz, or Steve Ruiz. Sorry, he, uh. He created this library called TL draw, which is really, really awesome. It's a it's basically like excalator, but you know, with a few more features, nicer UI, E.t.c. I, I really enjoy using TL draw, and it's basically the same thing, it's almost the same thing. It's a diagramming tool, for making these types of diagrams. [19:00] Where you could embed things onto it so you could, like, copy paste, Google Maps, or even entire web pages onto it, like, just different kinds of embeds. And so, of course, you needed that mixing of HTML and SVG, too, but I opened his up in Safari and I saw, hey, it actually works, and it works really smoothly. So I realized that he was actually using a different technique, where instead of having a giant SVGL elements and putting little sprinklings. [20:00] Of foreign object with HTML inside, he inverted that, so there was an HTML elements, with everything absolutely positioned as HTML elements inside, and then inside those HTML elements were separate SVG elements. So that inversion actually, it seemed a little bit weird, because here's me thinking in the future, I really want to export this as SVG make that really easy to do. But the more I thought about it, the more I realized it made a lot of sense. [20:00] But it did require a lot more math, and I don't know how long we have, so I'm gonna just skip over the math parts. But we ended up doing the same thing where we inverted that, so we basically have an HTML canvas with SVG sprinkled all over it, and it works in Safari, and it's actually the performance improved, too. So, yeah, that was one of the big challenges that advanced many, many years. [21:00] I mean, that's kind of amazing to just like, see, it's great that, you know, there's just like so much happening in open source. And like, you can share from each other and learn best practices. And be like, Oh my God, I didn't think about that. Oh, this is better, right? Yeah, yeah, the whole I'm not a stranger to having to work with SVG in that, it's. It's one of those I had. [21:00] I had the same thing one time too, where it was like, Oh, look, I've got a foreign object and the thing inside change sizes, and it's got this Viewport thing. Look, what the hell like? And it's one of those things where, like you explain it, you explain some of this stuff. Like, there's things like this that happened to, like, back-end developers. And they're just like, I can't believe that. You have to deal with that and it's like, Oh, not only do I have to deal with that, it's it's. [22:00] There's a 12 year old bug. And this was like, this is actually better than it used to be, like 20 years ago to get a race. [Laughter] yeah, yeah, it's a. It's bizarre like that, as soon as you like, I said. As soon as you leave the realm of like, regular, here's the forum and here's display, some text and whatever. Like, even that gets difficult, but like. Yeah, yeah, you get into like the SVG and canvas OR, like even avant-garde DOM rendering, and it's it's, can be a nightmare. [22:00] Yeah, it's like a whole different world. It's like, if you thought that CSS was hard, you know, try doing things in SVG. It's like, you're, you're graduating from. How do I Center this box to how can I zoom in and out of this box and make this box appear next to another box? In arbitrary positions? And a an even harder problem, how do you connect a line between those two boxes automatically so that the line actually looks nice and doesn't overlap? [23:00] Things that it shouldn't be overlapping? That's a really difficult problem on its own, too. Yeah, so sad. It's just like you're talking about connecting a line like a, like a line in between two boxes. You know, what would you think would be simple, but it's definitely not. Yeah, you think they'd just be like, Oh yeah, there's this. There's already an SVG for that, right? Like you, just right, I mean, like, you think that someone would have solved a problem in a componentized way that you could just be like, yeah, here's the beginning, here's the end, you've figured out. [23:00] Computer. But nope, although, you know, we're ChatGPT away from like, being able to give me GPC is like the new, like, you know, give me a cleanup. [24:00] X, you know, right, yeah, do you feel like, you know, with just kind of the you know the stuff you're seeing and you know the family? It sounds like it's just harder than it should be in a sense, right? So, like, where the standards, what's happening? Are there things going on? Are you advocating for any better standards to happen? To make your life not so crazy in this world? Yeah, I mean, to be fair. [24:00] Our use cases, such a niche use case that, I, I don't think that it would be worth the time. Like this is one of those things where it's like, the number of interested parties in solutions like this are like you could count them on one hand, right? And even so, there's, there's some advanced software like, Wi files, from Y works. I believe, they. I, I mean, they're, they're. Closed source, but they, they do a really good job at layouts and, graph rendering and stuff like that, and there's also Elk JS, which is open source. [25:00] But it's compiled from or transpiled from Java, so we use that to do automatic layout and stuff like that too. But if there's an error, which there tends to be, the error is completely unreadable because it comes from Java. So yeah, it's impossible to debug, but yeah, so there are lots of libraries around this, there's GOJS, JS, Plum, E.T.C. In fact, in the Reacts land, a popular library and one that I appreciate a lot is React flow. [25:00] And you're, you're seeing more and more applications built off of React flow. We couldn't use anything like Reacts flow because our requirements were a lot bigger than what Reacts flow provides. We needed nesting, we needed certain rules for how different things in the diagram displayed. [26:00] So all that to say that, you know, there's many different solutions for this kind of thing, whether you're trying to do things in the SVG or the DOM. And I think that there's no one-size-fits all, nor should there be a one-size-fits all. Different trade-offs for different use cases. Cool, thank you so much for joining. We always end this off. Would you rather question? So, well, here's the thing. I asked Chad PVC to create this. [26:00] That's Ben's request of me doing it. Because a lot, I mean, because she said, stuff like, would you rather eat a piece of cheese or ride a horse to the moon? Like, it'll be like, it'll be like some weird thing. Yeah, this one's weird, too. Okay, so here's the here. So I said, create a conflict and funny. Would you rather question about XState and state machines? Oh, okay, okay, you ready? Yeah, okay. [27:00] Would you rather spend a day stranded on a deserted island with only a state machine built with XState for company? Or be stuck in an elevator with a broken state machine that can only transition between working and not working. Oh gosh, does the broken seat machine control the elevator? I mean, that's a question. [Music] so would you rather do? Yeah, so I think I think the elevator has a broken state machine as well. [27:00] Okay, yeah, yeah. Interesting, honestly, I'd probably choose the, deserted island, because [Music], um. With a sufficiently advanced and sufficiently large state machine, you basically have AI and not in the like ChatGPT, we're going to pair it out of response. That seems really plausible. AI, but more like the type of AI that could actually understand and do things. And, like, just reasonabouts, like, you know, like that's symbolic AI, where it actually knows what it's talking about. [28:00] So, yeah, this is pretty good because it did specify it was built with XState, so we're going to build artificial intelligence with XState. Can you imagine the node dependencies you'd have with that, like your node modules would be like, whoa? Like, just give us your entire disk space and we're good to go. What would you rather? I don't know, let me think about this, I mean, I don't know. The elevator. The elevator might be fun. [28:00] Of course, you could end up dying in on the elevator, of course, you could end up dying on the island too. So I think just for the sake of difference, I would pick the elevator. Probably. Yeah, it's, you know, I mean, especially if it's like working, and then it's not. And they're like, Oh, you have these moments of excitement, like, I'm gonna finally get, Oh no, it stopped again. Well, if you're in the elevator, I'll spend a day with you. [29:00] Ben. So sorry, David. The only reason I didn't pack the Deserted island is because it sounds hot and I'm used to it. I don't like heat. [Laughter]. So check out Stately..ai as well, XState on GitHub if you're not using it. Oh my gosh, you said. It doesn't matter if your junior or mid-level senior architect, prod, program manager, project manager. It's just a great way to, like, help understand what's going on under the hood. [29:00] And I think it's always just been a great way for, I like, recommended XState when I talk about building an inclusive development teams, because it kind of takes the pressure off of, you know, an architect or somebody. Like, only knowing what to do, or only knowing the path, you know, you can kind of, like, map out the path for the rest of the team. Without. Do you use it? Ben do you use that work to make it? [30:00] Yeah, all right, we haven't. We haven't hit that use case yet. It does sound like I, I. It's always in the back of my head, like if, if we've got a situation where I'm like, this is a lot. But a lot of what I do is data visualization, so it's just like you get the data and then you display the data like, there's. There's usually not a lot involved in there, as far as like needing to manage the state of anything, but well, that makes sense. [30:00] Thanks again everyone for listening and tuning in, and we'll see you next time. See you [Music].