Docs: Add docs for reducer creators

[brandonroberts]

Follow-up to #1746

• Document usage of createReducers
• Keep references to using a reducer function with a switch case for current users

[alex-okrushko]

I'll take it

[brandonroberts]

👍

[realtomaszkula]

I think it would be beneficial to mention providing the reducers for AoT.

export function reducer(state, action) {
  return createReducer(...);
}

StoreModule.forFeature('feat', reducer)

[brandonroberts]

Just for clarity, we're generating the reducer outside the exported function in the schematics, but the point still remains.

const someReducer = createReducer(...);

export function reducer(state: SomeState | undefined, action: Action) {
  return someReducer(state, action);
}

StoreModule.forFeature('feat', reducer)

[alex-okrushko]

Putting it for myself so I don't forget all the info that's needed:

• before/after of simple reducer
• explain the need for proper typing of initialState
• add the note to always pass state into on-reducers (so that the return type is inferred correctly)
• explain how many actions could be provided for a single on-function
• explain how to wire it up for forFeature - including the case if it's the only reducer for the feature
• explain how to wire it up for forRoot (using token - if I won't have time to make it take the fn)

[fxck]

Could on accept different kinds of the first param? Say if I wanted to catch any action that has entities on it? Should I handle this outside createReducer?

How about something like

on(({ entities }) => !!entities), (state, action) => state)

[timdeschryver]

I don't think this is something we would add @fxck .

We're still reacting to unique actions.

[fxck]

Yeah, well since you have to do this anyway #1762 (comment) I can live without that. :)

[alex-okrushko]

@fxck I think that could result in more brittle logic. type should be the only thing that defines reducer behavior, I think.
At least that's how I see it ATM.