How does Fluxor know which reducer to use? about fluxor HOT 10 CLOSED

It'll look for any state type. If you create a second feature + state and reduce the same action it will call that too, but there must be a feature because that's were the reducers live

from fluxor.

@mrpmorris Thanks for the reply, but I'm still not quite clear, partly because I'm not sure what features are or do. I thought I had a bit of an understanding of them, but your comment confused me.

Also, I tried adding a second state, wittily named CounterState2, and a feature for it...

  public class CounterState2 {
    public int ClickCount { get; }

    public CounterState2(int clickCount) =>
      ClickCount = clickCount;
  }

  public class Feature2 : Feature<CounterState2> {
    public override string GetName() => "Counter2";

    protected override CounterState2 GetInitialState() =>
      new CounterState2(0);
  }
}

I then added a second reducer, which incremented by 2 instead of 1...

  public static class Reducers {
    [ReducerMethod]
    public static CounterState ReduceIncrementCounterAction(CounterState state, IncrementCounterAction action) =>
      new CounterState(state.ClickCount + 1);

    [ReducerMethod]
    public static CounterState2 ReduceIncrementCounterAction2(CounterState2 state, IncrementCounterAction action) =>
      new CounterState2(state.ClickCount + 2);
  }

...but when I run this, the second reducer is not called.

From what you wrote, I thought it would pick up on both reducers.

Please could you clarify, as I'm really not clear what's going on here.

Thanks again

from fluxor.

Could you upload the source for they somewhere, it looks like it should be working.

from fluxor.

@mrpmorris You can find the code here.

If you look in the Store/CounterUseCase folder, you'll see two state classes, each with its own feature, and one action. The Reducers class contains two reducers, one for each state.

However, if you run this and click the button to update the counter, it only gets increased by 1, which looks like only one reducer is being called. If I change the second reducer to use CounterState, so I have two reducers with the same signature, then the counter gets increased by 3, because both reducers are being called.

Sorry if I've done something stupid, but I'm still trying to learn both the Flux pattern and Fluxor's implementation of it, so I'm probably doing something basic wrong 😁.

Thanks again.

from fluxor.

Everything is working correctly. You are updating CounterState by one and CounterState2 by 2. The problem is you are only showing the state from CounterState in your Counter page.

If you also inject IState<CounterState2> CounterState2 { get; set; } into your Counter page then you can display it like so

<p>Current count: @CounterState.Value.ClickCount and @CounterState2.Value.ClickCount</p>

This is in fact exactly how Flux is of benefit, more than one state can update as a result of a single action being dispatched, so it's a very good test for you to try out :)

from fluxor.

@mrpmorris Duh, ain't oi an idiot? Stupidly obvious now you point it out. 😊

So am I right in thinking that Fluxor will call any reducer it can find that takes the appropriate action? In my case, it found two reducers that take an IncrementCounterAction action, so it will call both?

Also, please can you clarify what you meant by "there must be a feature because that's were the reducers live" as I'm still not clear what role features play in all of this.

Thanks again for all the help.

from fluxor.

Yes, Fluxor will execute any reducer that accepts that action.

A Feature is just a way of telling Fluxor that CounterState is a state object and not just a plain class.

When Fluxor scans your assembly it looks for Feature classes and also reducer methods. When it creates an instance of the store it will loop through all discovered reducers, if that reducer's state class is the same as the T in Feature then it will call feature.AddReducer

from fluxor.

@mrpmorris Thanks for the explanation, that makes a lot more sense now.

Just out of interest, why have feature as a separate class? if it's purpose is to mark the state class, why not use an interface on the state class?

Thanks again.

from fluxor.

Because the state is discarded whenever it changes

from fluxor.

OK, thanks for the explanation.

from fluxor.