XState in the Wild

Baptiste: [00:00:00] Hey there! Welcome in this new episode of XState in the wild. Today, we are going to talk about Zack. js with its creator, Sagan Adebayo. Zack. js is a JavaScript library to create your own accessible components. It comes with many primitives and is powered by state machines. It uses a syntax similar to the syntax of XState to define its state machines.

It's framework agnostic, and you can use it with React, Solid, or Vue. js. If one day you want to create a number impute, I invite you to use Zuck. js. You can import the number impute package from Zuck. js. It gives you this machine function, the number imputes dot machine function returns a state machine.

And you can create an instance from the state machine with the use machine hook. The hook [00:01:00] comes from Zach GS react in my case, but if you use solid, it would come from Zach GS solid. Or if you use Vue. js, it will come from Zach GS Vue. js. So you can see that Zach GS is framework agnostic. The state machine will remain the same, but the hook to wire the state machine to your framework will be dependent on the framework you use.

Then, the useMachine hook returns a state and a send function, but you don't use these properties by yourself. You use the numberImpute. connect function. This function takes the state And the send function and returns an API. The API gives you, for instance, these get root props, get label props, get decrement trigger props, et cetera.

So the API gives you simpler function to work with [00:02:00] than the state machine itself. ZackJS doesn't come with any style. But it gives you primitives to create good and accessible components. For instance, the impute we talked about, you can press the arrow up key or the arrow down key to increment or decrement the impute.

I didn't cut that, it's implemented inside of the state machine of ZackJS. You can click on the buttons. So all the behavior is handled by ZackJS, and it's up to you to create your components for your design system. And style them however you want. Now let's talk with Sagan about this excellent library.

Maybe you can present you a bit.

Sage: Yeah, for sure. Hi everyone. My name is Sagan Adebayo. You can call me Sage. I have. I mean, for the past couple of years, I've been working [00:03:00] on developer tools ranging from Chakra UI to ZackJS to Pandas CSS, RQI. Quite a mouthful now. I mean, after maybe five, six years working in open source but I'm, I'm glad to be here to talk about ZackJS and state machine stuff.

I geek about these things every day. So I'm happy to talk about it again.

Baptiste: Great. So when did, when did you start working on ZackJS?

Sage: Yeah, I mean, I think that's like 2021, 2020, 2021, roughly. So I think 2020 was when I struggled with X state. I just like during the COVID time, like where everyone was like at home.

I just spent all my time just watching, watching X state. I mean, from the front end masters course. I, I think I watched it twice and it's like, I did the same, I did the same . I'm not sure I get, I'm not sure I get this thing. It feels a bit too complex for me. But I think like slowly I mean it's, [00:04:00] it's amazing how the brain works, right?

Like after you do it once, twice, somehow the connections start to make sense. And then around 2021 I started to actually be the first, the first state machine, which was an accordion just try it out. Like this is Chakra UI, this is like the state machine. Let me try to make it match one to one but using state machines instead, right?

So I, I got the hang of it. Still a little bit clunky for my liking to be honest. But then I just like, After I built it again, I did it once and I did it again. It made sense. And I think from there on, I started to feel like I was ready to actually be, I mean, build with X state. So to be honest, it started with like, I want to build X state, not like ZagJS.

I mean, to be honest. But I think as I went down the Extent V4 path I mean, a couple of things were already like immediately obvious. Some of the patterns that you were able to do inside of the components in React, I wasn't really able to pull it off because Extent is very, like, it's a very [00:05:00] explicit system.

You model it and it's pretty explicit, right? And a lot of things in React is not exactly like Extent in that sense. So, like, The way effects work in React, where there are dependencies. When the dependencies change, the effects would run and you can control and do uncontrolled components. A lot of things in React that is very interesting.

Right. So those things were quite challenging to solve in Xstate. So I decided to like figure out like, and also Xstate was primarily based on React, right? So like the Vue and SolidJS versions were not too fully fleshed out in that sense. So I decided to figure out like, I mean, how can I solve this problem?

Again, also making this smaller library because I think X state v4 was quite a big size. So I wanted to actually just trim it down, create a very minimal version of X states and sort of leave with that for a while. So I've been on that and it's been pretty, pretty awesome so far.

Baptiste: Okay. And did you start working on the XGS to solve the problem?

That you had at Chakra [00:06:00] UI or was it totally independent?

Sage: Yeah, I mean to to be honest, the main goal was to solve the problem in Chakra UI But I wasn't aware of it at the time. Like I just wanted to I mean, it just felt like a cool new thing to learn That's how we started to be honest and then I think while the second time after I was to front end masters course, it doesn't make sense.

Like, I could actually use this stuff to do chakra UI instead of like just then for fun, right? So then it became like, okay, now this is serious. I have to take it seriously. Not just like do it for fun. So I, I spent the next year after that, just like. Digging into the, I mean, the state charts, white paper, reading about it, trying to learn about, like, the core details, read the SCXML specification on W3C website, like, just, like, get all these things inside you so you can actually, like, build something serious so from there on, actually, Then I had the goal to build Chakra with it see [00:07:00] how far I can go, I think.

I mean, to be honest, I didn't believe it was possible when I started, but I think the more I went on, the more I was convinced that this, this thing can work out.

Baptiste: Okay. And did you know about state machines prior to discovering Xstate during that period?

Sage: Nope.

Baptiste: Okay.

Sage: I mean, the, the, I, the most I knew at that time was reducers.

I mean, I could create a reducer function to do also things based on state and action, but like using the core concept of like your states, transitions, events, no, nothing of those, I mean, it's just Redux. Everyone knows Redux and some reducer. That's all.

Baptiste: Okay. Yes. I discovered the state, I think at the same during the COVID and.

Yes, there's a course of David Gossett on front end masters. I loved it. He did I think several courses, one for just state and one for react plus. X state. Yes. I watched both. They were, they were way instructive [00:08:00] and learn many things about state machines. X state as a gave a look to the SC XML documentation.

So X state is based. On some theoretical foundations, I think we can tell this way. So SXML is a specification that many libraries can implement and XState implements it. So many SXML compliant libraries should be compatible between each other. This was the base principle of XState as far as understood at this at this time.

And yeah,

Sage: totally.

Baptiste: So to, maybe to clarify in Zach's GS, you don't use Xstate, you forked it in, in, in a way and choose to, to rebuild Xstate for your Or in requirements, is it right?

Sage: Yeah, maybe, maybe I will not put it like that because it feels like, I mean, you're just trying to reinvent the wheel.

Like, what's the point of trying to rebuild something that already exists, right? [00:09:00] That's the feeling you get. But I think the thought was like, I really wanted, like, just a small, a smaller footprint of XState. So I took the X state. At the time, there was this X state slash FSM library, right? So that library on MPM is like a three kilobytes, I think, implementation of X state still by the X state, still made by the X state guys as well, right?

So I took that library and I started to say, okay, what can I build with this smaller version of the library? Because I was looking for a smaller footprint. And and. It couldn't, I mean, it wasn't as feature rich as the actual X state itself. Right. So I, so what I started to do was like, I started with that one as the base and I started to add back all the stuff that I wanted from X state.

And then if I like, you are really, really making X state again. So I'm just like, no, I'm not going to do this this approach instead. Right. And of course there's this pattern in X state where you have to like, I mean, everything has to be pure. Yeah. I mean, if you want [00:10:00] to set context, you have to like, Create a new object and spread it in, right?

So that really, of course, that that concept of purity came from React, right? So if you wanna create a new set of state, you have to set a new one or create a copy. But I mean, as much as that was convenient, I just really liked the VJS model of things where it's like, I mean, you just assigned the value and everything just worked twice.

So I liked the I saw, I liked the developer experience of the view reactivity system, right? So, and I wanted to see like, okay. I mean, it just feels nice if you have some state and you want to set some value, you just assign it and it's done. I think Svelte also has this pattern as well. So I wanted to just like get the DX of that.

But with the same theories and ideas as X state and state charts in general, right? So those were the things I took out. And just like try to like add my own little spice on top of it, I guess. Yeah.

Baptiste: Yes. Okay. Because Xstate has many [00:11:00] advent features like parallel states spawning, invoking, do you, do you need all of this to implement a XGS?

Sage: I mean, you don't even need, I think you probably don't need, maybe you probably maybe only 20 percent of the things in X state to be exact or to build any component. It's actually, that's right. So it's not, you don't need the whole shenanigans. We don't have nested states. We have the concept of spawning, but just a very basic one.

But then the main thing is just like the context, the the states, the transitions, the activities, which is now called actors. So those kind of things, that's, that's all you need. You don't want to do too many. I mean, I think the component, when you're trying to build a component, the logic is not too crazy, right?

It's not, you're not trying to build a whole complex electronic system or something, so it's just a fairly simple thing. So you don't need too many things to get that done.

Baptiste: Great. Maybe we can give some examples of components available in [00:12:00] XGS. You talked about Accordion, maybe there are other components on top of your mind.

Sage: Oh yeah, of course. I mean, we've gone really like full blown right now. We've got DatePicker, we've got ColorPicker, we've got Menus, NestedMenus, ComboBox, Autocomplete. So those kind of things we, I modeled them on a state charts, right? And a good part of that is a state chart is just a vanilla JS implementation.

So you can take that and integrate that and react in view and solid. I mean, even now we are playing with quick as well. So you could take that and put it in quick and it works as well. So it's kind of like experimenting with all these different ways of distributing the same state charts. I think that is.

Something we don't see enough of, like we, we hear and we hear about the concept of state trials. It sounds nice, but we actually don't see it work in our own framework, right? We want to actually see it work in our framework choice which is what ZagJS is trying to do.

Baptiste: Okay. So. The XGS is some [00:13:00] state machines for, for components.

And then if you want to wire both state machines to your framework, how do you do that?

Sage: Yeah, so every framework has like a reactivity layer, right? So React has some state, some reactive primitives, right? So, I mean, those are like useState, useEffect, useReducer. I mean, so a lot of the time, I mean, this state machine itself could be considered like, An external system, right?

And react is awesome because it gives you a hook called using external store. So you could take that hook and actually just like sync up the state of your machine with react in that sense. Of course, you have to do some render optimizations in there, but that's just react. I mean, other frameworks are pretty good on their own because they use the concept of signals, right?

So you can take something like VJ as a solid. Create a signal. I mean, we didn't, in effect, sync that up with the, the framework itself. And you don't have to think about the rendering and all the things, right? But with React, you have to [00:14:00] take care of these little bits. But I think we have like a, we, we, Zagreus ships like a small package.

For each framework, which is pretty much just like some sort of use effect and use state type of hook in every framework. Right? So, so you, so you don't have to think about this integration, you just take the machine, put it into the framework layer and then you're good to go. It just works

Baptiste: Great. What though, the state machine implement so you are talking about our audience.

So I think the, the state machine handle some events like clicking somewhere on the component. Does it provide something else like styles or I don't know something else?

Sage: No, not, not really. So I think the, so what we, what it does is just like we, so if you, if you look at, I think one of the most interesting things we can maybe take a look at, I'm happy to share my screen at some point, is like, does this, is this website called like the ARIA APG?

which is the [00:15:00] authoring practices for most for common components. Right now, if you read like, if you read one of these guides, so let's say you want to make like a, let's see, say, like an accordion components. Like you said, now, if you read the spec of that, you literally raised like a state machine. Like, I mean, if it's in this state, you can do this and that.

If it's in that one, you can do this and that. But of course we, a lot of the time we take that and maybe just implement it in react and we're done. But because it reads like a state charts, it's pretty much like, I mean, it's just there, like, it's just so sweet to take that and put that in some state machine and you're pretty much good to go.

So, yeah, we follow this kind of like specs to just like, I mean, we don't follow it to, to the letter. We try to test it and figure out if it makes sense to do that. But a lot of the time, this machine. Maps to that spec. And then, of course, on top of that, I provide just like other methods that may be helpful to the developer, right?

So if you say like the, I mean, for the accordion, if you want to [00:16:00] programmatically open an accordion, right? Of course, the spec is not going to tell you that, but it's just you that you have to figure out, like, at some point. Developer wants to programmatically do stuff or interact with this accordion, and I don't want them to learn state machines because that's a bit too much for them.

So what I can do is to expose a function, like maybe open an accordion. So like you say, pass the value of the accordion you want to open, it's going to open, right? Those are the things you have to think about just the developer experience of interacting with the state machine. As a building, the state machine is nice, it's just like building the engine of a car, but you're never really exposed to the engine at any point.

You just put some nice fancy stuff on it and people are people are happy to drive it, put a fancy seat on it. So that's pretty much how we think about building components.

Baptiste: Okay, so state machines. Are actually just a small part of XGS and then you add some I think accessibility layer and then I don't know, an API [00:17:00] to, to let the developers interact with it.

Correct. Exactly. Okay. And so we talked about an accordion component. I saw in the, on the documentation of the GS, that there is a button component. My question is, I understand as a next state lover that state machine solve complex problems. Way more easily than other solutions. But my question is does it feel necessary to use state machines for the smaller components?

What is your opinion on that?

Sage: Yeah, I mean, to be honest, I mean, a state machine is not like a silver bullet for anything. You don't just take it all and slap a state machine on it and say, I'm going to solve it. Of course, I have to say there's a bias to want to use a state machine to solve everything. But I mean, it's not so bad in itself.

I mean, I would say so like a state machine can have states. [00:18:00] I mean, and a state machine could also be used as a pure reducer, right? It's just Take something and set some states. It's not doing any state transition. Of course, I mean, so you could think of it like just a store, right? So at a lowest level, you can raise the argument that a state machine could also be a store.

There's some context information, some events that you have to exclusively send to update that store. That is the cleanest system you can ever have, at least. So you can make that argument, to be honest. Even if it's a small thing, you can always use a state machine for that. But of course, the counter argument to that is like, if it's something that's fairly, like, extremely simple to do, like, just, you just want to say it's pressed, true or false, like, no, you don't need a state machine for that.

Like, you just, I mean, just create some state primitives, use the state primitives of your framework to do that, right? But when it gets a bit complex, you then you have to, I mean, when you state, when you feel like you start to do like, I mean, I mean, it's open and it's expanded and you start to actually have [00:19:00] multiple states that you have to coordinate together.

And then it becomes very clear that, okay, there's some states and transitions here I need to think about. Of course, I mean, a classic React developer would not think of this. It's just like. Go in and use the effect and just like do all the jamboree there and make sure it works when you're done. But I think someone, I mean, a true engineer would think about that and see there's actually like a some sort of like state and transition thing we need to think about here.

And you don't have to use a library. You just have to figure out like. Create an object of all the states and figure out like, how do you want to transition between them? It's just a way of thinking, not really like, state machine is not equal to X in that sense. It's just like a way of thinking about problems and solving problems, right?

So that's, that's my own tech. So I have just two brains. I mean, there's one part of my brain I've used like, yeah, you could technically do that if you want, but at the same time, you have to be more pragmatic and figure out like, you don't have to [00:20:00] every time. Yeah.

Baptiste: Yes, I loved this explanation and you were giving the argument that maybe you could use Xstate for every problem and it could replace, for instance, Dustand or Jotay, which are libraries stores, libraries, Xstate does that, we can use

Sage: Xstate,

Baptiste: but yes I love that you, you mentioned that state machines are not Xstate, thinking in state machines, Is I think more important than learning X state you can use a state machines in over languages and JavaScript excited just for JavaScript.

But yes, I think one really, really cool thing is to learn thinking about state machines, state transitions. So I'm in this state, what can happen, et cetera. And I have another question for you. How many people did contribute to Zach GS, all the machines for the [00:21:00] components?

Sage: Yeah, I mean, I think we, maybe just like two people in general, that's me and another commentator, Abraham. So we pretty much just like work on, work on it. Abraham is still sort of growing in that process. I'm helping him out, just like helping him to learn about like the the details. And he's building out really cool stuff.

I mean, very recently he worked on a virtualization library. With with state machines it also worked on like a, an audio player. So it's kind of like a pretty cool thing you could do with, with state machines, right? So it's starting to build some more confidence contributing there. I would say like a large chunk, say 80 percent of the machines, I build them myself.

And then, of course, we are starting to also see external contributors. Maybe one person creates one simple machine. I mean, it always ends up being complex, even though it starts simple. Well, I'm glad we have like state machines. So like I helped them sort of deconstruct the [00:22:00] complexity and make the things work a bit more.

Baptiste: Okay. And did some people tell you that state machines are too complex, overkill, and maybe you should do things another way. This is something we hear about state machine, but no, you don't need them. I understand my use effects. I know how to code with his effect. No need for state machines.

Sage: Yeah, I mean, of course people do that. I mean, I think it's, it's a very common thing. Like if you're not, if a, if a concept is foreign to you, I mean, there's a very innate bias that you just want to talk down on it. Like, nah, it's not useful. I don't need it. I think even all the way back to like when React was introduced and JSX was introduced, everybody's like, what is this?

It's not so great. Like, why do I have to do this? Right. So it's, I mean, I think it's just human behavior in general, right? So, I mean, I don't, I don't consider it like someone does not like state machines. I think there's a level of complexity you get to that there's no other tool [00:23:00] that can solve this besides state machines.

Otherwise you just end up in chaos and regressions everywhere, right? So it's, you don't, you don't have to start with state machines, of course, I have to say that, like just use your, your library primitives and you're fine. But the problem starts to grow, especially if you work within a company and you're building a product, the complexity of your product grows exponentially, right?

So from next week, from this week to next week to next month, it completely grows. It just grows in a massive way, and you have to be able to tame that complexity in a way that can be easily maintained. Otherwise, you've just built a robot, a huge, a huge beast that no one can work with, right? So it's It's something that you come to realize over time.

So people initially don't feel comfortable with it. I think it's also kind of also means that, like, even the state machine people that, like, preach about state machines would also kind of like, I mean, in that sense. I mean just how I mean make it look a bit more sexy. I think that's the way I can put it Like just [00:24:00] let's not make it look a bit too mechanical and too structural and all these terminologies we throw around All right so it's just like if you You and when someone buys a car, you don't want to just introduce the engine or the chassis to them Like I mean, that's a bit too much, right?

so like they're not engineers to know the engine oil and all the specs like They don't care about that until there's an engine failure Then they care about what's going on, right? So it's that sound like the way I see it as well, like a progressive disclosure of knowledge so that people don't understand.

They're not exposed to the entire machine. It may be some API around it. It looks nice. Everyone can use it within the company and they love it. And it's consistent. People are happy. And when there's a problem, you say it's a quick fix. It's easy because all of the states and everything is explicit. I think people start to like it a bit more compared to the classic way of doing things.

So I think those are huge benefits. So I think people should see the benefits before they embrace this old idea of state machines in the [00:25:00] first place. Yeah.

Baptiste: Yeah. That was a topic I wanted to talk about. updating state machines. So you mentioned that you follow some specifications for accessibility. Do this specification change often or not?

Sage: Usually they don't change. I mean, it's just like, it's just like the HTML standards as well. Like they don't, they don't really change. If they change, they change once in like, Three, four years and that's fine. I mean, that's enough time to do a breaking change again. So technically it's usually not a breaking change.

It's just like an improvement in accessibility or stuff like this. So, I mean, a select element has not broken since how many years? So it's like, it's literally the same. If you wrote HTML in 1990 and now it's still, to select is to select, right? You will look different, of course. But it's still the same way and work the same.

And that's why I like it. Because every element in there you're designing for as a fixed set of interactions and a fixed set of APIs [00:26:00] in that sense. So that's why I think a state machine is just the best representation. Of that, right? So and that's kind of like the way it works. And when it comes to managing changes inside the machine itself, which is why I prefer like to always do like, I mean, an API around that, right?

So it's kind of like you don't give people the state machine to interact with directly, but you design an API around that such that I mean, You can change the system, but the API still stays the same, right? I think that's really where the benefit is. Alright, so like, I mean, even, I always like to use the classic example of a vehicle or a car, right?

Because like, I can literally replace a whole part of a car in the engine. And it still works the same way for you. Like all that you care about is once I put my key and it turns on, I'm ready to drive. Like, that's all I need to know. I don't care whether you change the exhaust pipes or something. It doesn't, it doesn't matter.

So that's really the way I think about it as well. An API around it. And you should be good to go. Okay.

Baptiste: So the state machine [00:27:00] you implemented at the beginning of ZagJS didn't change a lot, if I understand well.

Sage: Yeah, it didn't change a lot. Of course, we probably, most of the time we do, we rarely change it, except if there's really a bug, there's something that doesn't work, then of course we fix it and we improve it.

And the great part about that is once you, once you improve it or fix something. It propagates to everyone, right? Like everyone in every framework enjoys that benefit. As opposed to repeating that work over and over and over again across multiple frameworks, like that is crazy work. I cannot do, I don't have the lifespan for at least.

Baptiste: I think it's a great transition to talk about the future of ZackJS. What will will it begin start to, start to be in the future?

Sage: I mean, it's really hard because like right now I mean, to be honest, I would feel like the future of, of something like Zagreus already is kind of like already in progress which is like [00:28:00] RQI what we currently have, where so RQI is pretty much like making like the nice body of a car, like we just like take the team and just like put a nice shape around it and just like say, Hey, just use that.

The, the, I think the main goal, what we wanted to achieve with RQI is. I mean, if you see the code in react and you see the code in solid and you see the code in view, the only thing that changes 90 percent is the same. Maybe only 10, 5, 10 percent will change, but the code literally looks exactly the same way.

All right. And that is, that is, that's just like the ultimate for the ultimate form of like a component library when I can use it in multiple frameworks. If I don't feel like using react today and I want to use solid JS. I don't feel constrained because there's no component library in SolidJS. And there's way too many component libraries in React.

So people are forced to like pick React because of this reason. But maybe they prefer Solid or Vue. [00:29:00] js. I mean, we just want to try it out and see how it feels. So providing the same experience across board in every framework. That's really the future. We, we, I mean, we hope that ZagJS could get to, but we already achieved that.

So that's like awesome. So RQI already exists today. You can install it in at least three major frameworks, right? So I would say like, I mean, with the, with the rise of like new systems, like the AI and all of the like V0 tools, where you could actually scaffold a component. I mean, of course, the future that I see there would be like being able to actually like build complex UIs.

I mean, whether simple or complex UIs. Using all the primitives we provide inside JS. So you don't, you just have to say, build me a dashboard and it's gonna like, I mean, use all of the like primitives that we provide now. Q I whatever, whatever framework you choose. I think that's the real beauty of it.

So it's like, I can get like the state machines or RQI in that sense in react, view and [00:30:00] solid and my dashboard works the same, like it doesn't change regardless of the framework because today. All of these tools are kind of like either baked in React or baked in, I think React is the most common one. So it's like even any, even any AI system or LLM today, it's kind of still React centric, right?

Not, not, it takes a while for them to get to view a solid, but with RQIB actually I mean, we have the potential to build systems like that.

Baptiste: Let's assume. And if I start a new project today, should I use Zack or arc?

Sage: Yeah, I'll tell you, it depends on like what you, I mean, it depends on preference, if you like a pre pre made library, like radix UI, or like, I mean, or like if you're trying to get like a similar example, I just want to import the component and use the component. I don't care about anything else. Just use RQI because that gives you everything that you need.

But if you're trying to build, say, like a design system and you want to be in control of literally all the decisions, [00:31:00] say you have a big company, a slightly big team, you guys have, you have the resources, you want to actually, you don't want to build the logic, of course, but you want to actually take control of, like, all the components are named or all the props are named, or how the things work, like.

Then you have, you can go low level without JS, because what we do is just like with RQIs. Take away all the decisions from you. Just like we just make a pretty reasonable decision for like the naming of the components, the naming of the props and all those things. Like we just make those things ahead of time for you and you're good to go.

But if you want control, I think developers somewhat like control at some point. Right. So like if you're a person that you like, you like to want to control things then of course, address is your. It's your pick in that sense. Great.

Baptiste: And is Arc already used in the Chakra UI or not, not yet?

Sage: Yeah, that's, I mean, Arc would power Chakra UI v3.

Chakra [00:32:00] v3 actually is already, I mean, we have a pre release already for Chakra v3. And the pre release uses Arc UI. I mean, the goal of Chakra is like, I just want to delete all of the logic code in Chakra. I never have to maintain any of that again. Like Chakra should just purely be the UI stuff, right?

That's it. Not the logic bits and stuff. So I just like take all of the nice goodies from RQI and combine that with Chakra and the style prop system. And that's it. You're good to go. That's how we build Chakra, right? So I mean, of course, we're looking forward to releasing that pretty soon. Maybe when this video is out, it will be released already.

But like me. We're looking forward to getting that out.

Baptiste: Let's assume. And where can we find more information about Zag and Chakra? Zag, of course, is

Sage: zagjs. com. You can, you can go there to see like all the info. RQI is also there, rqi. com. You see like all the you, you probably [00:33:00] be able to see when you look at the code snippets between ZagJS and RQI, you see what we talk about.

When we feel like we try to make the experience a lot easier and then chakra, of course, it's pretty much the chakra UI that come you see. You see like the current version of chakra, but the next one is also coming out pretty soon.

Baptiste: Great. And where can we see more information about you Sage on your website, maybe?

Sage: Yeah, my website it's a pretty long domain name, adbio. shagman. com, but you can also search for me on Twitter, Sage Shagman Adbio as well. You see me everywhere. And you should, you should, at least Twitter is a pretty common place to find me.

Baptiste: On Twitter, maybe too?

Sage: Yeah, Twitter, yes. Shagman Adbio, that's it.

Baptiste: Great. Thank you a lot for all all those information about State Machine, Zag, and Chakra. Thank you for your time. And I hope to talk about you when Chakra UI version 3 is released.

Sage: Oh yeah, of course. Awesome. Thank you so much for having me. [00:34:00] Thank

Baptiste: you,

Sage: Sage.

Baptiste: Bye.

Xstate in the wild. Learn how experts use Xstate.