Asynchronous action handlers vs. action-reducer-effect-action-reducer - why the difference? about blazor-state HOT 2 OPEN

If you go back in history of the two repositories you will see I started Blazor-State a few days before Pete started Fluxor. We hadn't talked to each other in a while and both thought this concept was the most import thing to build for Blazor. A few days in we chatted. I thought he had seen my repo and was trolling when he said what he was working on. :) We share many of the same philosophies, yet we offer enough differences to hopefully support the community and give valuable options.

Not distinguishing between what Pete calls "effects and reducers" was a specific design decision. I think the developer should be aware of the differences in their handlers but I didn't and still don't think it requires a structural change in the architecture. Handlers work fine for both.

The concern in the thread seems to be about when subscriptions are automatically fired. What Pete calls a bug and what you call a feature, I don't think it is a bug nor a feature. It is a byproduct of how Blazor is implemented.

I do NOT use this by-product to trigger loading spinners. I use a loading middleware to handle all of these things in the UI. ( On my backlog to add this to the TimeWarp Architecture so others can use it. But testing, a basic documentation structure and Auth are in front of that currently).

The automatic firing of the subscription will happen after the handler completes. I guess one could fire these in the middle of a handler but that was not the design intention.

from blazor-state.

I think I agree. Though I appreciate Pete's purity to the flux model, I don't see much benefit to that--it makes the complex things possible but doesn't make the simple things simple.

Now if only I could understand/find/contribute a better approach on #266 I would introduce Blazor-State to my team.

from blazor-state.