using withState and withReducer together

After some experimentation, it appears we can chain withState after withReducer to set initial state. If I chain withState before withReducer, then that initial state is discarded. However, I’m wondering if this behavior is a feature we should be using or we really should only use withReducer and pass in the initial state? If we can use both withState and withReducer, it would be nice if ordering did not matter similar to how the .put() works. .put() just expects a put() will occur at some point in the saga.

I find myself naturally gravitating to a syntax where I use withState and withReducer b/c it explicitly tells me what’s going on (that is: I’m using these reducers and this state). Whereas, passing two args into withReducer is less explicit.

      expectSaga(someSaga)
        /// does not work!  this initial state will be discarded after withReducer
        // would be nice if ordering did not matter
        .withState({
          reducer1: {},
        })
        .withReducer(combineReducers({
          reducer1,
        }))
        .run();

      // declarative and and clear what's going on - imo
      expectSaga(someSaga)
        .withReducer(combineReducers({
          reducer1,
        }))
        .withState({
          reducer1: {},
        })
        .run();

      // a little vague - imo
      expectSaga(someSaga)
        .withReducer(combineReducers({
          reducer1,
        }), {
          reducer1: {},
        })
        .run();

Any thoughts?

[tastafur]

This works, try to establish the state of the reducer after adding the reducer? .withReducer(reducer) .withState(state) @jfairbank

[jfairbank]

Hi, @epikhighs.

I initially introduced withState before withReducer, so that’s part of the reason why they don’t play nice together. I’m not opposed to changing the behavior, but I still think having the implicit initial state from a reducer would be useful. Maybe if initial state wasn’t set withwithState, then we could use the implicit initial state from the reducer.

I’m happy to accept a PR that changes the behavior to let the two methods cooperate more nicely.