Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Peter Morris
    @mrpmorris
    It's just an unnecessary level of indirection
    Matthias-Claes
    @Matthias-Claes
    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.
    Peter Morris
    @mrpmorris
    Why do you need multiple actions?
    Matthias-Claes
    @Matthias-Claes
    When I was doing something that would affect multiple states I would fire an action for both states. But now I'm changing that to use a recudermethod per state in stead. So I don't anymore
    Peter Morris
    @mrpmorris
    My advice is to have a single namespace with most of your actions in
    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)
    Matthias-Claes
    @Matthias-Claes
    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?
    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();
                });
    }
    Peter Morris
    @mrpmorris

    New [ComponentParameter] request

    dotnet/aspnetcore#29379
    Vote it up if you want it
    Haytam Zanid
    @zHaytam
    @mrpmorris How do you handle form submissions?
    Do you put in the state the model and then disable the submit button?
    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?
    Peter Morris
    @mrpmorris
    The object you edited can go into the action to be posted off to the server
    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
    But I have the BusySpinner wrap the inputs on the page itself, not in a master layout or something
    Peter Morris
    @mrpmorris
    You could choose to do that instead if you wish
    Haytam Zanid
    @zHaytam
    Thanks!
    Peter Morris
    @mrpmorris
    Yw
    Maxim Crabbé
    @MaximCrabbe
    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 :)
    Haytam Zanid
    @zHaytam
    Literally thinking of the same problem
    And also used the same solution (SubscribeToAction)
    If there is a cleaner approach, I'll happily take it!
    Maxim Crabbé
    @MaximCrabbe
    I hope so, because 'we are not reading the state now', we are 'reading actions payload' :)
    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 :)
    Peter Morris
    @mrpmorris
    The server can return you an editable object in the API response.
    That is dispatched by the effect.
    The SubscribeToAction in the form simple sets MyModelToEdit = Action.Customer
    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
    Ordinarily you'd take the DTO from the API, reduce its values into state, and then the form would make a copy of that state into a mutable object
    but that's a lot of work
    Peter Morris
    @mrpmorris
    The other way I have seen it done is the form calls the API itself
    I'm not so keen on that
    Maxim Crabbé
    @MaximCrabbe

    Ordinarily you'd take the DTO from the API, reduce its values into state, and then the form would make a copy of that state into a mutable object

    The first part I understand, reducing the values into the state, but how do I make a copy of the state into a mutable object in the component?

    Peter Morris
    @mrpmorris
    AutoMapper would be one way, but I wouldn't store the object I at all
    Either do the api calls in your app and only reduce results, or ( I recommend) use the action subscriber to grab the mutable DTO from the server and don't let it go into state
    Alexander Gnauck
    @agnauck
    just found this channel after I posted a new issue with a question here:
    mrpmorris/Fluxor#157
    Peter Morris
    @mrpmorris
    Are you saying you are updating the state but the UI isn't updating? I didn't quite understand the end
    Alexander Gnauck
    @agnauck

    assume I have a state with with a huge array of trades (1000+). The UI is build out of many Fluxorcomponents. All of those components show lists which are build from subsets of the state array.
    eg:

    • List of trades for Apple stock
    • List of trades for Microsoft stock

    When I insert a new trades to the array in the state for performance reasons only affected components should be updated.
    Or is this nothing I should be concerned about?

    My assumption is that FluxorComponent calls StateHasChanged in any coponent, also when the add or insert does not affect this component. But I can be wrong. Still studying the code. My concern would be performance in a high traffic realtime application
    Peter Morris
    @mrpmorris
    When you subscribe to state X then your component will re-render whenever that state changes regardless of which part changes