95% of this video is about XState and the only time the Effect is used, it is when wrapping one-line code in Effect.sync and immediately running it with Effect.runSync, which is no better than just running the same code directly . I'd wish for a better example that shows where Effect shines. For example a basic error handling and how we can then branch out to a specific error state in XState.
This video is really explaining in a nutshell what a state machine and the actor model are. It is not very clear how Effect could be used in the context of XState and what it would change to the dev experience. It looks like Sandro Maglione is the person to look up for answers.
I think the idea is that both tools are good at modeling different things which happen to be complementary. i.e. if you use XState to model your state machine, you could still make use of something to model computation, or if you use Effect to model computation, you might still want something to help you model a state machine. To use them together, XState is tasked with guaranteeing that the state of your machine is always valid, and Effect is tasked with running the side-effects that occur as a result of transitioning between states. To elaborate on the slide at 27:11 illustrated by an architecture I’ve been hacking on, I’m using Effect-cli as the top-level framework for a CLI tool, and inside certain subcommands, I want to model their logic as a state machine to guarantee a certain dependency graph between different actions. Those actions are then implemented as Effects. The benefit of using XState is that you can visually model these statecharts instead of defining them strictly in code.
@@nickr753 I guess I am used to the idea of having one entry point which is an effect and which is composed of effects, all the way down, but this setup is probably an exception rather than a rule. It just feels natural to me that an effects system is the framework.
I've used this library before and it just kills productivity as it is full of gotchas and pitfalls (not to mention the boilerplate). Worth learning the idea of state machines but really, sum types (or discriminated unions if you prefer) are a more practical way of making illegal states unrepresentable. All the other bells and whistles xstate gives you over and above sum types have a very poor cost/benefit ratio.
95% of this video is about XState and the only time the Effect is used, it is when wrapping one-line code in Effect.sync and immediately running it with Effect.runSync, which is no better than just running the same code directly .
I'd wish for a better example that shows where Effect shines. For example a basic error handling and how we can then branch out to a specific error state in XState.
Effect video , instant like
wao, it's effective
This video is really explaining in a nutshell what a state machine and the actor model are. It is not very clear how Effect could be used in the context of XState and what it would change to the dev experience.
It looks like Sandro Maglione is the person to look up for answers.
Thanks for the heads up
I think the idea is that both tools are good at modeling different things which happen to be complementary. i.e. if you use XState to model your state machine, you could still make use of something to model computation, or if you use Effect to model computation, you might still want something to help you model a state machine. To use them together, XState is tasked with guaranteeing that the state of your machine is always valid, and Effect is tasked with running the side-effects that occur as a result of transitioning between states. To elaborate on the slide at 27:11 illustrated by an architecture I’ve been hacking on, I’m using Effect-cli as the top-level framework for a CLI tool, and inside certain subcommands, I want to model their logic as a state machine to guarantee a certain dependency graph between different actions. Those actions are then implemented as Effects. The benefit of using XState is that you can visually model these statecharts instead of defining them strictly in code.
@@nickr753 I guess I am used to the idea of having one entry point which is an effect and which is composed of effects, all the way down, but this setup is probably an exception rather than a rule. It just feels natural to me that an effects system is the framework.
I've used this library before and it just kills productivity as it is full of gotchas and pitfalls (not to mention the boilerplate). Worth learning the idea of state machines but really, sum types (or discriminated unions if you prefer) are a more practical way of making illegal states unrepresentable. All the other bells and whistles xstate gives you over and above sum types have a very poor cost/benefit ratio.
try w/ ui, its freaky good.