[oweqruiowe]

Holy, this is the first time I've heard of it, but it sounds really great.

> Instead of using cascading parameters and other ridiculously complex ways of passing state around

So much this! There are too many folks stuck in the 'container' component pattern when really you should never pass a prop that can be queried from state. Working like this results in a sustainable application that's flexible, like you _state_ xD

I'm going to give this a really close look, thank you.

[bob1029]

We found similar frustrations with having state flow with the HTML structure. From a novice perspective I can see how that might seem desirable, especially considering how concise it looks for sample implementations when you are doing 2-way binding.

But, once you get into really complicated scenarios where structurally-unrelated components are statefully-related (e.g. navbar interacts with some component in an entirely unrelated modal), things get very nasty without some common arbiter of state being shared between these components. You can usually solve this in some way with all the SPA frameworks I've worked with, but Blazor is the first case where building these state machines as C# services has knock-on benefits that simply can't be ignored anymore IMO.

Overall, separation of state machines from the UI seems the be the theme, and certain technologies can do this a lot better than others.