When to use a separate store vs. component parameters and EventCallback

[andylippitt]

I'm attempting to convert this recent MS sample: dotnet/blazor-samples/blob/main/6.0/BlazorServerEFCoreSample to use Fluxor.

I ended up with a state that looked like this:

public record class CRUDState<T>
    where T : class
{
    public bool Loading { get; init; } = false;
    public IEnumerable<T>? ItemsPage { get; init; } = null;
    public int Count { get; init; } = 0;

    public int FocusItemID { get; init; } = 0;
    public T? FocusItem { get; init; } = null;
    public bool DeleteConfirm { get; init; } = false;
    public bool Deleted { get; init; } = false;
    public bool NotFound { get; init; } = false;

    public bool Error { get; init; } = false;
    public string ErrorMessage { get; init; } = string.Empty;
}

Which covered the CRUD pages for a single type.

But then I find I need to also track my index grid sorts and filters and paging state to get it to align with the current page of results. The bool DeleteConfirm and matching actions and reducers seems pretty silly, and my bool Loading is oversubscribed between multiple async effects.

I feel like I'm doing this all wrong and that there's some more appropriate philosophy of how to blend of using Fluxor along-side component parameters, internal state, and EventCallbacks that I'm missing.

[mrpmorris]

You don't need to store state as to whether or not the confirm delete box is visible etc. You can do those in local state (i.e. within the component).

Use Fluxor state when you want to
A: Show data that might be affected from another part of the system. For example, the current user's name in the top bar might change if the user alters their profile.
B: Store state across navigations so you can go back to them - in your example, you might want to store the search phrase, the items in the grid, and the sorting/filtering (in a good grid component this state can be serialized to/from a string).

[andylippitt]

Thank you