[react-redux_v5.x.x] Connect the Dispatch type with actions in dispatch params

[peter-leonov]

Long time no see :)

This PR solves the problem with actions in dispatch props have currently no connection to the Dispatch type argument of the connect() function. In practice this means that Flow will not stop us from returning any random type from an action creator given in mapDispatchToProps. Here is an example:

// first valid action with action creator of our app
type ValidAction1 = {|
  +type: 'VALID_ACTION_1'
|}
const validAction1 = () => ({type 'VALID_ACTION_1'})
// second valid action with action creator of our app
type ValidAction2 = {|
  +type: 'VALID_ACTION_2'
|}
const validAction2 = () => ({type 'VALID_ACTION_1'})

// combined type of all valid actions of our app
type Action = ValidAction1 | ValidAction2

// the dispatch type of our application, which should accept only valid actions of our app
// (vanilla dispatch() returns action as is)
type Dispatch = Action => Action

// here is an example of an invalid action creator (possibly a typo or copy-paste problem)
const invalidAction = () => { foo: 'bar' }

// no own props
type OwnProps = {||}
// this component is going to only dispatch things
type Props = {
  action1: typeof action1,
  action2: typeof action2,
  invalidAction: typeof invalidAction
}

// ... other boilerplate code here ...

// ERROR: currently at this point Flow does not warn us about the `invalidAction`, but is should warn
connect(Props, OwnProps, _, _, _, Dispatch)

We do check the mapStateToProps to get the real state type (if it's present in the code and given or inferable from the call) but fo dispatch the Dispatch type is just bogus and was added to be typed in the bright future. Hopefully, it is now :)

Also, I've fixed some minor things:

• not passing dispatch to config and mergeProps arguments if no mapStateToProps parameter passed;
• fixed type arguments order for the mergeProps part of typings (was a typo);
• pass the empty object type {||} as stateProps to mergeProps and config instead of wrongly inferred empty type for the non present StateProps and DispatchProps.

As this PR makes the typings significantly stricter (and safer) but a bit harder to drop into a random project (especially, after the habits we've developed with the very forgiving mode of Flow <v0.85) we should discuss if and how to make this change smooth 😄

[peter-leonov]

This is what bindActionCreators() actually does.

[Hypnosphi]

Should the corresponding change be made to redux libdef as well?

[peter-leonov]

Here is the main piece of code in this PR:

$ObjMap<DP, Bind<D>>

In simple case it just make sure that the actions returned by the specified in DP action creators are compatible with the function type in D. That it's a function type is implicitly specified by the usage of $ObjMap.

What's more interesting, in case of redux-thunk the code above transforms the raw thunks of type (...A) => (...B) => R from mapDispatchToProps object to (...A) => R in the resulting Props. This thing makes it possible to use thunks returning something useful:

const thunkB = (id) => async (dispatch: Dispatch) => {
  const data = await fetchTodo(id);
  dispatch(todoLoaded(data));
}

const thunkA = async (dispatch: Dispatch) => {
  // dispatch returns the promise from thunkB
  await dispatch(thunkB('todo123'))
}

class TodoLoader ... {
  componentDidMount() {
    const { thunkA } = this.props;
    // so it does in the props too and the new typings support this
    thunkA.then(trackTodoLoaded);
  }
}

[peter-leonov]

This is a test case for redux-thunk as described in previous comment. Here you can see that DispatchProps type as returned from mapDispatchToProps is different to what the Props get. This is exactly because of what connect() does: it hides the arguments by wrapping the thunk value.

Btw, can it be considered as a good monad example, dear functional gurus? 🤓

[peter-leonov]

What do you think, is it time to split the tests for connect in multiple files by topic? Like test_connectMergeProps.js, test_connectStateOnly.js, test_connectConfig.js.

[villesau]

I think that could make sense! Good idea 👍

[EugeneZ]

This looks great. Massive thanks for all the work you've been doing on these typings! I think there is one overload of connect missing, the one where mapStateToProps is provided, and the mapDispatchToProps is a map. (The corresponding overload where the third and fourth arguments are provided is present, however.)

In our code, at least, this seems to be the most commonly used overload.

I've taken a shot at typing these in our code based on your work and they seem to work well so far:

  // this difference is not important in the vanila redux,
  // but in case of usage with redux-thunk, the return type may differ.
  declare export function connect<-P, -OP, -SP, -DP, S, D>(
    // If you get error here try adding return type to your mapStateToProps function
    mapStateToProps: MapStateToProps<S, OP, SP>,
    mapDispatchToProps: DP,
    mergeProps?: null | void,
    options?: ?Options<S, OP, SP, {| ...OP, ...SP, ...DP |}>,
    // Got error like inexact OwnProps is incompatible with exact object type?
    // Just make your OP parameter an exact object.
  ): Connector<P, OP, {| ...OP, ...SP, ...$ObjMap<DP, Bind<D>> |}>;

[peter-leonov]

@EugeneZ 🤦‍♀️ yes, you're right. It was not exactly forgotten, but embedded into the function case and thus typed incorrectly in case of thunks. Thanks a lot for trying out the yet very raw material! And happy new year 🎄🎅🍋!

[villesau]

Good idea to split to files, and one (apparently?) typo :)

[villesau]

you mean notStatic? :)

[peter-leonov]

Eagle eye achievement unlocked!

[villesau]

I think that could make sense! Good idea 👍

[peter-leonov]

Rebased to hopefully get green tests. Will split into files asap.

[villesau]

Nice, GJ!