Redux-toolkit: CreateSliceOptions.reducers is marked as required even though it is not

[gaspardip]

I found this while writing some slices that only needed extraReducers (because they reused actions from other slices)

Here is the line where it uses a default map if options.reducers is falsy

https://github.com/reduxjs/redux-toolkit/blob/master/src/createSlice.ts#L211

Let me know if you want me to file a PR, although I don't understand exactly why the public definition of createSlice doesn't match the internal one and uses RestrictCaseReducerDefinitionsToMatchReducerAndPrepare

[phryneas]

Hi there :)

This is from a time where extraReducers simply was not a part of RTK.

Right now, you are right: from a "runtime code" perspective, reducers is not required. But simply making it optional breaks a LOT of type inference (just try it and run the tests :wink: ), so we have the choice of making these types a lot more complicated (and as you noticed, they already are very complicated) or simply require users to pass an empty object.

So far, the "empty object" has been the more practical approach.

As for a PR against the types: this is the worst possible moment, as the types for that file are currently being changed heavily in #290. But you can take a stab at those new types. If you find a simple solution, that would be welcome of course.

Oh, and as an explanation: RestrictCaseReducerDefinitionsToMatchReducerAndPrepare is a helper type that makes sure that the returned payload of the prepare function matches the type of the reducer argument for CaseReducerWithPrepare.
While this made sense for the outside interface, it lead to some internal quirks, which is why the internal definition is a little more lax. But with #290 that will be a thing of the past as well.

[gaspardip]

Ah alright, yeah I actually tried to make the change and it required some test adjustments, so that's why I filed the issue first. I think waiting for #290 to land and then reevaluate how to fix this is the way to go, but I really think you shouldn't need to pass an empty object if it's actually not required. Thanks for the explanations.

[phryneas]

@gaspardip I just gave this a try and making reducers optional or creating a second function signature creates lots of problems in the inference of reducer types, so I'd rather not do that.

Also, I have a second thought: createSlice with just extraReducers is essentially just createReducer. Wouldn't it make more sense to just use that instead?

[markerikson]

Yeah, I don't want to change reducers to be optional. The expectation truly is that you're going to be using that field. And agree with @phryneas that you're basically looking at createReducer in that case.

[gaspardip]

That works for me but shouldn't that be mentioned in the docs at least?

[markerikson]

@gaspardip : which aspect do you feel should be mentioned, specifically?

[gaspardip]

Just a small note mentioning that if you find yourself writing a slice that only makes use of extraReducers you are probably looking for createReducer and how is that related to the reducers empty object, in my opinion.

Also I guess you'd be fine if you omitted reducers in a slice and don't use TS, right?

[markerikson]

Yeah. Can you file a PR to add that note to the createSlice docs page or the usage guide?

[gaspardip]

Yeah sure, will do later today! I'd need you to review the wording tho