# Mind-Reading with adaptive UIs

Canonical: https://davidk.dev/talks/mind-reading-with-adaptive-uis/
Video: https://www.youtube.com/watch?v=dLK2zW6c79c
Speaker: David Khourshid (@DavidKPiano), creator of XState
Type: Conference talk · Event: Agent Conf 2020 · Year: 2020 · Duration: 37:24 · Views: 272 (as of 2026-10-19)
Topics: Adaptive & intelligent UIs, XState, React hooks, Visual modeling

## Summary
Information in order to create a better user experience by making the app more adaptive. Adaptive user interface is also known as a UI RU, our interfaces that adapt to the user.

## Key takeaways (quoted from the transcript)
- Information in order to create a better user experience by making the app more adaptive. (4:00)
- A better user experience might be instead clicking the delete button, having it say deleted, and then having the user have the option of clicking undo. (8:00)
- First, we have to create an abstract model of how our app behaves, then we have to measure transition analytics so between the states, we have to keep track of what the users are doing. (14:00)
- When we have this model, this full abstract model of our application, we could determine where users are most likely to go. (19:00)
- Adaptive design or development lets you create kind of a customized user interface for each user by using this machine learning. (29:00)

## Chapters
- 0:00 Introduction
- 2:00 Google also has a lot of examples of these adaptive user…
- 12:00 Statecharts extend on finite state machines by providing things such as…
- 14:00 We want to measure how users are using the app so…
- 25:00 Code do more using finite state machines, abstract modeling…
- 32:00 There's actually a Python tutorial…
- 34:00 - yeah, you could use Exeed…

## Transcript
[0:00] I just feel like it's a very community driven conference, it also is a lot of quality and people are just nice. Hi, my name's Sarah and this is agent Conf in Dortmund. [Music] amazing venue. Austria is beautiful, meeting all the people in the community and getting to go and hang out and ski. [Music] thank you, thank you. So I know what you're all thinking. Can you really read minds? And the answer is yes, because I just proved it.

[0:00] Today, I'm going to be talking about mind-reading with intelligence and adapt abuser in their faces. But before we get into that, I want to show you sort of a counter example of this. Now, some of you might know this company name, Slack, and some of you might remember a couple months back, Slack decided to add a rich text editor and it sucks. And it was an unannounced change. And everyone, well, not everyone, but so many people just hated it.

[1:00] And so there were two reasons that we can nail down why. This was just a terrible decision. For some people, it works, but for other people it doesn't. And that's where the point here is. That this is not an adaptive user interface, because we're basically forcing all of the users to use this rich text editor, which thankfully they rolled back. And it's also not adaptable, so the difference is adaptable. Means that we could go into the user settings and we could say, I don't want this rich text editor instead, I just want my normal markup or markdown editor.

[1:00] And Slack didn't even provide that option when they rolled out this feature. Now the thing is that when we're developing applications, we tend to make some pretty terrible user interface and user experience design choices.

[2:00] But it's not necessarily our fault, it's just we were not interviewing enough users. We're not understanding just the different types of users that are using our applications. One example of this, you know? Jerod Palmer said that forms are really hard to make, and we see this all the time. It's like, let's say you go on the web site says, enter your new password, so you enter your password, and then it's Confirm your password.

[2:00] So you start typing, and then the website says the passwords have to match you. Absolute idiot and I. Run into this all the time. It's like showing validation and just not a very friendly user experience, because, simply put, we're not adapting to the user. So here's the main core problem is that everybody is different, we all have different needs, we all speak different languages. As Ellie talked about, we all, we all even look different, except most of you look European, but that's okay, we'll talk about the Leer.

[3:00] And so because of this, A, B tests aren't effective. Because when we do A/B tests, we're forcing users to choose either A or B, and then, depending on the majority of which users prefer, we force all of the users to be in this one, either A or B. And the thing is that could be a terrible choice, you know, no matter which one you pick. Also, we have to realize that user flows are seldom linear.

[3:00] So our traditional techniques of using funnel charts and doing like Google, Google analytics or KISSMetrics, or something like that. And seeing how users go through a flow. That doesn't really tell the whole story. Because there's many different ways a user can use her app, and there's many different paths the user could take. And so by measuring just one flow, you are measuring only one of many. So we have to improve the way that we do analytics in our apps.

[3:00] One such library that's doing this, it's created by Sam Ciccone over at Google, it's called guess Jes, and what guessed is it's machine learning and predictive analytics for prefetching. And so you could just plop this into your web pack, app or even your static website. And what this does is it uses Google analytics and it predicts what the next page your user is going to visit based on what your user has visited before.

[4:00] And because of that, we could prefetch that pages contents and load it really fast for the user. So this is an example of one of, like, one of many libraries that are really good for adaptive user interfaces. Another one Google recently released a couple months back, it's called React adaptive hooks, so if you're using React, you could use these hooks directly in your app. And measure things such as CPU, your Wi-Fi strength, your battery levels, all of that and use that.

[4:00] Information in order to create a better user experience by making the app more adaptive. So I keep throwing around this adaptive word, what exactly does that mean? Well, adaptive user interface is also known as a UI RU, our interfaces that adapt to the user. So a UI is a subfield of HCI, which stands for human-computer interaction, which is exactly what it sounds like humans interacting with a computer, computers interacting back with the human.

[5:00] Now, traditionally, when we make apps, it's not very adaptive. We're like, what you see is what you get, these are, this is the form you're gonna fill out. This is the way the app works, and if you want it to work a little bit differently, then you could email. Select 20 times, telling them your markdown editor sucks. So, adaptive user interfaces adapt to people, not just devices, and so you might think of responsive design as adapting to an advice.

[5:00] Where you might have a small mobile device or a large one of those big, curved, 40 inch monitors that cost like $1,000. But adapting to people is fundamentally different than this, because it's like, you are the device. And doing that, it's a lot harder because computers don't exactly have a clear mental model of you as a person. One of the earliest examples of an adaptive UI is Clippy, from Microsoft. You know, I didn't work on Clippy.

[6:00] I was a, you know, kid at that time anyway, Clippy. Whenever you were typing either in Excel or word or whatever, it would pop up with some helpful suggestions, and so Clippy was being adaptive also really annoying. So another word for adaptive user interfaces is intelligence user interfaces, and so basically. The aim of this is to improve efficiency, effectiveness and naturalness of human machine or human-computer interaction. And this is one of the original papers on this on intelligent user interfaces, written back in 1999.

[7:00] And so that's gonna be our goal today is getting there. So we're gonna be focusing on step zero, which is how do we write our apps in, model our apps so that we could get to that point? So, for example, let's say that you're coding an email client, the user might visit the inbox first. And then there's a bunch of different, that different paths, like we talked about that. The user could take either they might want to view the latest emails that they have, or they might want to compose a new email.

[7:00] Now, depending on what they do, when they compose a new email, they might want to save it as draft, maybe not send it yet. I let email sit in my inbox for days because I forget to send them, or they might want to send them immediately. The thing is that depending on the user, the we might do different things, or they might be more likely to traverse different paths. And so this is the thing that we have to measure in order to create these adaptive UI's.

[8:00] Another example is in terms of improving the user experience. For example, a delete button. Typically you would have some notification saying, are you sure yes or no? You click yes and it will, it will delete it. Now. At first, this is nice because you're like, thank you for asking. I'm really appreciative that you want to make sure that I really want to delete this. However, that gets annoying after a while. And so, a better user experience might be instead clicking the delete button, having it say deleted, and then having the user have the option of clicking undo.

[8:00] So Google also has a lot of examples of these adaptive user interfaces. I love this and I've been using it a lot. Where you start typing an email and it will predict what you're going to say next. And all you have to do if you're on your mobile phone is just swipe, right, I think. And over here, you just press tab and it's just like autocomplete in your editor, it will predict what you're saying and fill it up you.

[9:00] So this is another example of an adaptive UI. Now I work at Microsoft and I've been talking about Google a little bit too much. So here's an example. In VS code, there's something called Intel Akkad, both for visual studio and VS code. Now this is really cool because it uses machine learning to predict what the next thing you're going to autocomplete. And this could do things like from just methods or properties to even full snippets.

[9:00] So I really encourage you to check out in Teleco for VS code as a great example of this. So you? See the difference when you press the dot, you're going to see stars, and those stars are what it predicts. It's frozen right now, it looks a lot cooler here, but yeah, just look up Intelli code for VS code. Also, adaptive user interfaces are important for distinguishing between what we call power users and normal users, or users who might be new to your app.

[10:00] So we want to provide flows for users who just want to get done, they want to go from A to B, the C done. But then users who might not be familiar with the app, we might have to provide them more guidance. And that's what adaptive user interfaces can do. However, developing adaptive user interfaces is not without its challenges. And also this is a cutting-edge topic. As I mentioned, one of the first papers mentioning this was written in 1999, which is 20 years ago.

[10:00] But it is still an active area of research and exploration in the human-computer interaction community. So all of the things I'm gonna be talking to you about are cutting edge. They are being implemented in production in companies like Google and Microsoft, as we saw. But what I want to talk about is getting there. So the road to adaptive user interfaces. Now. To do this, we need data, and actually we need a lot of data, we need big data.

[11:00] And we need to collect all of this data in a structured way and in a predictable way. So that we can make sense of the data and actually incorporate it back into our adaptive user interfaces. So how can we do this? The answer is model driven development, which is, I promise you, a lot different than the development that you're doing nowadays, the development that we do. We're just like, Okay, we have a feature, we have a sprint cycle, which is maybe a week or two.

[11:00] Let's just code that feature in and then be done, maybe run a few tests and ship it. Model driven development is different, model driven development means we have to plan everything first, and so what's one of the best ways that we could plan these features? You might know of user flows, user diagrams, things like that designers love to use.

[12:00] Where we have a very clear outline of going from one state. To another state. And if you've seen any of my other talks or follow me on Twitter, then you know that, you know. State machines are a big part of that, and essentially that's what user flow diagrams are, so just a reminder of what a state machine is. You have an initial state, like a sign-in form, or like a sign-in page.

[12:00] You have a finite number of states where the user could travel to a finite number of events. That could cause transitions between these states, and also potentially some final states where you consider your app flow finished. And we prevent errors like this by using finite state machines. So, honestly, if you want to find me on Twitter or something, just type state machine and I'll say hi, I'll find you, I promise. So, statecharts extend on finite state machines by providing things such as hierarchy, parallel states, history, actions, and so much more.

[13:00] And I wrote this library called XState, which allows you to do that now. We're not going to be getting too deep into XState. Just know that X data is one of many ways which you could represent these finite state machines and statecharts. In JavaScript or whatever other language you're using now, XState also available for React, it provides a React took. I know that many of you are using React. So there's a useMachine hook, which is essentially useReducer on steroids.

[13:00] You provided a machine, you get the state, you could send it, events. It works as simply as that you could use it at the local level or at the context wide level. And coming soon, there's going to be exit four for View, like a plugin for that using views new composition API. However, XState is agnostic enough that you don't really need to have an adapter to these libraries. You could use it as is the machine definition works as a pure function, or you could interpret it, and it just works as an event emitter.

[14:00] So, you know, works with you.

[14:00] Angular, spelt, whatever you use backbone, I guess I can try it. So let's take an example app. Let's say that we are trying to make a feedback form a very simple feedback form, and this is the way it works right now. You click good. It says, thank you for your feedback, you click bad, and it asks you why, it asks you to provide feedback and submit it. So here's here's how it works.

[14:00] You know, you click good, it will say thank you and let's rerun it, you click bad. You could complain here, you could submit it. It's that are a very simple app. You might be thinking in your head, OK, I know exactly how to create this, but let's make this adaptive. So here's a general game plan for how we can make a simple app like this adaptive. First, we have to create an abstract model of how our app behaves, then we have to measure transition analytics so between the states, we have to keep track of what the users are doing.

[15:00] Then we could identify which paths we can make adaptive. So that certain users get one path and other users might get another path, depending on what suits them best. And then we use that analysis for that adaptation. So there's a few concepts we have to learn here first. The first is weighted graphs, so a directed graph. You have nodes that connect to each other. With these edges, weights say. OK, you might be 90% likely to go to success and 1% likely to go to error.

[15:00] And of course, you could measure this with metrics. And so the weight of going from sign-in to success is a lot greater than going from signing in to error. And so that's why, when you think of your app flow as a whole, it doesn't look exactly like this, but it looks more like this. And when you visualize it, you could see which paths users are more likely to take, and then you could identify places where users don't really use the app too much.

[16:00] So a couple years ago, I was working on the visual Studio live share plugin, or extension 4 vs. Code in visual Studio with a lot of other really talented developers. And there was this part in the user interface where we had to model all of the different ways that the user could sign in, share, join, session. And these were finite. States like these were states where a user can't both be sharing and joining at the same time.

[16:00] The sign-in flow was a very, very sequential flow. And we want to measure how users are using the app so that we could identify. Alright, there's a lot of errors that users are running into, or more people are sharing than joining. And so, by modeling it as a finite state machine, and then adding it to the extension, we were able to create visualizations such as this in D3, which this is sort of a force directed graph that shows the weights of going from one state to the other state.

[17:00] And we were able to identify problem areas, identify how users were using the app over time, and a lot more. All right, so let's go back to our feedback app. So we want to, we want to change this up a little bit. Let's say that if the user clicks bad and they it takes them to the forum screen, the user decides. I really don't want to fill that out. So instead, it should just say thank you after the user does that for a while.

[17:00] So I will go ahead and show that, let's see, all right. So keep in mind B analytics to the rights, because that's gonna be really important. Let's say that we click bad and then we, we really don't want to, you know, we really don't want to submit why we clicked bad, so we're keeping track of over here. And this is just simple counting. So this is a very simple example of an adaptive UI.

[18:00] So I keep doing this and I keep clicking bad, and I really don't want to fill out that form. Boom, having a terrible experience, so I keep clicking bad. And then eventually, after it reaches some threshold, it will just say, thanks for your feedback. So I'm like, okay, that's a lot nicer of a user experience, and so that's an example of an adaptive UI. So going back to here. So what we did there was, we analyzed the transitions, we measured how we're getting from one place to another place.

[18:00] There are one states to another state. And using those measurements were able to determine what is the best path for the user to go to. So, take this, for example, let's say that we're creating some sort of Instagram map. We have a login page and it could go to either the gallery, the camera or the. Profile by default, it goes to the camera. But let's say that over time, we measure the users interactions with that app, and we see that the user is most likely.

[19:00] This one in particular, to go directly to the camera. So they're more of a producer of photos rather than a consumer, so we could instead creating an adaptive path and take them directly to the camera, doing that now. There's many machine learning techniques that I'm not going to go too deep in to right now. Because, you know, lunch is soon. But one of them is decision trees, where you would take your data.

[19:00] And in order to identify which states should we take our user to? Next, there's a number of metrics that we should that we could analyze and determine. Okay, because of this information, this contextual data that we know about the user, we might do different behaviors depending on that. So, I encourage you to look more on decision trees to learn about how you could use them in your applications. Now, when we have this model, this full abstract model of our application, we could determine where users are most likely to go.

[20:00] By using shortest paths, and in case you don't know, a shortest path is just a shortest. Wait to get from a starting states to some other states. In this case, we could go between a B and C, but with a weighted graph, it's a little bit different. So let's track metrics here, let's say that we're moving through, we're tracking things such as the target state, the source states the event that happened and the time that it happened.

[20:00] So based on these metrics that we collect, we could say all right. Even though going from A to B to C is the shortest path, most users are likely to go from A to D to E to C. So, in other words, A to D to E, the C is actually the shortest path. And so this is where it gets a little bit tricky and mathematical for analysis, you know, bringing machine learning into it and things like higher order Markov models.

[21:00] Which, like, we talked about, let's say, a user is more likely to go from A to B than A to C. But depending on the state before, the user might be much. More likely to go from AC than A to B. So now we have to take into account all of the different states that happened before. And so these are, you know, a few more advanced topics. And so we could also use deep reinforcement learning, which combines machine learning and reinforcement learning together, in order to predict the users behaviors.

[21:00] Now, reinforcement learning is really cool because we're essentially training an agent to predict a user's behavior, and we're punishing it if it doesn't predict it accurately, and we were rewarding it if it does. Predicted accurately, and based on these rewards, when a user uses the app again for a new time, we could be able to predict it more accurately. Now, just a quick primer on how reinforcement learning works. You haven't agents.

[22:00] That's like your AI robot that's going through the app. And doing all these actions and making sure that those actions are the right actions. And so the way it chooses these actions is via a policy, and so the environments, we analyze the action on the environment. If it was a good action, we give the agent to reward, if it's not we, you know, we don't give it as much of a reward.

[22:00] And so that I action causes a change in states. Now, deep reinforcement learning is about taking that states, putting it through neural networks. Don't ask me what this means, I have no idea. And then eventually getting in action. So you might be thinking, seriously, can we really use reinforcement learning in applications? And the answer is yes. And you're just gonna have to take my word for it, or I could just show you what demo right here.

[23:00] So what I did over here was I created a very simple tic-tac-toe game and I used finite state machines just because that's sort of my thing. And this is a very simple game where you know you play. And let's see if I. That was a terrible move. Okay, so okay. Oh, won that time. But when we play what I'm really doing over here and I, I was. I did this for about half an hour and we could see that.

[23:00] There's actually a different frequency in which we play certain squares, so we see that the center one has played a lot. And as we. Go through the game, the frequencies change, and so you see over here, this is a game position that has never been played before, which is why all the squares are gray. So what we could do is we could feed that right back in to an agent and use reinforcement learning.

[24:00] In this case, I'm using simple cue learning in the browser in order to predict what the next move is going to be. And so what that means is that I could instead play against an AI, and so I'll do that. Over here, you could see the training values over here. This is used to determine the reward you get for playing a certain square. So now this AI is, its goal isn't to win, its goal is to play like a human.

[24:00] So let's see if it does that, so let's say, let's see if it blocks me. It did block me, okay, so let's say I go here. It blocked me again, which is great. And so this time we're going to tie. So now let's do something again, let's play really dumb and hopefully it will win, so there we go. So it's using a combination of frequency based on the analytics that we got, you know, playing the game over and over again, combined with reinforcement learning, and so thought that was pretty cool.

[25:00] I also have a video here in case the demo fails, which it did not, which I'm really happy about.

[25:00] Alright, so, in short, we have an application, an application that you creates, and we create an executable abstract model, which is the state machine of your application. Then we track using metrics and in XState or any other events, and in your library or subscribable library. This is just you do it in one place, you do it wherever the state is being updated. So if you're using React, you could even put it in a useEffect or something like that.

[25:00] Then we could take those raw metrics and provide two things like as your analytics, Google analytics, segmented IO, Mixpanel, KISSMetrics, whatever you use in your applications. And then we feed that back into the executable model and just identify areas for adaptability, and then we put that right back into the app, into the application. So we no longer have to, Ida. Rate through many weeks of Oh, does the user really want this?

[26:00] What's the best user experience for all users? Instead, we can adapt the application as the user is using it, which I think is really powerful and really exciting. So even though this is a cutting-edge topic and there's nothing, you know, there's not too much about it yet. I think it's really exciting. Unlike React concurrent mode, so the dev experience in representing your applications as abstract models. You have determinism so you could identify what state you're going to go to based on the currents in the vents.

[26:00] You have visualization capabilities, communication between developers, designers and other stakeholders. You could generate tests for that, tests for this are using model-based testing. You could even use that data and provide simulation of just modeling how users might use your app without a user actually being there. And so all of this translates to a really good user experience. Because we're capturing analytics from the user, using those analytics and feeding it back into these date machines that we've created for our apps.

[27:00] So X8 has a lot of libraries to help in. I'm also working on an XState analytics library, X8 View is coming out soon, as well as many other libraries. So if you want more information on that, you could just visit ext.js. Org, Slash docs and also there are visualization, so if you go to X 8, SJS org, Slash Biz, then you'll see that. You could take your machine definition, copy and paste it right into this and then be able to just walk through it and verify that your abstract model of the application works exactly how you expect it to work in your head, it works exactly how your designers expect it to work.

[28:00] And you could use this exact same code right back in your application. So sort of like Jared's for MacLeod, this is basically like XState Cloud. I don't know, I didn't really give it a name yet, so there's a lot of helpful resources. The world of statecharts is a really great introduction to what statecharts are. We have a spectrum community where a lot of people ask questions about statecharts and X data in general, and, of course, the XState docs.

[28:00] So overall, I wants to make your. Code do more using finite state machines, abstract modeling, model driven development, and more. Thank you so much, agent Cough. [Applause]. Hi, I'm Clemens. Thanks for the talk. I've got a question, as far as I understood it. Adaptive design or development lets you create kind of a customized user interface for each user by using this machine learning. Patterns, right? Correct? Yeah. What I'm wondering is, isn't it kind of error-prone this way?

[29:00] When you've got like thousands or millions different versions of your user interface out there? And people may report it back or something. And you have to figure out actually which worse and which are they using. That's a really good question, and actually, that's one of the biggest questions in the Cuman computer interaction community about adaptive interfaces is that. The worry is that these user interfaces can make your app a little bit less predictable, actually.

[30:00] And the truth to this is that if you have an abstract from all of your app. The the way that finite state machines work is, that's how it's always going to work. Nothing is going to change. So when you build that activity into your app, you still have the exact same transitions, you're not like making a random choice or whatever. And so the way that you could test and predict how you could use your app is two ways.

[30:00] First way is you're providing those analytics. Like, let's say, as a JSON object or something where it's like, the user. Is this percent likely to do this, this present likely to do that? And so when you're testing, you could provide those values and say, given this set of metrics, how is my app going to behave? So it does become a lot more predictable that way. And the second one is actually it's called mixed interaction mode.

[31:00] And what that means is you're providing an activity and also adaptability, so you provide some adaptivity. Where it's like, okay, let's, you know, have a menu, like a menu list with the most likely items, the user is going to select that top. But so, if the user needs to customize anything, then they can go into the settings panel and be able to tweak those values themselves. So hope that answers your question.

[31:00] Okay, cool, that doesn't make any difference. I'm very loud. Three, two. One Okay, oh, that was like 0.25, man, you got really lucky there.

[32:00] Yeah, you didn't give the H and any information about how to win the game or anything, you just. They just decided. He's action based on what the human would do, basically, exactly. And I think at the moment I don't even understand half the code that's in there. In fact, I could actually show you real quick, just an example of what it's doing. Okay, yeah, so I have, like, alright, here we go, here's my Ax, basically my inputs.

[32:00] What I did was I used a. There's actually a Python tutorial, a very simple Python tutorial on using Cubase reinforcement learning with tic-tac-toe. And I adapted that directly into here, and I use the state machine to help. And so that's why you have variables in here, such as LR, which is the learning rates, the decay gamma like in 0.9. And these seem like a lot of magic values. But that's basically saying, as I play the game, if an action is considered good, maybe don't consider it that good.

[33:00] Like, maybe give the reward a little bit less. Because we don't know for sure if that accident was good or not until the game was won. And so basically, it is very ugly code right now, but it is a copy-paste of a Python reinforcement learning tutorial, so it is actually learning. And that's why if I played poorly, then the machine would also play poorly, and that's why the goal is for the machine to acts like a human instead of trying to win.

[33:00] Thank you. Does that make sense? Okay, cool, so how you doing great?

[34:00] You just like, go up the stairs and hey, what's for lunch? I've heard that it's like they're like pork burgers and vegetarian options. Sounds great, I know I'm super excited. Hello, thanks for your talk. One short question I've seen some advice was internet to skip. The whole state library is like my bags or red X or whatever, and just use X right for you. React application it's hard to imagine how to use it in a real world example.

[34:00] I mean, when I've got a really big React application, how can I imagine that? Do I not use you state at all? And everything is in a state machine of. XState, or is it a mix of both? So that's a really good question, actually, all the questions were really good, with that one in particular. I actually just read an article that upset a lot. Redux people, it's called Redux is half of a pattern, which I described how Redux is half of the state machine.

[35:00] And I actually don't mention next state at all in there. But basically, what I would say is take a step back even further, even though I created that state, what I recommend to people now and I, I work. I also do consulting with Reax training, in which we give React workshops teaching how to use hooks. And so what I would say is, take a step back, don't use Redox, don't use Mob X, don't even think about any other state management library.

[35:00] Instead, start with basic hooks, start with used. And then once your state becomes more complex, you go to useReducer, and useReducer is when you could apply these finite state machine techniques. I mean, you're gonna be using a lot of switch statements. And so once that gets more complex, then you could think about using something like XState. Which provides a used machine hook, which, like we talked about, is just used reducer. Because the fact of the matter is that a lot of the stay in your app is distributed, which means local and localized.

[36:00] And instead, you have components communicating with each other and that sort of antithetical to having a full atomic global states. So what I would suggest you is start small, useReducer is going to be your best friend and React. And if you're using Angular, then the scan operator is great, if you're using View, then. I don't know. I haven't done too much for you, but yeah, okay, thanks. So that means it's totally legit to have both, right?

[36:00] For example, a local state in your component is still, or normal, your state property, yeah, or useReducer when we are talking about fetching data from an API, it's fine to use something like X-ray. - yeah, you could use Exeed, so useMachine is basically useReducer and useEffects combined. Otherwise, you, you could, even if you I don't know if a year down the road you start using Exeed and then you're. Like, I really hate XState.

[37:00] All you have to do is refactor that to useReducer and useEffect, and you get basically the same thing. Okay, thank you very much. Mm-hm.