5

I keep reading that I should use redux-thunk or redux-saga to handle side effects. Why not simply use action creators like that to dispatch multiple actions :

function loadProductActionCreator(dispatch) {
  dispatch({
    type: 'load_product',
  })
  fetch('api/product').then(
    function (r) {
      return r.json();
    }
  )
  .then(function (res) {
    dispatch({
      type: 'loaded_product',
      data: res
    })
  })
}

I tried that and it worked (complete code). So I guess there must be some inconvenients I'm not aware of.

sylvain
  • 1,951
  • 2
  • 19
  • 34
  • You can do that for sure. When you are fed creating wrappers for every action creator manually (like you do on lines 45-47) - you give up and take redux-thunk. – zerkms Dec 11 '16 at 21:48
  • so that's the only benefit ? avoiding creating several actions for this kind of tasks ? – sylvain Dec 11 '16 at 21:51
  • If you check the redux-thunk code you would see that the function it exports is just 4 (four) lines of code https://github.com/gaearon/redux-thunk/blob/master/src/index.js – zerkms Dec 11 '16 at 21:58
  • 2
    wow. There's also a very detailled explanation from Dan Abramov here : http://stackoverflow.com/questions/35411423/how-to-dispatch-a-redux-action-with-a-timeout/35415559#35415559 (from redux-thunk home page) – sylvain Dec 11 '16 at 22:06
  • How you are going to test that? :D – Henrik R Dec 12 '16 at 12:16
  • @HenrikR I won't, but if I had too I'll probably fake the fetch (or use something like nock) and resolve promises manually to ensure dispatch are called at the right time with the right arguments. Not the simplest thing I have to admit. – sylvain Dec 12 '16 at 22:21

2 Answers2

5

You code is similar to what thunk does.

As per redux docs, actions should be pure. And they should always return same values for same input parameters. By using fetch you are allowing action to return not specific value, rather value from server and that mean action response may vary upon time.

That is called side effects. And it's something what shouldn't be in redux actions by default.

But why?

Yes, you can type it inside action like you have, in small apps it does not matter.

In larger application there are benefits of using redux-saga:

  • actions are predictable, they just return payload like

    {
  type: 'FETCH_POSTS',
  params: {
    category: 'programming'
  }
}

  • and then you build middleware which will take actions with all data required to perform request to real API

Possible advantages:

  • Cleaner codebase (but may be overhead on smaller applications)
  • Separation of "dummy" actions with all required information to perform requests and actual API middleware
  • Request parameters are visible directly in redux dev tools
  • Possible to easily debounce, throttle fetches which may be really tricky with redux-thunk
  • Possible to easily combine actions (wait for another event/fetch, chain events)
  • Possible to stop running tasks

From personal experience, on one project (larger codebase) we have started with redux-thunk, but later we needed to integrate more advanced features, like throttle, and some dependencies between actions. So we rewrote everything to redux-saga and it worked well for us.

Jurosh
  • 6,984
  • 7
  • 40
  • 51
  • As per Redux docs, **reducers** must be pure... Actions are plain objects `{type: 'someType', payload: 'someData'}`, aren't they? – cbdeveloper Dec 12 '19 at 11:32
1

You are kind of replicating redux-thunk here. A pure redux action creator should return an action object to be dispatched and not dispatch an action itself (see redux doc on action creator).

To better understand why your technic is a replication of redux-thunk, look at this post from its author

Community
  • 1
  • 1
Thibault Vilon
  • 11
  • 2