Inferred dispatch type is not helpful

[eduter]

I was hoping that the AppDispatch from the examples would only accept the actions I defined, but it accepts basically anything.

Was that a design decision, a bug, a known limitation from the current type definition, a limitation from TypeScript itself?

I've created this repo to illustrate what I mean:
https://github.com/eduter/redux-toolkit-example

More specifically these lines:
https://github.com/eduter/redux-toolkit-example/blob/39b4e0d/src/features/counter/Counter.tsx#L48
https://github.com/eduter/redux-toolkit-example/blob/39b4e0d/src/features/counter/Counter.tsx#L26
https://github.com/eduter/redux-toolkit-example/blob/39b4e0d/src/features/counter/Counter.tsx#L34

[markerikson]

This is intentional.

We do not find it useful to try to limit what types of actions can be dispatched at the TS level. Any reducer can respond to any action, and any action can be dispatched without a single reducer caring about it - that's an intentional part of Redux's design. Because of that, we specifically recommend against the semi-common practice of trying to create TS unions representing action types:

https://redux.js.org/usage/usage-with-typescript#avoid-action-type-unions

The main goal of inferring an AppDispatch type is to ensure that TS recognizes any modifications to dispatch that come from middleware overriding behavior (most commonly, the redux-thunk middleware allowing dispatching thunk functions).

Is there a specific reason you're trying to limit things at the TS level?

[phryneas]

Adding to that: every middleware you have in your application can send any kind of action to your reducers - and many of them also will. There is no real value in limiting the action type at dispatch. Just use an action creator and don't dispatch hand-written actions and you should be pretty much as safe as it makes sense.

[eduter]

Right, if you think of AppDispatch as the type that has to accept any action that might be dispatched by anyone in the application, that makes sense. What I was looking for was a type for actions my components may dispatch, to avoid mistakes when connecting them. They won't dispatch INIT or any middleware actions. But sticking to action creators avoids most problems. I think the only problem it doesn't solve, probably can't even be caught at compilation time:

https://github.com/eduter/redux-toolkit-example/blob/39b4e0d/src/features/counter/Counter.tsx#L34

In past projects I didn't have this problem because I was writing all the boilerplate by hand. When writing my own action creators, they would only use the parameters they expected, while the ones generated by the toolkit will put anything they get (including mouse events) into the payload property. I guess it's a fair price to pay for all the code it saves me from writing.

[phryneas]

Well, let's go through these errors:

dispatch(() => 'not an action')}

in this case, () => 'not an action' is a valid thunk. Even if you have a dispatch type that only accepts certain plain actions, if you use the redux-thunk middleware, this has to be a valid thing to dispatch.

          onClick={increment} // A non-serializable value was detected in an action, in the path: `payload`.

This one is... TypeScript being TypeScript - and overloads. The method signature of the action creator here is () => SomeAction, but the code actually assumes that this will never be called with any argument.
Unfortunately, TS allows a function with the signature () => SomeAction to be used in place of a method with the signature (someArgument) => SomeAction - so here, event is put into the payload.

I wonder if we could catch that, but it would not be in the type of dispatch. It would be a change in the action creator type.

[phryneas]

@markerikson I think we could catch that second case with the change

export interface ActionCreatorWithoutPayload<T extends string = string>
  extends BaseActionCreator<undefined, T> {
  /**
   * Calling this {@link redux#ActionCreator} will
   * return a {@link PayloadAction} of type `T` with a payload of `undefined`
   */
-  (): PayloadAction<undefined, T>
+  (noArgument: void): PayloadAction<undefined, T>
}

[markerikson]

sure, seems reasonable to get into 1.9.1!

[markerikson]

That @phryneas is a computer genius man! (classical reference)

[markerikson]

Out in https://github.com/reduxjs/redux-toolkit/releases/tag/v1.9.1

[maksnester]

Hey guys, I'm trying to understand the change that was done here with that noArgument: void as it messes with components when they declare fn prop type via MouseEventHandler.

I see that exact error @markerikson attached as a screenshot but I personally don't understand why it is something good or helpful. What's the problem with the mouse event being passed into payload here if the action doesn't use it (so it'll be ignored) ?

In many cases I just want a component to call whatever I pass to it like

<Dialog onClose={reduxCloseHandlerWithDispatchAttached} />

And because of that change with noArgument: void I have to make dummy wrappers like

<Dialog onClose={() => reduxCloseHandlerWithDispatchAttached()} />

Just to prevent that mouse event being passed to the action that doesn't even care about it. From reading this thread I understood it is a trade off to avoid

// A non-serializable value was detected in an action, in the path: payload

but is non-serializable value even a problem if it doesn't end up in the state?

[EskiMojo14]

@maksnester actions also need to be serializable, to allow proper time travel debugging. actions are recorded to allow the devtools to support skipping and reordering them.

[adrian-gierakowski]

I’m only beginning to learn about redux and RTK and was also surprised that I was able to dispatch actions which are not supported by the store.

Is there any resource I could learn about why being able to do that in my application code was desirable? Thanks!