Feel the same about Svelte stores. They’re conceptually very similar when you extract as classes. But there’s no need for selectors, and direct state setting is possible
I picked up RXJS from Angular and brought it to React. Then realized I was using a fraction of RXJS and could do with a tiny implementation, so I published one myself. I've been using it for years in prod with no issues. No more chasing trends for me.
i know its not the same but thats why i love signals. In svelte i can just create a signal anywhere and make "helper functions"/actions In svelte specifically i can also just make a Class that has methods instead of actions it feels a lot easier to get these patterns right without needing a state library
If you already use any of state manager, just keep it. Don't mixed up or refactor your code. Unless you create new project. I mean, in the future will be another state manager born.
When Theo started a speech about URL query parameters, I thought the framework would have a way to combine local state and query strings. Anyway, it’s good that we have something new. Thanks Theo!
Heck yeah! I ran into David K Piano's first talk about XState years ago while looking for state machine content. I use it with Svelte for heavy UI logic.
New store again... My opinion is not popular, but rxjs in angular has solved all of these store problems many years ago out of the box, but the only problem is that it is difficult to learn for the majority. However, React is a super popular framework, why just can't anyone figure out a versatile solution that just works, but still we have "store" and the functions to update it, but just different syntax. The approach remains the same. This is the biggest problem imo.
The approach here is NOT the same as with the majority of state management solutions. It provides some math-grade guarantees about the correctness of the program. Not necessary for every case, just as rxjs is an overkill in many cases. No one can figure out a versatile solution because one probably doesn't exist :)
but that's a good thing, that's entirely the point - he's adding useful comments and pointers. If you don't find his commentary useful then why are you subscribed...
@@witchmorrow The format used to be shorter, now it feels like the viewer is being strung along just to always hit that 30 minute video mark or close to there.
Pinia's far superior. Having to use React hooks + other data somewhere else so I can finally use it in my stores with `useEffect` to initialize state is frustrating. This means you have to do a full initial render before initializing that state for the follow-up render.
A couple years ago I wrote a really tiny (invisible in build maps) hook and did away with actions, reducers, stores and other assorted unnecessary patterns. My code became much smaller and readable. I added debugging tools and I'm in the process of fully transitioning to TS to enforce whatever types you want your state to have. The code to use it is just a couple lines. You just call the hook and get on with your life. Now every time I see these convoluted schemes, I chuckle.
@@docmars usually, you don't need to. The re-renders would result in the same virtual DOM. Computing virtual DOM is not as expensive as updating the DOM. If you still want to get rid of unnecessary re-renders, you need to use pure components and wrap them with "memo". Using "memo" the, component will usually not be re-rendered when its parent component is re-rendered as long as its props have not changed.
Huge fan of tagged unions and as such i'll always lean towards apis, with a single mutating action, such as `send(action)` in this case, vs having N mutating actions (with some being deprecated, others being replacements, and so on). Xstate also works nicely with restate.
This is a mess compared to using Atoms in a library like Jotai or Nanostores. I use Nanostores because it is framework agnostic and the Astro team recommends it and you can use it between islands. Transitions are just simple exportable functions. State objects are whatever you want. Works with TS flawlessly.
@zocky3282 My projects are of medium size, webs and management applications for my company, and it works very well for me. If the functionalities it brings serve you (which is what you need for status management) it's great.
@@zocky3282 In my case, I have done medium-sized projects: websites or management applications for my company. Recently I've been simplifying a lot my application architectures, because in the javascript world I think we have made the mistake of using a lot of code to do the same thing. In this aspect, nanostores gives me what I need to manage state and separate the view from the application domain and for me it has been enough and it works well in MPA applications (I have stopped doing SPA's for the same reason, to simplify developments and get as close as possible to the web standards). Anyway, it's just my approach, you should choose the one you feel more comfortable with for your situation.
The only thing better than xstate store is xstate itself. Once you got the hang of actor communication and app visualization, you never want to go back
I'd say the solidjs store is even much more beautiful, just simply creating the store with initial states in a file, define functions to get and set as you wish, export them and it just works 😂
FYI you can infer a key’s existence in the same object. Both Stiches and my library TW Classed rely on this. But it’s like you say HELLL to infer those types.
I really avoid using state managers in my projects, but i understand the scenario of them. Xstate looks really good, if i have a chance to use ill give it a go
@versaleyoutubevanced8647 but the function is called once the component unmounts... or are you saying... unmount, calls return function, BUT only calls useMemo function if dependencies have changed?
A state machine is a modelling paradigm that explicitly describes the states of an application and the transitions between those states. There is an ambiguity of the word state in React and state in a State Machine. State is the condition an app is in. It could be Loading, Idle, Saving etc. An application that is in state Loading cannot transition to the state Saving for example. By modelling the states of an application you cannot land in a bad state, avoiding logical bugs. in xState the react "state" is the context object, so that's where your react "state" is.
Among equally clever and stupid things I've done is having the entire state managed with rxjs and encoded and compressed as a url to make whatever application state book.arkable and shareable so long as the user is authorised
I love xstate for app startup flows and complex state flows but I limit it to those cases. Zustand is amazing in react projects. I have yet to need something like zustand in svelte.
Yeah tbh I don't actually get the appeal of a store. Is it that people want to feel less bad about using global variables? Or is it that you want a standardized interface for update event propagation? In case it's the latter, you could just have a file where some globals are declared, as well as some functions to update/listen.
@@Simon-ir6mq I have an Excel like application that receives notifications for validation or actions from other users and without a State Machine (like the xState) it is a nightmare to handle with some global parameters. The application needs to respond (or not) based on the users input, the condition the application is in (maybe saving/calculating or loading). The difference of xState is that you model the states (the conditions) your component can be in and the transitions that are allowed from each condition (called state). If you don't do that, then the states of your application are implied in the code and in the head of the developer. So I agree that React state is 100% good for 95%, but for complex modelling of an application I would go with xState to explicitly describe all the conditions and transitions that can happen.
@@Simon-ir6mq A simple appeal is the helpers that come with the store, subscribing to a global on react in order to make it act when mutated requires a bit of a boilerplate another one is the probability of your build tool messing with you, does not happen that often these days but oh boy..... some time ago it did a lot haha. Finally, on larger teams is usually easier to train people about the global state when it is structured with a well known and popular solution instead of an inhouse one. but you are right about it being possible using globals, it is just move inconvenient
This is interesting, because it contradicts the VUE documentation, which clearly and lucidly indicates when you can rely on a simple state and when you should use the official state management library - Pinia. How about rethinking your silence? Since anyone with access to the comments section can also fire up the documentation and see how much you're spouting foolishness?
I really like this mentality of separating things from React, that's why I'm still fond of redux. I don't like this trend of coupling everything to react, now we're even coupling to remix/next. It reminds me of jQuery solutions which barely used any functionality of jQuery but still required that dependency. I want my code to be portable but also to outlive trends. If I'm deeply coupled to something that is likely to change, I'll have to change it for reasons other than it needing to change.
@MadsterV Not sure if this is a serious question or just bait, but I am inclined to answer anyway. Things like virtual/infinite scrolling with server-side fetching is a must for handling large datasets. If you’ve worked with serious data sizes and new to display all that info FAST and without crashing the browser, while still be able to query/filter data and do pagination, you’d know performance isn’t about making it look pretty. Check the docs. 'Pretty' CSS tables there are dime a dozen, but I take your meaning, for trivial stuff CSS implementation is fine
Valtio is an overlooked state manager that would simplify that agora zustand entanglement. People seem to avoid it because it's so simple. That's why I like it though.
Its buggy for computed values, I spend days replacing mobx with it on a new rework on job project only to be needing to replace it again because it fucking sucked with bugs
Would not it be clearer in react if you just made an utility, like: function effect({ deps, run, cleanup }: { deps: any[], run: () -> void, cleanup: () -> void }) { useEffect(() => { run(); return cleanup; }, deps); } that you can then use like this: effect({ deps: [slug], run: () => { ... }, cleanup: () => { ... } }) I feel like at least some of the problems with useEffect is that it is too much quirky to use, so wrapping it maybe provide some benefits.
@@requindr My whole point is that it does provide benefits (semantic ones), lol. And if someone gets confused by this I don't think this person is a programmer, those are literally plain english words with well defined meanings in react, I'm not presenting a theorem proof in modal logic.
Why is the FE world like this? Why do we need a new framework, state manager, editor, runtime, additional languages on top with build steps nonsense every single day? In the backend world languages has left these trivialities behind and for example go, c#, php, java communities are not into this at all . They focus on the things that matter which means we have a stable environment with mature tooling
The Java community is just as guilty of making things way more complex than they have any right to be (how many competing build systems are we up to now? 5?). The issue doesn't stem from any one language or language ecosystem, but rather comes from a culture hyper-focused on delivering new features to the detriment of virtually everything else. Naturally the low barrier to entry, poor standard library, and so on likely are contributing factors, but I don't think they're the primary ones.
Just one more state manager guys and all will be good.
bruh just one more state mamager bruh I promise bruh this is the last one bruh
just one more, c'mon
Just waiting for a state manager to become a framework similar to how react router became a framework
the next one will be the best!
Effector is way ahead of Zustand. Give it a try.
Now we need a state manager to keep track of all these state managers.
Why don't we call state managers governors?
State Comptroller?
Mayors. Most countries don't have governors separately but every country has mayors.
Looks like there's already a state manager called @techempower/react-governor
Trust me guys react is one state manager away from perfection
I don't know why I find this funny
zustand is always gonna be my go to
me too 👍
Jotai
Pinia is great for vue
@@philheathslegalteam Jotai is my ex, zustand now, You should learn zustand
@@philheathslegalteam meh, too complicated for me when it came to typing
JavaScript libraries are like fashion items. They go out of fashion the moment you invest in them.
Also, a lot of them become more popular because they are already popular. It's very much fashion.
man all of this is so easy in solidjs, this vid makes me appreciate it even more
This
Feel the same about Svelte stores. They’re conceptually very similar when you extract as classes. But there’s no need for selectors, and direct state setting is possible
I picked up RXJS from Angular and brought it to React. Then realized I was using a fraction of RXJS and could do with a tiny implementation, so I published one myself.
I've been using it for years in prod with no issues. No more chasing trends for me.
Great ad by the way, happy you’re promoting interesting companies!
Thank god you made that call at 19:51 I was about to be really frustrated.
I usually enjoy your videos as a background task but this had my full attention. Saved to watch again 👍🏼
i know its not the same but thats why i love signals.
In svelte i can just create a signal anywhere and make "helper functions"/actions
In svelte specifically i can also just make a Class that has methods instead of actions
it feels a lot easier to get these patterns right without needing a state library
If you already use any of state manager, just keep it. Don't mixed up or refactor your code. Unless you create new project. I mean, in the future will be another state manager born.
When Theo started a speech about URL query parameters, I thought the framework would have a way to combine local state and query strings. Anyway, it’s good that we have something new. Thanks Theo!
Have you looked at nuqs for this? (I'm the author)
Heck yeah! I ran into David K Piano's first talk about XState years ago while looking for state machine content. I use it with Svelte for heavy UI logic.
New store again... My opinion is not popular, but rxjs in angular has solved all of these store problems many years ago out of the box, but the only problem is that it is difficult to learn for the majority. However, React is a super popular framework, why just can't anyone figure out a versatile solution that just works, but still we have "store" and the functions to update it, but just different syntax. The approach remains the same. This is the biggest problem imo.
True, angular is really good in this regard. And now, for non-complex problems, it is possible to use signals instead. ❤
Better than being forced to used a single opinionated option or writing own. What have you done for the community?
I love injectable services in Angular
I'm a React dev and am eager to learn Angular
I just need to have discipline cuz I've heard its difficult at the start but lovely later
The approach here is NOT the same as with the majority of state management solutions. It provides some math-grade guarantees about the correctness of the program. Not necessary for every case, just as rxjs is an overkill in many cases. No one can figure out a versatile solution because one probably doesn't exist :)
They will do everything to not use signals )))
Are state managers the new front end framework meta?
As a few of the comments already mentioned just use signals, legend-state in React and the other frameworks have signals built-in
For a 4 mins read blog post it took 22 mins youtube video
At this point I think he does it to ensure the ragebait posts and clicks
but that's a good thing, that's entirely the point - he's adding useful comments and pointers. If you don't find his commentary useful then why are you subscribed...
@@witchmorrow The format used to be shorter, now it feels like the viewer is being strung along just to always hit that 30 minute video mark or close to there.
Brother just read the article if you don't like the commentary, because that's like the whole point of this channel
@javierflores09 K
TLDR: Basically Pinia
Pinia's far superior. Having to use React hooks + other data somewhere else so I can finally use it in my stores with `useEffect` to initialize state is frustrating. This means you have to do a full initial render before initializing that state for the follow-up render.
@@docmars 100% agree. I'm watching this and being reminded why I felt Vue felt so much better when it came to state management.
Basically vuex, Pinia looks already more advanced. Although this is a stand alone package
Pinia is not a state machine, so basically nope.
@@robertg.3331 not is xstate- store
A couple years ago I wrote a really tiny (invisible in build maps) hook and did away with actions, reducers, stores and other assorted unnecessary patterns. My code became much smaller and readable.
I added debugging tools and I'm in the process of fully transitioning to TS to enforce whatever types you want your state to have.
The code to use it is just a couple lines. You just call the hook and get on with your life. Now every time I see these convoluted schemes, I chuckle.
can you provide the source?
I found jotai before the popular “zustand” and never learned another
react context + our own state machine for life
useContext + useReducer is all you need
What do you do to avoid wasteful re-renders every time your Context state changes?
@@docmars there is tricks, but its not worth tbfh. If you reach that point just use zustand
@@docmars usually, you don't need to. The re-renders would result in the same virtual DOM. Computing virtual DOM is not as expensive as updating the DOM. If you still want to get rid of unnecessary re-renders, you need to use pure components and wrap them with "memo". Using "memo" the, component will usually not be re-rendered when its parent component is re-rendered as long as its props have not changed.
I will never leave zustand ❤❤❤
Effector (and ecosystem) is the best for me in most cases
Huge fan of tagged unions and as such i'll always lean towards apis, with a single mutating action, such as `send(action)` in this case, vs having N mutating actions (with some being deprecated, others being replacements, and so on).
Xstate also works nicely with restate.
xstate is actually amazing if you engineered it right you can easily transfer your logic to other frameworks
This is a mess compared to using Atoms in a library like Jotai or Nanostores.
I use Nanostores because it is framework agnostic and the Astro team recommends it and you can use it between islands.
Transitions are just simple exportable functions. State objects are whatever you want. Works with TS flawlessly.
Yeah I was thinking the same..... it feels way easier to just.... use signals/atoms.
But hey.... you get "free" state machines
Very interesting... Thanks. I will try it. You should also try nanostores, from Evil Martians, super lightweight and framework independent store.
Does it work on large projects, I saw RHF recommending it for multi step form
@zocky3282 My projects are of medium size, webs and management applications for my company, and it works very well for me. If the functionalities it brings serve you (which is what you need for status management) it's great.
@@zocky3282 In my case, I have done medium-sized projects: websites or management applications for my company. Recently I've been simplifying a lot my application architectures, because in the javascript world I think we have made the mistake of using a lot of code to do the same thing. In this aspect, nanostores gives me what I need to manage state and separate the view from the application domain and for me it has been enough and it works well in MPA applications (I have stopped doing SPA's for the same reason, to simplify developments and get as close as possible to the web standards).
Anyway, it's just my approach, you should choose the one you feel more comfortable with for your situation.
*preact-signals* my favorite one
The only thing better than xstate store is xstate itself. Once you got the hang of actor communication and app visualization, you never want to go back
I'd say the solidjs store is even much more beautiful, just simply creating the store with initial states in a file, define functions to get and set as you wish, export them and it just works 😂
FYI you can infer a key’s existence in the same object. Both Stiches and my library TW Classed rely on this. But it’s like you say HELLL to infer those types.
My go to will be Akita/Elf for angular and react, by the way it supports both.
A state machine so smart, it got its PHD.
I believe it is easy to implement an event driven state mngt based on the Dom 😅 I don t say it should be like this but it just work.
Writing a supported, modular, and large-scale solution on zustand is a pain. the library was not appealing.
by best state manager is `emittor`
My favorite state manager is Phoenix Liveview - mainly because I don’t have to deal with state.
For bigger projects it's a better option but for small projects, zustand is unbeatable.
I really avoid using state managers in my projects, but i understand the scenario of them. Xstate looks really good, if i have a chance to use ill give it a go
What would a useMemo with cleanup function do?
evaluate once variables that cause external effects
@versaleyoutubevanced8647 but the function is called once the component unmounts... or are you saying... unmount, calls return function, BUT only calls useMemo function if dependencies have changed?
Which mac are you using?
I don't know why not that many people talk's about Valtio, It makes state management super easy.
The state of the art from what I see
i guess I'll stick with redux (heavy state management) and zustand (for small medium projects) for state management
How does it compare to Pinia?
Does this mean if i want to persist my state, i have to convert it to a state machine first?
A state machine is a modelling paradigm that explicitly describes the states of an application and the transitions between those states.
There is an ambiguity of the word state in React and state in a State Machine.
State is the condition an app is in. It could be Loading, Idle, Saving etc. An application that is in state Loading cannot transition to the state Saving for example.
By modelling the states of an application you cannot land in a bad state, avoiding logical bugs.
in xState the react "state" is the context object, so that's where your react "state" is.
Still using DI + RxJS...
Remind me why we not just use rxjs everywhere like in Angular?
Pinia ❤
lol
I wonder how other ecosystems survive with a single state management tool 👀😂
@@TheAlexLichter I know, right? We need 20 different solutions, learning a new one every time you switch jobs,
Among equally clever and stupid things I've done is having the entire state managed with rxjs and encoded and compressed as a url to make whatever application state book.arkable and shareable so long as the user is authorised
oh god!
In case it wasn't obvious, there is a limit to how urls can be, so it is not a great idea to attempt putting encoded state
That MF drop was personal 😂
I love xstate for app startup flows and complex state flows but I limit it to those cases. Zustand is amazing in react projects. I have yet to need something like zustand in svelte.
Another week, another react state management library
99% of the time you dont need a store, dont thank me
Yeah tbh I don't actually get the appeal of a store. Is it that people want to feel less bad about using global variables? Or is it that you want a standardized interface for update event propagation? In case it's the latter, you could just have a file where some globals are declared, as well as some functions to update/listen.
@@Simon-ir6mq "functions to update/listen" - you mean, like 'useState' for listening and the returned setter for updating?
@@Simon-ir6mq I have an Excel like application that receives notifications for validation or actions from other users and without a State Machine (like the xState) it is a nightmare to handle with some global parameters.
The application needs to respond (or not) based on the users input, the condition the application is in (maybe saving/calculating or loading).
The difference of xState is that you model the states (the conditions) your component can be in and the transitions that are allowed from each condition (called state).
If you don't do that, then the states of your application are implied in the code and in the head of the developer.
So I agree that React state is 100% good for 95%, but for complex modelling of an application I would go with xState to explicitly describe all the conditions and transitions that can happen.
@@Simon-ir6mq A simple appeal is the helpers that come with the store, subscribing to a global on react in order to make it act when mutated requires a bit of a boilerplate
another one is the probability of your build tool messing with you, does not happen that often these days but oh boy..... some time ago it did a lot haha.
Finally, on larger teams is usually easier to train people about the global state when it is structured with a well known and popular solution instead of an inhouse one.
but you are right about it being possible using globals, it is just move inconvenient
This is Pinia for React. And Pinia is just great.
pretty much everything i have is in redux.
So many slices...
Maybe in future on a new project i'd try this. It looks REALLY clean.
The type inferring is what could make me switch to this
writing explicit types for a zustand store is soo annoying, so this looks like a good alternative
Why is no one talking about signals? Like preact-singnals, it's really damn good for small to medium state management
different mental models
Effector! Is really good
We need state manager manager.
The only thing I don't like about this in 10:12 is that you can not rename the transitions project-wide.
That Leo meme from once upon a tim e a hollywood, poining on a TV and titled: Tha'ts PINIA, that's pinia for React
As a VUE developer, since Composition API + Composables we dont need store libraries anymore.
And in case we need Pinia is the best!! 🫡
This is interesting, because it contradicts the VUE documentation, which clearly and lucidly indicates when you can rely on a simple state and when you should use the official state management library - Pinia. How about rethinking your silence? Since anyone with access to the comments section can also fire up the documentation and see how much you're spouting foolishness?
@@coder_one Not my problem if my comment offended someone.
@@jntaca offended? It turns out that reading with understanding is not your strong point....
@@coder_one keep trolling, anomymous abject.
react-observing is the best.
Again a problem you would not have if you would not diff a change twice in react. Just drop setState and redraw the whole thing.
Effector realy cool. Try this!
I agree with AG-Grid 100%
the blind favoritism and non-sequiturs in these comments is amazing
Have you seen ombistac zedux?
That's what you said last week.
Been using it for 3 years in a project, it's good for things but I wouldn't recommend it for general state management
Thanks, you saved me 22 minutes of my life
xstate-store is not 3 years old and is very different from traditional xstate
@@t3dotgg my bad, I thought this was just xState library that David created.
@@t3dotgg he should have called it another name as a new library
@@jatiquep5543 What, like XStore? Or my suggestion, Store Manager For People That Like How XState Works.
How about performance? I feel like going back to the cavern age if the state manager is not fixing React truly reactiveness in an easy and elegant way
Please why does not react have something like pinia and setup stores ?
Those are awesome
Theo has bless us with a 23 minutes video and not 3hrs, thank goog.
state managers never seem to fix my internal state :(
components ads are my shit now
I'm on Legend State and don't see a reason o change
It often looks like react community takes a year to process advancement of the vue community
sticking with zustand
I really like this mentality of separating things from React, that's why I'm still fond of redux. I don't like this trend of coupling everything to react, now we're even coupling to remix/next. It reminds me of jQuery solutions which barely used any functionality of jQuery but still required that dependency. I want my code to be portable but also to outlive trends. If I'm deeply coupled to something that is likely to change, I'll have to change it for reasons other than it needing to change.
Just waiting for a state manager to become a js framework similar to how react router
Ag grid is awesome. It used in Dell
why use a grid library when we have CSS grids?
@MadsterV Not sure if this is a serious question or just bait, but I am inclined to answer anyway. Things like virtual/infinite scrolling with server-side fetching is a must for handling large datasets. If you’ve worked with serious data sizes and new to display all that info FAST and without crashing the browser, while still be able to query/filter data and do pagination, you’d know performance isn’t about making it look pretty. Check the docs. 'Pretty' CSS tables there are dime a dozen, but I take your meaning, for trivial stuff CSS implementation is fine
Try effector. It’s so good to write logic there.
I gave up on state management since server components
Valtio is an overlooked state manager that would simplify that agora zustand entanglement. People seem to avoid it because it's so simple. That's why I like it though.
Recently discovered it working on a react native project and I think I will start using it in everything,react or vue or vanilla
Its buggy for computed values, I spend days replacing mobx with it on a new rework on job project only to be needing to replace it again because it fucking sucked with bugs
For me valtio is more verbose
Would not it be clearer in react if you just made an utility, like:
function effect({ deps, run, cleanup }: { deps: any[], run: () -> void, cleanup: () -> void }) {
useEffect(() => {
run();
return cleanup;
}, deps);
}
that you can then use like this:
effect({
deps: [slug],
run: () => {
...
},
cleanup: () => {
...
}
})
I feel like at least some of the problems with useEffect is that it is too much quirky to use, so wrapping it maybe provide some benefits.
I feel like you shouldn’t do a wrapper that doesn’t provide benefits, at best it will only confuse other devs
@@requindr
My whole point is that it does provide benefits (semantic ones), lol. And if someone gets confused by this I don't think this person is a programmer, those are literally plain english words with well defined meanings in react, I'm not presenting a theorem proof in modal logic.
Just use signals, and make services like angular
Zustand sounds German (translates to status) and as such you should propably pronounce it more like tsustant.
it's more like [tsu-shtant] but Theo already mentioned that he doesn't care
Unpopular opinion: I think MobX is the most complete and unverbose (and easier to hop in) state managment library.
Based.
stores popping out more often than js frameworks (well technically they are js frameworks too but still)
Is it crazy if I like valtio
not good
state management considered harmful
Why is the FE world like this? Why do we need a new framework, state manager, editor, runtime, additional languages on top with build steps nonsense every single day? In the backend world languages has left these trivialities behind and for example go, c#, php, java communities are not into this at all . They focus on the things that matter which means we have a stable environment with mature tooling
The Java community is just as guilty of making things way more complex than they have any right to be (how many competing build systems are we up to now? 5?). The issue doesn't stem from any one language or language ecosystem, but rather comes from a culture hyper-focused on delivering new features to the detriment of virtually everything else.
Naturally the low barrier to entry, poor standard library, and so on likely are contributing factors, but I don't think they're the primary ones.
Hypermedia as the engine of application state (HATEOAS)
xstate realized how unusable their api is, so instead they copied every other state management library. Love it!
13:00 no idea what he's saying like nothing 😅
yeah, fuck the airbnb rules... those got me crazy