I was following this blog post: https://betweentwobrackets.dev/posts/2020/06/state-management-with-blazor-using-fluxor-part-1/
I followed the idea of dispatching the actions in the facade to keep the code more readable and I sometimes need an action in a component to also affect the state of its parent component so using the StateFacade I can just call actions for both compents in those methods
I followed the idea of dispatching the actions in the facade to keep the code more readable and I sometimes need an action in a component to also affect the state of its parent component so using the StateFacade I can just call actions for both compents in those methods
Put all your actions in one folder, have multiple states affected by them via reducers
Put actions in sub-folders when they are only for editing some local state in the UI that can't possibly affect state elsewhere
I didn't like the facade extension of the pattern
It doesn't store state, does it?
Why not dispatch the action?
It's just an unnecessary level of indirection
At this moment it doesn't offer much benifit other than that I also use the facade for my autocomplete http calls for example. It also allows me to dispatch multiple actions while the component doesn't need to know that but as you already pointed out I can solve this by a reducer listening to those actions.
If you think of your state as committed state then anything that updates them should be in an action that multiple states reduce from
So put them in a common namespace
In some circumstances you might need state that is only for a specific use-case (e.g. a specific bit of user interface), in which case I would put those actions in the namespace for that use case
(that feature)
Thanks for all the info, Peter. I'm working on implemening your suggested method as much as possible.
Another question I have though.. Is there a way to clean up this?
Another question I have though.. Is there a way to clean up this?
protected override async Task OnInitializedAsync()
{
SubscribeToAction<FetchSuccessAction1>(async action =>
{
formModel = action.entity with { };
StateHasChanged();
});
SubscribeToAction<CreateSuccessAction2>(async action =>
{
formModel = action.entity with { };
StateHasChanged();
});
SubscribeToAction<UpdateSuccessAction3>(action =>
{
formModel = action.entity with { };
StateHasChanged();
});
}
Vote it up if you want it
I want to disable the submit button in all forms, but I'm thinking I'll need to add the models to the state too so that the field values aren't lost if the submissions fails for some reason
Is that the right way?
The action UpdatePersonAction (for example) has a reducer that sets IsBusy in the state to true, perhaps have a BusyDescription = "Saving"
And when the effect that calls the server finishes you set IsBusy to false
My <BusySpinner> component is bound to the state.IsBusy
<fieldset class="xo-busy-spinner_container @Class" disabled=@IsBusy>
@ChildContent
@if (IsBusy)
{
<div class="xo-busy-spinner_obscurer">
<span class="xo-busy-spinner_spinner"></span>
</div>
}
</fieldset>
I put the content inside a fieldset because when you set
disabled=true it also disables all controls inside it, buttons, inputs, everything
So the user can't use the keyboard to modify stuff
So you could set IsBusy=true BusyDescription="Fetching data" when loading
IsBusy=True BusyDescription="Saving data" when saving
IsBusy=True BusyDescription="Saving data" when saving
But I have the BusySpinner wrap the inputs on the page itself, not in a master layout or something
Given: GetDataAction -> Effect does http call -> await Http result, dispatches action GetDataActionCompleted with payload of the data -> reducer writes Data to the state as initial data. Question: How do I properly put the data in an editform. What we try right now: In the OnInitializedAsync of the component, SubscribeToAction to the GetDataActionCompleted. Get the payload and make a copy of it and pass the copy to the model of the form. But this seems dirty that you need to use SubscribeToAction whenever you want to work with a editform. In real life we also have many more Actions to subscribe that we need to 'watch' that can change the payload. Hope someone has a proper solution for this :)
And also used the same solution (SubscribeToAction)
If there is a cleaner approach, I'll happily take it!
if someone adds a new action to modify the form for example with a new button that launches an action he has to remember to add the actionsubscribe as well it is a smell :)
Then you can edit it in the form, it doesn't go into state
Now, you can also reduce the values of
Action.Customer into state if there are multiple pieces of state holding customer information so that, for example, fetching a Customer from the server with a name that has been updated will update existing state
But your state is readonly
SubscribeToAction is a shortcut