Platform: Access slice of state in feature module

[doender]

[x] Documentation issue or request

Given the following in app.module.ts (and assuming we cannot change the state's structure):

StoreModule.forRoot({user: userReducer});

And having the following in a feature module:

StoreModule.forFeature('feature', featureReducer)

What is the most idiomatic way to access (read-only) user in featureReducer?

The solution I came up with is dispatch another action that adds user so that it can be used in the featureReducer:

@Effect()
augmentAction$ = this.action$
    .ofType(Actions.Action1)
    .withLatestFrom(this.store$)
    .switchMap(([action, state]:[Action, AppState]) => {
        return [new Actions.Action2(state.user)];
    });

This works, but it becomes hard to manage if almost every action needs to be transformed into another action if user is needed often. Is there a better way to handle this?

Other things I've thought about doing:

• Add the user in the action creator (is this possible? desirable?)
• Combine the reducers in such a way that user is directly available in featureReducer

[rupeshtiwari]

Hi @doender
I would go with first option suggested by you. Before dispatching the action I would put user data in action payload. And I believe this is possible too by writing selector on root reducer and calling selector before creating action payload.

[brandonroberts]

Best practice is to provide the user as part of the payload as mentioned instead of selecting it from the state in the effect. This keeps the Effect pure and easier to test. You can also write a selector that composes the two pieces of data together for your action.

[kylecordes]

This is very interesting. The approach I have been recommending and practicing is to strongly favor reducers as the place where logic resides, and to resist adding complexity to effects more than necessary. This includes expecting actions to contain just the bare essentials, and having reducers access to state incoming as state rather than expecting any other code in the system to copy parts of the state into an action. I have done this because reducers are the most readily testable place to put logic; pure functions. A test case looks like a beginning state, a bunch of simple easily typed actions, and some interim and ending states tested.

I've also seen people present another approach, which is to write only the most simple reducers (I have wondered if down this path one might just abandon handwritten reducers completely...) and instead put all the complexity over in to Effects. Which has its own set of trade-offs of course - Trade-offs that I am both worried about and drawn to, as a relatively fluent user of RxJS.

I had been under the impression that this is all very much up in the air, the subject of many different opinions and experiments. Is it really true that the established best practice is the "have the thing that makes the action grab the relevant part of the state and stuff it in the action" path?

It would be great if there is some kind of document somewhere the talks about the best practices for how to sell certain kinds of problems, where those practices came from, why there better than other alternative approaches.