Version 1.x

[tomkis]

Version 1.x

[tomkis]

So let me explain why async/await can't be used for side-effects.

First of all, when you talk about side effects, you need to be more specific what you exactly mean by side effects, since you have mentioned async/await I suspect that you meant API call, however there might potentially be side effects which are not asynchronous, for example logging. When you call console.log it's impurity yet it's totally synchronous operation and would not benefit from async functions at all.

However, I am pretty much convinced that when you mentioned side effects, you actually meant long lived transactions. It's really confusing because even redux-saga claims that it is:

An alternative side effect model for Redux apps

Which frankly, is a nonsense, because redux-saga has nothing to do with side effects. Saga is pattern for Long Lived Transaction (LLT), which in Redux context means series of actions (which may or may not be asynchronous). Typically API call is LLT because it takes more than one action (Request, Response) in place and it lives in time (asynchronous).

async/await is just a syntax sugar on top of Promises, you can just wait for Promise resolving, that's nice, it could help us with our Request <-> Response scenario, but what if our series of actions does not contain only two actions (Request, Response) but may be potentially infinitely long series? It's still transaction, right? It's still long lived, right?

async/await helps you when you need to asynchronously wait for single value. Saga on the other hand can asynchronously wait for many values.

In other words the most trivial Saga definition is something which can accept infinite number of actions and dispatch infinite number of new actions, although it's not just map it's more of flatMap because reaction to one action, may potentially dispatch more than just one action.

And of course, there's also really nice abstraction and it's RxJS Subject ;-) (coming soon)

[tomkis]

Please, we are still open to ideas / suggestions therefore feel free to use this issue.

[tomkis]

Next has been merged to master and 1.3.1 has been released.

[jmatsushita]

Have you considered async/await for the side-effects?

[eliperelman]

Async/await cannot handle all the aspects of the side effects and would make testing much more difficult, as has been laid out in redux-saga:

redux-saga/redux-saga#7
http://yelouafi.github.io/redux-saga/docs/basics/DeclarativeEffects.html

[jmatsushita]

Ah ha I see. But couldn't we use async/await instead of Promises (typically in effects.js) while keeping sagas for their declarative awesomeness?

[eliperelman]

Yes, that is entirely possible, but I'm not sure there is much benefit. redux-saga's call function is already Promise-aware:

// effects.js

// this function returns a promise
export const fetchRandomGif = () => fetch('/gif/random');

import { call } from 'redux-saga/effects';
import { fetchRandomGif } from './effects';

const response = call(fetchRandomGif);

import { fetchRandomGif } from './effects';

const response = await fetchRandomGif();

So as I see it, there is not much to be gained.

[eliperelman]

Also async/await (Async Functions) are mostly sugar on top of Promises. You can't use them without a Promise being created somewhere along the line.