4 ms·

What solution do you use for async Redux code?

weeksie 7y ago
Handle async stuff in mapDispatchToProps. dispatch => ({ async onRequestFnord(arg) { dispatch(actions.fnordRequested()); const result = await service.fnord(arg); dispatch(actions.fnordReceived(result); } }); Or something to that effect.
- acemarke 7y ago
  Which is 95% identical to a thunk syntactically, except that you've limited how that logic can be tested and reused. There are valid arguments against using thunks [0], but all you've done is put the exact same logic in a different form. Hardly an argument against using them. All you have to do is change it to: const onRequestFnord = (arg) => async dispatch => { dispatch(actions.fnordRequested()); const result = await service.fnord(arg); dispatch(actions.fnordReceived(result); } // later, in the component const mapDispatch = {onRequestFnord}; At least thunks also give you access to `getState`, and if you need it, the ability to inject an "extra argument" that might contain something like a service reference that can be mocked for testing. [0] https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/ https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-th...
  - weeksie 7y ago
    Except you've added a library. And the function is no less testable than the thunk. I fail to see why adding access to the entire application state is an advantage. This is just cargo culting. In fact that you held up that counter example as a preferable practice tells me everything I need to know about your library.
    - r_p4rk 7y ago
      If you feel so bad about including a "library", the redux-thunk middleware is trivial to implement yourself in about 6 lines of code.
  - Izkata 7y ago
    > At least thunks also give you access to `getState`, and if you need it, the ability to inject an "extra argument" that might contain something like a service reference that can be mocked for testing. I've found this to be absolutely required, due to users being able to trigger multiple ajax calls that could return in the wrong order. You need getState() to know which one is valid and discard the old results.
    - weeksie 7y ago
      I feel like that logic is better handled at the reducer level. Trying to think of an instance where it would be absolutely necessary to track state like that in the action. I'm probably missing something, what would be an example?
      - Izkata 7y ago
        One reducer holds the user's criteria, another holds the ajax results. The second one can't access the first one's state to confirm if these results are the correct ones to store, it has to be done in a thunk in the action.
        weeksie 7y ago
        Fair as an escape hatch, and I don’t know your situation, but in a lot of cases I think that’s a smell indicating that you need fewer reducers. I totally understand that there are legitimate reasons for things to end up that way, but it’s certainly something I’d want to avoid or make as rare as possible.
        Izkata 7y ago
        ...so how would you handle the case I described above, where a user can trigger the same ajax with different parameters, fast enough that multiple calls can return in the wrong order (due to network latency, server load, the second one being cached, etc)?
        7y ago

Handle async stuff in mapDispatchToProps. dispatch => ({ async onRequestFnord(arg) { dispatch(actions.fnordRequested()); const result = await service.fnord(arg); dispatch(actions.fnordReceived(result); } }); Or something to that effect.

acemarke 7y ago
Which is 95% identical to a thunk syntactically, except that you've limited how that logic can be tested and reused. There are valid arguments against using thunks [0], but all you've done is put the exact same logic in a different form. Hardly an argument against using them. All you have to do is change it to: const onRequestFnord = (arg) => async dispatch => { dispatch(actions.fnordRequested()); const result = await service.fnord(arg); dispatch(actions.fnordReceived(result); } // later, in the component const mapDispatch = {onRequestFnord}; At least thunks also give you access to `getState`, and if you need it, the ability to inject an "extra argument" that might contain something like a service reference that can be mocked for testing. [0] https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/ https://blog.isquaredsoftware.com/2017/01/idiomatic-redux-th...
- weeksie 7y ago
  Except you've added a library. And the function is no less testable than the thunk. I fail to see why adding access to the entire application state is an advantage. This is just cargo culting. In fact that you held up that counter example as a preferable practice tells me everything I need to know about your library.
  - r_p4rk 7y ago
    If you feel so bad about including a "library", the redux-thunk middleware is trivial to implement yourself in about 6 lines of code.
- Izkata 7y ago
  > At least thunks also give you access to `getState`, and if you need it, the ability to inject an "extra argument" that might contain something like a service reference that can be mocked for testing. I've found this to be absolutely required, due to users being able to trigger multiple ajax calls that could return in the wrong order. You need getState() to know which one is valid and discard the old results.
  - weeksie 7y ago
    I feel like that logic is better handled at the reducer level. Trying to think of an instance where it would be absolutely necessary to track state like that in the action. I'm probably missing something, what would be an example?
    - Izkata 7y ago
      One reducer holds the user's criteria, another holds the ajax results. The second one can't access the first one's state to confirm if these results are the correct ones to store, it has to be done in a thunk in the action.
      - weeksie 7y ago
        Fair as an escape hatch, and I don’t know your situation, but in a lot of cases I think that’s a smell indicating that you need fewer reducers. I totally understand that there are legitimate reasons for things to end up that way, but it’s certainly something I’d want to avoid or make as rare as possible.
        Izkata 7y ago
        ...so how would you handle the case I described above, where a user can trigger the same ajax with different parameters, fast enough that multiple calls can return in the wrong order (due to network latency, server load, the second one being cached, etc)?
        7y ago