Always call verifyStateShape for combined reducers

[ellbee]

As discussed in #715

[gaearon]

It's still saying “initial state” in the error message.

[ellbee]

Ah, sorry. I thought you meant it could be changed because the message already made sense. Of course, it does not. I'll update.

[ellbee]

I think it is clearer if the messages are slightly different depending on whether the warning has been triggered via the INIT action in createStore or by calling the the reducer directly. Here is how I propose the messages read for these two cases:

Passing mismatching initialState to createStore (existing case)

The initialState argument passed to createStore has unexpected type of "Number". Expected argument to be an object with the following keys: "foo", "baz"

Unexpected keys "fdfds", "dsfsdf" in initialState argument passed to createStore will be ignored. Expected to find one of the known reducer keys instead: "todos", "todosReverse",
"dispatchInTheMiddleOfReducer", "errorThrowingReducer"

Passing mismatching state to reducer

Unexpected key "bar" in state argument passed to reducer will be ignored. Expected to find one of the known reducer keys instead: "foo", "baz"

Unexpected keys "bar", "qux" in state argument passed to reducer will be ignored. Expected to find one of the known reducer keys instead: "foo", "baz"

The state argument passed to reducer has unexpected type of "Number". Expected argument to be an object with the following keys: "foo", "baz"

[gaearon]

in state argument passed to reducer will be ignored

This might be a bit misleading because most likely the user didn't pass the argument to reducer themselves. They just returned it the last time. Any idea how to change phrasing to suggest this?

[ellbee]

Yeah, I think you are right.

As reducers are shown in the docs to have signature of (previousState, action) => newState, how about something like this?

The previous state received by the reducer has unexpected type of "Number". Expected argument to be an object with the following keys: "foo", "baz"

Unexpected key "bar" in previous state received by the reducer will be ignored. Expected to find one of the known reducer keys instead: "foo", "baz"

I think this is better, but the first sentence of the second warning is starting to read a bit awkwardly.

[ellbee]

Slight variations:

Unexpected keys "bar", "qux" found in previous state received by the reducer. Expected to find one of the known reducer keys instead: "foo", "baz". Unexpected keys will be ignored.

Unexpected keys "bar", "qux" found in reducer's previous state. Expected to find one of the known reducer keys instead: "foo", "baz". Unexpected keys will be ignored.

[gaearon]

I like this:

Unexpected keys "bar", "qux" found in previous state received by the reducer. Expected to find one of the known reducer keys instead: "foo", "baz". Unexpected keys will be ignored.

[ellbee]

PR updated with the preferred wording

[gaearon]

Great job! 👍