mrpmorris / Fluxor

Fluxor is a zero boilerplate Flux/Redux library for Microsoft .NET and Blazor.
MIT License
1.22k stars 139 forks source link

Switch to using IServiceProvider #445

Open mrpmorris opened 10 months ago

mrpmorris commented 10 months ago

My current implementation avoids using IServiceProvider, so that there is no dependency on it (no pun intended).

I now think this may have been a mistake, as it means the store has to have everything manually registered (effects and features added to the store, reducers added to the features,). This was done for you automatically by scanning the assembly at startup to look for [ReducerMethod] and [EffectMethod].

One of the problems with this is that when a consumer wishes to write a generic effect, such as one that will set IsLoading = true/false on a state that implements ILoading it was not possible unless the coder (you) told Fluxor at startup a list of classes that you want to use your generic reducer with.

If I switch to depending on IServiceProvider it should be possible to write code like this

[ReducerMethod]
public static TState? ReduceLoading<TAction>(TState? state, TAction action) where TState : ILoadingState where TAction : ILoadingAction
{
  return state with { IsLoading = true };
}
Nickztar commented 10 months ago

This looks like a really nice feature.

My initial thought is that this would require a lot more verbose initialization right? Have to register everything manually (not really a issue for me just something that might be worth considering)?

Anything thing is that this would likely improve startup speed, at least in wasm, since the reflection wouldn't be required anymore if I am not mistaken.

Overall this sounds like a really nice thing and would certainly allow me to write a lot nicer helpers around state (do feel like I do a lot of the same things over and over, especially things like the loading).

mrpmorris commented 10 months ago

It would still be able to auto-discovery what you need registered.

ashern commented 10 months ago

I think that now, you create all of the objects/functions on startup. Will this move that overhead to on demand at first call?

mrpmorris commented 10 months ago

@ashern The discovery would be done with a code-generator, the creation would be done on demand. So even after dispatching Action1, the Effects for Action2 would not yet be created.