在 React / Redux 和 redux-thunk 中，如果在 fn 是 thunk 时调用 fn()(dispatch) 会发生什么？

Question

I am new to a React project code base, and I saw one function:

const fn = foo => dispatch => { 
  // do something
}

so fn is a function that takes foo and returns a function that takes dispatch and does something.

So inside of fn , I wanted to do some smaller tasks, and would call itself to accomplish that, so I had:

// Code sample 01:

const fn = foo => dispatch => { 
  // do something

  if (someCondition) {
    fn(123)(dispatch);
  }
}

My coworker told me fn is actually used as part of redux-thunk (and so I think fn is a thunk), and the proper way is to call it as:

// Code sample 02:

const fn = foo => dispatch => { 
  // do something

  if (someCondition) {
    dispatch(fn(123));
  }
}

But I wonder if I use Code Sample 01 above, it seemed to run, but the processor has half of the 12 cores running at 80% capacity after the code has run to finish. It sometimes even cause the whole tab of Google Chrome to become unresponsive. What is the reason that Code Sample 01 causes that / what really is happening?

Answer 1

redux is synchronous. in order to be able to do some async action before dispatch, you can use some libraries like redux-thunk .

redux-thunk intercepts your action creator function. if your function returns another function than redux-thunk it will allow you to do some async action, passing dispatch as params, so you can dispatch once you resolve your async request.

on the other hand, if the function doesnt return another function, redux-thunk will let dispatch call the reducers right away as synchronous.

the proper way to use redux-thunk would call dispatch after some async action in a promise chain or an async await fashion:

const myAsyncAction = foo => dispatch => { 
  // do something async like
  // promise chain example but you could use async await
  axios.get('myUrl')
    .then(res => dispatch({ action: 'loaded', payload: res}))
    .catch.(err => dispatch({action: 'fail', payload: err}))
  }
}

Answer 2

I think fn is a thunk

fn here is better described as a 'thunk creator' - the thunk is actually the function taking dispatch as an argument - ie what fn returns.

Your example here is really interesting - I've never seen a thunk recursively dispatch itself, but since a thunk literally is just a function taking dispatch as an argument, I see both styles as equally valid.

When you dispatch a thunk, the dispatch argument that gets injected into the thunk comes from the redux-thunk middleware. Thecode for this middleware is really simple - there is no magic going on here at all.

The dispatch injected into the thunk by the middleware is the same dispatch you use have available anywhere else via redux, and it's just a synchronous JS function call. Therefore, fn(123)(dispatch) is literally the same as doing dispatch(fn(123)) . When you do it the second way, it actually just results in the first way being called but inside the middleware instead of just directly.

Because of that, the two code examples you've given are functionally equivalent, and they should have exactly the same behaviour. I'm not sure what's causing the performance issue with the first example, but it must be some other bug inside the // do something section or elsewhere that's different between the two. From a 'redux perspective', both approach 1 and approach 2 are completely valid and equivalent.