Why does RematchDispatch give `never` type when there is a reducer and an effect with the same name?

558 Views Asked by At

I just upgraded from typescript 4.1.2 to 4.3.2 using Rematch. These rematch packages are used:

  • "@rematch/core": "2.0.1"
  • "@rematch/select": "3.0.1"

and I faced a typescript error: Type never has no call signatures. I looked into the 3rd parties' code and found that RematchDispatch gives never type when I have a reducer and an effect in a particular model with the same name. For example:

export const myModel = createModel<RootModel>()({
  state: { ... },
  reducers: {
    myReducer(state, payload: string) { ... }
  },
  effects: dispatch => ({
    myReducer(payload: string, rootState) { ... }
  }
}

and RematchDispatch<RootModel>['myModel']['myReducer'] type will give 'never' type so for example I cannot call this via useDispatch in a react component because of the above-mentioned typescript error.

I also checked the documentation: https://rematchjs.org/docs/api-reference/models and found this

Effects functions that share a name with a reducer are called after their reducer counterpart.

This seems to be a valid case and it worked in my project until this typescript upgrade so this issue might be related to the Rematch and Typescript mix.

Could you please help me with this issue? What did I do in the wrong way?

Thanks in advance!

1

There are 1 best solutions below

3
On BEST ANSWER

I'm Sergio, Rematch Maintainer!

Looks you found an issue of our typing's system, actually TypeScript upgrade from 4.1 to 4.3 changed a bit how it handles several scenarios that made necessary an adjustment by Rematch team.

We're already working on this: https://github.com/rematch/rematch/issues/912, and also we already introduced a Github Action to tests our typings tests to Typescript@next version, in that way we can fix this issues before TypeScript releases his stable.

A possible workaround, is to name differently your effect and your reducer, like increment for the effect and INCREMENT in uppercase for the reducers.

Anyways, this should be fixed and we're already working on it :)