Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Maxim Crabbé
    @MaximCrabbe
    @zHaytam I think you are right about the autocomplete data not being put in the state, the only thing I 'dislike' about it, is that he ll be putting HTTP call logic in the component or a service, while mostly 80% of other HTTP calls will be started in effects (or they should maybe the http calls should also be put in services I assume and not directly in effects :)? )
    Haytam Zanid
    @zHaytam
    I feel like that's fine, having a few http calls in some specific components for specific things that aren't related to the state is okay
    Peter Morris
    @mrpmorris
    If you aren't going to have another UI then it's not really a problem
    If you are going to have a Blazor UI and a XAML UI then I'd put all behaviour in the store
    Borislav Nikolov
    @Sesi0

    hey @mrpmorris,

    I have a problem when adding Fluxor to a Blazor WASM project.

    image.png
    Borislav Nikolov
    @Sesi0
    Downgraded to 5.0.0 and it seems to be ok.
    Borislav Nikolov
    @Sesi0
    @mrpmorris is there a way to call actions before other components are init?
    Borislav Nikolov
    @Sesi0
    Nevermind I just found SubscribeToAction which worked perfectly for my usage.
    Borislav Nikolov
    @Sesi0
    I think it should be documented in the Blazor docs it is pretty good feature.
    Peter Morris
    @mrpmorris
    @Sesi0 Was it Blazor 5.1 that had this problem, but it worked in 5.0?
    Borislav Nikolov
    @Sesi0
    @mrpmorris I tried again to update it and it works maybe it was due to LiveSharp package. But the strange thing is it worked with LiveSharp when Fluxor was not implemented. I will just continue without hot reload.
    Peter Morris
    @mrpmorris
    LiveSharp can cause those kinds of probles
    Haytam Zanid
    @zHaytam
    @mrpmorris How would I go about extracting user info from local storage back into the state when visiting the app again?
    Borislav Nikolov
    @Sesi0
    @zHaytam for example you store the culture in local storage and on visiting the app you want to load the language based on this culture?
    Haytam Zanid
    @zHaytam
    yes
    Borislav Nikolov
    @Sesi0
    I initialize the store in App.razor.cs and after this, I dispatch the actions to initialize the store. (LoadThemeAction, LoadCultureAction and etc.)
    I will give you an example
    image.png
    App.razor.cs
    And in one component I need to get some state-based properties in the back code (for example SelectLanguage.razor.cs)
    image.png
    I subscribe to the action which holds the new theme, change my fields in the component and call StateHasChanged()
    Haytam Zanid
    @zHaytam
    Oh, got it, thank you for the examples!
    Borislav Nikolov
    @Sesi0
    @zHaytam no problem, btw this was also my question when I asked you when I refresh the browser.
    Peter Morris
    @mrpmorris
    An effect that listens for StoreInitializedAction. Reads state, then dispatches an action with that state in
    Haytam Zanid
    @zHaytam
    Seems like StoreInitializedAction gets triggered even when navigating to another page
    Is that normal?
    Actually, navigating to another page seems to reload the whole page
    Nevermind, it does that when the page doesn't exist
    Haytam Zanid
    @zHaytam
    @mrpmorris Would WASM trimming break the app with Fluxor?
    Matthias-Claes
    @Matthias-Claes

    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?

    Peter Morris
    @mrpmorris
    @zHaytam no. Trimming only affects MS assemblies
    @Matthias-Claes Why do you need a state-facade instead of working with state?
    Matthias-Claes
    @Matthias-Claes
    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
    Peter Morris
    @mrpmorris
    I think it over complicates things
    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
    Matthias-Claes
    @Matthias-Claes
    So you would recommend stepping away from the facade completely using more reducermethods in stead?
    Peter Morris
    @mrpmorris
    From what I can see, his facade only dispatches actions (usually one, sometimes more)
    It doesn't store state, does it?
    Matthias-Claes
    @Matthias-Claes
    It doesn't. Currently I'm also just dispatching from the Facade
    Peter Morris
    @mrpmorris
    But why?
    Why not dispatch the action?
    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