I will give you an example
App.razor.cs
And in one component I need to get some state-based properties in the back code (for example SelectLanguage.razor.cs)
I subscribe to the action which holds the new theme, change my fields in the component and call StateHasChanged()
Is that normal?
Actually, navigating to another page seems to reload the whole page
Nevermind, it does that when the page doesn't exist
I'm currently trying to pull all my action related stuff into a StateFacade but I ran into a problem where my component needs to wait for data to load. I'm currently using SubscribeToAction to wait for my success actions but I'm wondering if there is a way to also pull this into the StateFacade.
I need my results to fill the model for my EditContext in my component.
Anyone got any ideas for this?
@Matthias-Claes Why do you need a state-facade instead of working with state?
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?