I read some comments and I think that people is mixing the concepts. First: State Machine !== State Management. Second: You could use both at the same time, no problem. Let's imagine you have a search input component: Inside the concept o state machine, the term "state" refers to the current condition of your app, For example - Search input is empty - Search input is filled - Search input is disabled Each of these state is one of the possible conditions (finite state) that the search input component can have and has nothing to do (directly) with the variable that will store the value atribute of the input or the variable that will store the loading state. One of the ideas behind using state machine in frontend dev is that you are taking an approach less imperative and more declarative towards the possible state (conditions) of your component may have, that can help you with component testing and avoiding unpredictable situations like infinite loading or unexpected error, for example. There is a video that is about this libary and explains much better what I tried to mean XD ua-cam.com/video/wgWwJSnhgDU/v-deo.html Also recomend reading about finite state machine in game development, that you'll have good insights for front components dev.
Very interesting. I like the way you can visualize the state transitions and simulate them. That's really helpful in understanding the potential paths through the state machine and identifying invalid states and transitions. I often ponder this while writing code. My current practice is to draw a diagram of the state machine before coding it.
I'm studying this concept since 2009. I create a very disrupt method to teach tech and you are one of mt favorites channels in this path. Thank you. I love State Machine, this is Kabbalah !
Man, this was super resourceful! I'd be curious to see an example of xstate and react-query, covering the best practices for some real-world retry behavior. Maybe going into detail of how to inform the user they may not fetch again because a maximum fetch failure limit was reached and you must refresh the page in order to re-attempt the request. This can be useful in preventing users from spamming the retry button
I think state machines using XState are useful, but must be used and applied carefully, as they can make a simple scenario to be a lot more complex to read and maintain. Taking the video study case as an example, you can easily achieve the same result by wrapping load, reload and retries in a custom hook and using libraries such as react-query. This will produce a more readable result in fewer lines of code. I would only use state machine if states don't circle back to only two different ones like in the example, instead, I would use them to represent a more complex workflow.
Yeah, I hate it. Perhaps it’s useful in more complex examples, but this is ultimately just makes code unreadable. Is it possible to do everything in XState, or are there limitations to what you can do with it?
@@hojdog in my experience I was adding a lot of loginc to a map that becames impossible to maintain. Every time that I need to add login to that was painfull with redux and redux saga. But with xstate all the complex logic was reduced to almust 0.
"If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail." People tend to blind themselves with these tools. They have something simple they want to do, but they overcomplicate things by using tools that aren't necessary for the job.
If you think this is supposed to be a replacement for react-query then you are missing the point. The point is to implement bespoke logic. XState really shines the more complex the logic becomes, but once you are already familiar with it, there is nothing wrong with using it for simpler logic.
Thanks a lot for this video. One thing though, I think you should warn beginners/juniors that this type of tech should be used for large and complex applications. You don't hunt with a bazooka. Once again thanks for all your content!
“The nice thing about x state is it handles all your state and logic in one place”. Heard this many times with 90% of state management libraries (Redux, Mobx…)
That's actually two different states these libraries are managing. The term state is confusing and actually means several different things. The FSM however could be also done via redux and co.
It's absolutely amazing lab! At my full-time job I use XState to re-write (2 or 3 time) complex custom auto-complete "with whistlers" finally with zero errors and no glitches. Yep, it's not simple as it feels should be, but its works and mountable. Thanks for video.
This tool is pretty awesome! Thanks for demo. Yes the demo fetch scenario would be best handled with Polly or Cockatiel J's libraries, but I got the gist of how x state works and I think it will be great for maintains some workflows that my app uses to guide users over several days. Might even use it in transition some windows workflow foundation workflows.
Bro, thank you very much for all the content you share, your channel is the best for react and js, this is very interesting, try to take a little course on this.
I have a question, But I don’t know u will understand or not Qno If we have eventlistners and we pass args like click and dblclick Question is how much time its waits for next click if event is for double click… We have both ‘click’ and ‘dblclick’ on same element For how much time it will wait for next click if user wants double click Hope u understand Thanks
Wie kann man im Kalender in der Wochenansicht (5-Tages-Ansicht) den aktuellen Tag, also die ganze Spalte, highlighten lassen? Früher ging das (z.B. gelber Hintergrund), seit vielen Monaten geht das dummerweise nicht mehr. In deinem Video sehe ich einen dünnen blauen Rahmen um den aktuellen Tag, das wäre ja auch okay. Aber ich finde nirgends eine Option dazu, auch bei den Regeln habe ich nichts Passendes gefunden, außer die abgelaufenen Termine ausgrauen zu lassen, was aber mit sich wiederholenden Terminen nicht funktioniert. Vielen Dank!
@@fyfirman useState is just a stateful value and setter function. Xstate is for configuring complex state machines. It's more like useReducer with an opinionated interface. State libraries like xstate become more important in larger applications.
You wouldn't use a state machine to handle if a button was clicked or not. States machines can simplify complex logic needed for switching between and keeping state in an app. Its another way of saying "I will change into [someState] when [someConditions] are met."
I think so, a state machine can be simple or complex, in the case of a small project we would have simple state machines, and if tomorrow the project grows, scaling the logic of the state machines would be relatively simple and the expected behavior would be clearly defined.
I like how xstate tries to simplify state management with state machines. I am just not sure if it is worth to use for every component. I think it would be better for something like a game that has a lot of complex state management is required.
From what I understand, Redux's actions are triggered by events and X-State's actions are triggered by state changes. So Redux is like "Do this..." and X-State is like "Do this after this...". It focuses on the transitions between states which makes it more powerful.
I think this (ua-cam.com/video/HfZCcg9_3t8/v-deo.html) is a better first-example to showcase the power of state charts, rather than a contrived fetch. Here, you see (1) a clear separation between business logic (state machine) and declarative ui (jsx) (2) a lot of logic like "can I click this when in xxx state" is no longer required, as the library can infer that from the state machine. The UI side just uses APIs like `can`, as shown in the video. If you have a crazy amount of `useState` and it is being set all over the place, this is a better alternative, at the expense of having to learn the syntax.
For those that are confused, I found the solution: 1) Don’t use booleans for options with more than two potential states. Use an enum, a class, or a module with exported strings. 2) completely ignore this. 3) Continue using Redux, or if for some inexplicable reason you want to… mobx.
Hey Kyle, In the actions you are mutating context and that is something that you should avoid. You can find it in the docs Instead of: increaseRetryNumber: context => (context.retries += 1), you should do: increaseRetryNumber: assign({ retries: context => context.retries + 1 }),
Hi kyle amazing content It would help me and lots of people if you make video about advanced tables in react like sorting paging filters every app has it
I would not recommend using it if we are using frameworks like React. XState might be useful in some rare scenarios but it is over engineered for most cases. .
I see that XState is very helpful in plain JS. But I use React currently, so should I stick to something like redux or switch to XState for complex state management?
Hello Kyle, Thank you for the amazing videos. I wonder what your thoughts are about next.js for the server+client solution? and/or do you prefer something else?
I like the idea of xstate just like I like the idea of redux, I just hate the implementation. Overly complicated like a lot of these comments have pointed out. Zustand FTW
here is how I would've done this in a much simpler way using OOP concepts; have a class that handles your calls to your back-end APIs with optional retry properties and offers you events you could register to having each event passing you an event object carrying all the helpful information you needed to handle whichever logic you wanted to handle. You could have the error event caller handing you an event object carrying information about the number of attempts it did so far while allowing you to pass a message back to the event caller telling the class to stop retrying or continue retrying after n amount of sleep, or whatever other logic you'd like to have the caller method do next. The problem today is it's very difficult to convince javascript developers to ever attempt learning OOP properly. So they ended up, in 2023, attempting to come about doing something so simple and basic in OOP 20+ years ago in a such a convoluted round-about way. here is a sample of what your error event handler would look like: function onError(ev) { console.log(ev.errorMsg); // do any logic you want (e.g. show msg to user, etc..) if (ev.retries>3) { ev.stopRetry = true; } } and here is how you use the API class const apiCaller = new MyCustomApiCallerClass(); apiCaller.event("error", onError(ev)); apiCaller.Post("your uri goes here", headersObj, postParams, anythingElseYouWant); ^ the above is a sample for onError, you could do the same for success, or any other event in the lifecycle of whatever you're building. Note: you can either implement your own Event class that you can reuse inside other classes (event class is just a class that maintains a list of callbacks for each event name) or use EventEmitter.
While I think something like xstate adds more complexity than it’s worth for 95% of web usecases, OOP has never been the only option in any domain. More functional oriented approaches and languages have been around and widely used since before OOP even existed. Using an OOP approach is fine but in no way superior. There are many examples to be given where a purely OOP approach adds unneeded complexity and strange abstractions that functional languages don’t need.
@@d.sherman8563 at least from his example, it will generate unnecessary complexity for the entire codebase and make the API calling annoying without any benefits from a fast iteration web development perspective. OOP is surprisingly good if everything is set (like a game or something that doesn't require rapidly change) or already gain large amount of prerequires before you even built it because you know how to abstract it in a certain degree without trying to guessing the rest. Ppl claim good engineers can abstract everything well but it's more like a survival bias for me, they abstract well because they abstract terribly before for the similar question. You don't want to be that abstract terribly case anyway if you work on that codebase. But it doesn't mean OOP is bad, we can still get some sort of ideas from OOP and apply them into functional programing or whatever it's to suit the practical needs. Like what XState does. You know why I said that, it's because in one of projects I had worked on, we applies that OOP concept into our api callings similar to the OP claims, it's not bad, but it isn't good either. It generates tons of unnecessarily complexity and lost tons of flexibilities, code is really hard to track after layers of abstractions along with typescript. Ultimately, it doesn't solve the UI state rendering issue without further abstraction, some of the annoying issues that XState can solve for front lib like React. It's far worse than without using OOP at all from the beginning, the abstraction is initially amazing but it will slowly degrade due to complex business needs, that's just how naturally thing evolve, guess what, OOP causes more troubles to do refactor. Like you said eventually, those so called OOP "benefits" in fact do not come with the nature of OOP itself, we can still achieve it with FP, with less complexity and better flexibility, at least in this case.
I like x state but it’s way too verbose. I haven’t used it before but I’d expect no auto suggestions on what options there are and that’s quite inconvenient too
i dont understand whats the point of the libary ,all you are doing is making a simple fetch request and either get an error or something,why do you need state mangent for that thing and why this thing suppose to be better then redux.
I read some comments and I think that people is mixing the concepts.
First: State Machine !== State Management.
Second: You could use both at the same time, no problem.
Let's imagine you have a search input component:
Inside the concept o state machine, the term "state" refers to the current condition of your app, For example
- Search input is empty
- Search input is filled
- Search input is disabled
Each of these state is one of the possible conditions (finite state) that the search input component can have and has nothing to do (directly) with the variable that will store the value atribute of the input or the variable that will store the loading state.
One of the ideas behind using state machine in frontend dev is that you are taking an approach less imperative and more declarative towards the possible state (conditions) of your component may have, that can help you with component testing and avoiding unpredictable situations like infinite loading or unexpected error, for example.
There is a video that is about this libary and explains much better what I tried to mean XD
ua-cam.com/video/wgWwJSnhgDU/v-deo.html
Also recomend reading about finite state machine in game development, that you'll have good insights for front components dev.
Xstate is very useful for handling complicated state. I look forward to your Xstate crash course. Thank you
Thanks Kyle.
Your content really helped me learn web development and get a fulltime job.
Very interesting. I like the way you can visualize the state transitions and simulate them. That's really helpful in understanding the potential paths through the state machine and identifying invalid states and transitions. I often ponder this while writing code. My current practice is to draw a diagram of the state machine before coding it.
I'm studying this concept since 2009. I create a very disrupt method to teach tech and you are one of mt favorites channels in this path. Thank you. I love State Machine, this is Kabbalah !
Man, this was super resourceful! I'd be curious to see an example of xstate and react-query, covering the best practices for some real-world retry behavior. Maybe going into detail of how to inform the user they may not fetch again because a maximum fetch failure limit was reached and you must refresh the page in order to re-attempt the request. This can be useful in preventing users from spamming the retry button
Yeah will love this too
You are genuine content creator.Greatful to have a teacher like.Thank you making such good content.
I think state machines using XState are useful, but must be used and applied carefully, as they can make a simple scenario to be a lot more complex to read and maintain.
Taking the video study case as an example, you can easily achieve the same result by wrapping load, reload and retries in a custom hook and using libraries such as react-query. This will produce a more readable result in fewer lines of code.
I would only use state machine if states don't circle back to only two different ones like in the example, instead, I would use them to represent a more complex workflow.
Yeah, I hate it. Perhaps it’s useful in more complex examples, but this is ultimately just makes code unreadable.
Is it possible to do everything in XState, or are there limitations to what you can do with it?
@@hojdog in my experience I was adding a lot of loginc to a map that becames impossible to maintain. Every time that I need to add login to that was painfull with redux and redux saga. But with xstate all the complex logic was reduced to almust 0.
"If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail."
People tend to blind themselves with these tools. They have something simple they want to do, but they overcomplicate things by using tools that aren't necessary for the job.
If you think this is supposed to be a replacement for react-query then you are missing the point. The point is to implement bespoke logic. XState really shines the more complex the logic becomes, but once you are already familiar with it, there is nothing wrong with using it for simpler logic.
nice niche where it can be used is some business process, or, even better, a game. Something like blackjack could have been taken for example.
Thanks a lot for this video.
One thing though, I think you should warn beginners/juniors that this type of tech should be used for large and complex applications.
You don't hunt with a bazooka.
Once again thanks for all your content!
“The nice thing about x state is it handles all your state and logic in one place”. Heard this many times with 90% of state management libraries (Redux, Mobx…)
yep
That's actually two different states these libraries are managing. The term state is confusing and actually means several different things. The FSM however could be also done via redux and co.
This looks amazing! Definitely would give it a try. Thank you, Kyle 😌
I love XState! Fixing bugs in app transitions is so much easier when all you have to do is rearrange a JS object.
Thanks a lot! I was struggling with xstate. Please do more. A to do app example would be nice.
It's absolutely amazing lab! At my full-time job I use XState to re-write (2 or 3 time) complex custom auto-complete "with whistlers" finally with zero errors and no glitches. Yep, it's not simple as it feels should be, but its works and mountable. Thanks for video.
This tool is pretty awesome! Thanks for demo. Yes the demo fetch scenario would be best handled with Polly or Cockatiel J's libraries, but I got the gist of how x state works and I think it will be great for maintains some workflows that my app uses to guide users over several days. Might even use it in transition some windows workflow foundation workflows.
We most def do appreciate you broski you do a great job breaking things down 💪🏽
Bro, thank you very much for all the content you share, your channel is the best for react and js, this is very interesting, try to take a little course on this.
I'm very interested in that future video on xstate :)
Visualizations for the win!!! Very nice.
Thanks so much
Looking forward for the next video.
How it compares to jotai and zustand?
0:00 - 0:05 I wish life was that simple
need more course about this.
Waiting for the full detailed video on XState. Please make it asap. Thank you ..
Massive respect for react-query now
I have a question, But I don’t know u will understand or not
Qno
If we have eventlistners and we pass args like click and dblclick
Question is how much time its waits for next click if event is for double click…
We have both ‘click’ and ‘dblclick’ on same element
For how much time it will wait for next click if user wants double click
Hope u understand
Thanks
Wie kann man im Kalender in der Wochenansicht (5-Tages-Ansicht) den aktuellen Tag, also die ganze Spalte, highlighten lassen? Früher ging das (z.B. gelber Hintergrund), seit vielen Monaten geht das dummerweise nicht mehr. In deinem Video sehe ich einen dünnen blauen Rahmen um den aktuellen Tag, das wäre ja auch okay. Aber ich finde nirgends eine Option dazu, auch bei den Regeln habe ich nichts Passendes gefunden, außer die abgelaufenen Termine ausgrauen zu lassen, was aber mit sich wiederholenden Terminen nicht funktioniert. Vielen Dank!
Awesome lib, starting use right now
Please do an example with React and, if possible, TanStack Query! That would be awesome!
Sorry but this example seemed so complicated lol. And the “simple” fetch request looked insanely convoluted. Never seen it done like that.
Exactly! Even simple `useState` hooks seems easier than this, imo.
Once you are working with it you'll like it.
@@fyfirman useState is just a stateful value and setter function. Xstate is for configuring complex state machines. It's more like useReducer with an opinionated interface. State libraries like xstate become more important in larger applications.
You wouldn't use a state machine to handle if a button was clicked or not. States machines can simplify complex logic needed for switching between and keeping state in an app. Its another way of saying "I will change into [someState] when [someConditions] are met."
It’s simple to people who have used state management editors before like in Unity 3D and other programs
Is there actually a follow-up video or did we just plug one and it hasn't actually been made?
Hey can you show how to do them in typescript?
I think XState shines in very large projects it will provide a good and clear documentation also but is it worth it on a smaller side projects?
I think so, a state machine can be simple or complex, in the case of a small project we would have simple state machines, and if tomorrow the project grows, scaling the logic of the state machines would be relatively simple and the expected behavior would be clearly defined.
Is it worth using this in conjunction with storybook?
Would love to see a simple example app with XState and the T3 stack.
Hi, I hope you’re doing good. I would be glad if you make whole course on xstate machine
Would you use Xstate with react-query?
Will it work with remix?
Hi, What do you think about Recoil or Jotai ?
Rxjs is where it’s at!
awesome video , could you make a video on offline first with indexedDB with backgound sync to remote ?
thanks kyle, how about implementation in react and use case?
Can you recommend a good global state management library that can be used in nextjs for ssr?
It's literally what's the video about
It's really awesome.
cameback here after 5 months waiting a full tutorial of xstate :)
The last 3 characters of this URL are forming VUE :D
I like how xstate tries to simplify state management with state machines. I am just not sure if it is worth to use for every component. I think it would be better for something like a game that has a lot of complex state management is required.
Please do a recoil example
This looks like a step function, in a cool way.
I'd be happy even it if engineers documented the flow using the editor, even if not using it to generate code.
Hi, how is this better than redux toolkit ?
From what I understand, Redux's actions are triggered by events and X-State's actions are triggered by state changes. So Redux is like "Do this..." and X-State is like "Do this after this...". It focuses on the transitions between states which makes it more powerful.
@@stevebarakat6968 I guess it doesn't integrate very well with ngrx
Can XState used in React Native？
How about using Redux?
This is looks very interesting but I can see this becoming very hard to read in bigger state machines.
I think this (ua-cam.com/video/HfZCcg9_3t8/v-deo.html) is a better first-example to showcase the power of state charts, rather than a contrived fetch.
Here, you see
(1) a clear separation between business logic (state machine) and declarative ui (jsx)
(2) a lot of logic like "can I click this when in xxx state" is no longer required, as the library can infer that from the state machine. The UI side just uses APIs like `can`, as shown in the video.
If you have a crazy amount of `useState` and it is being set all over the place, this is a better alternative, at the expense of having to learn the syntax.
Looks good. But it's hard to understand the code and it's huge. Anyway thanks for the update. 👍
For those that are confused, I found the solution:
1) Don’t use booleans for options with more than two potential states. Use an enum, a class, or a module with exported strings.
2) completely ignore this.
3) Continue using Redux, or if for some inexplicable reason you want to… mobx.
Love your videos and your work, Can you please also make videos on Astro or astro v react or Astro with react
Thanks Kyle for the amazong explanation, can you please add the github repo link for the project.
Hey Kyle,
In the actions you are mutating context and that is something that you should avoid.
You can find it in the docs
Instead of:
increaseRetryNumber: context => (context.retries += 1),
you should do:
increaseRetryNumber: assign({ retries: context => context.retries + 1 }),
Hi kyle amazing content
It would help me and lots of people if you make video about advanced tables in react like sorting paging filters every app has it
The video is missing at 12:03 bro
Do this tutorial with React please!
Nice, state machine comes to js. Been doing this in rails for 15 yrs.
im glad that nobody does care about rails in 2k23 kekw
Video about Zustand please?
This looks like Redux Dev tools, do these two libraries share this state machine concept?
Waiting for application project samples.
Wouldn't it affect performance?
if you use it correctly, no ;)
I would not recommend using it if we are using frameworks like React. XState might be useful in some rare scenarios but it is over engineered for most cases. .
After more than 50 years webdevs adapt technology which actual programmers used for ages )
where is the full tutorial?
I am still working on it as it is quite involved
I see that XState is very helpful in plain JS. But I use React currently, so should I stick to something like redux or switch to XState for complex state management?
You should try zustand.
@@sirsuer6726 is that another state management library?
Yup! Super simple and easy to use. Doesn’t even require wrapping your whole app in a component either, it’s really nice.
Zustand is awesome ( you can also try jotai if your project is small )
Thanks for the suggestion guys! I will definitely try zustand
I want to see it on a real full stack MERN application or something
Take a shot every time kyle says “State”
Hello Kyle, Thank you for the amazing videos. I wonder what your thoughts are about next.js for the server+client solution? and/or do you prefer something else?
Just missed their new docs.
I'm a game developer, and man, states are the pain in making games, specially complex games
It is pretty much like bloc on a smaller scale.
Please loopback 4 mongodb microservices tutorial
Great video, but if you could share the code too, it would be even more amazing, thanks.
I like the idea of xstate just like I like the idea of redux, I just hate the implementation. Overly complicated like a lot of these comments have pointed out. Zustand FTW
here is how I would've done this in a much simpler way using OOP concepts; have a class that handles your calls to your back-end APIs with optional retry properties and offers you events you could register to having each event passing you an event object carrying all the helpful information you needed to handle whichever logic you wanted to handle.
You could have the error event caller handing you an event object carrying information about the number of attempts it did so far while allowing you to pass a message back to the event caller telling the class to stop retrying or continue retrying after n amount of sleep, or whatever other logic you'd like to have the caller method do next.
The problem today is it's very difficult to convince javascript developers to ever attempt learning OOP properly. So they ended up, in 2023, attempting to come about doing something so simple and basic in OOP 20+ years ago in a such a convoluted round-about way.
here is a sample of what your error event handler would look like:
function onError(ev) {
console.log(ev.errorMsg);
// do any logic you want (e.g. show msg to user, etc..)
if (ev.retries>3) {
ev.stopRetry = true;
}
}
and here is how you use the API class
const apiCaller = new MyCustomApiCallerClass();
apiCaller.event("error", onError(ev));
apiCaller.Post("your uri goes here", headersObj, postParams, anythingElseYouWant);
^ the above is a sample for onError, you could do the same for success, or any other event in the lifecycle of whatever you're building.
Note: you can either implement your own Event class that you can reuse inside other classes (event class is just a class that maintains a list of callbacks for each event name) or use EventEmitter.
While I think something like xstate adds more complexity than it’s worth for 95% of web usecases, OOP has never been the only option in any domain. More functional oriented approaches and languages have been around and widely used since before OOP even existed.
Using an OOP approach is fine but in no way superior. There are many examples to be given where a purely OOP approach adds unneeded complexity and strange abstractions that functional languages don’t need.
@@d.sherman8563 at least from his example, it will generate unnecessary complexity for the entire codebase and make the API calling annoying without any benefits from a fast iteration web development perspective. OOP is surprisingly good if everything is set (like a game or something that doesn't require rapidly change) or already gain large amount of prerequires before you even built it because you know how to abstract it in a certain degree without trying to guessing the rest. Ppl claim good engineers can abstract everything well but it's more like a survival bias for me, they abstract well because they abstract terribly before for the similar question. You don't want to be that abstract terribly case anyway if you work on that codebase.
But it doesn't mean OOP is bad, we can still get some sort of ideas from OOP and apply them into functional programing or whatever it's to suit the practical needs. Like what XState does.
You know why I said that, it's because in one of projects I had worked on, we applies that OOP concept into our api callings similar to the OP claims, it's not bad, but it isn't good either. It generates tons of unnecessarily complexity and lost tons of flexibilities, code is really hard to track after layers of abstractions along with typescript. Ultimately, it doesn't solve the UI state rendering issue without further abstraction, some of the annoying issues that XState can solve for front lib like React. It's far worse than without using OOP at all from the beginning, the abstraction is initially amazing but it will slowly degrade due to complex business needs, that's just how naturally thing evolve, guess what, OOP causes more troubles to do refactor.
Like you said eventually, those so called OOP "benefits" in fact do not come with the nature of OOP itself, we can still achieve it with FP, with less complexity and better flexibility, at least in this case.
Let's always do alot of good
I like x state but it’s way too verbose. I haven’t used it before but I’d expect no auto suggestions on what options there are and that’s quite inconvenient too
State management is used on like 1 out of 100 projects. Modern front end devs are nutjobs.
as a 5 years experienced dev, I can say it's extremely complex and it'll be a maintenance nightmare if you centralize all states in a single place
Finite state machine nice to see some game dev concepts to the web world.
Please use Dark Reader browser addon, the last thing we want to do is stare at a pitch white background which is the case in most of your videos.
👍👍
This adds too much complexity for very little in return. A lot of this can be modeled as a reducer instead.
i dont understand whats the point of the libary ,all you are doing is making a simple fetch request and either get an error or something,why do you need state mangent for that thing and why this thing suppose to be better then redux.
Btw in nuxt 3 you don't have to have any library for state management just use useState with composables dir and done 👍🏻
i cant ... after all this time.....
Russell Mews
Far out!
Heloise Key
This video was complicated 😢
Actually, the hardest thing about programming is cache invalidation and naming things.
A library with state machines? Why not use a vanilla factory function.