when will redux-saga migrate to async/await?

[anymost]

As the title showed, I want to know when redux-saga will migrate to async/await, The generator function is too complicated to use.

[Andarist]

No.

From the user perspective it is no different than async/await - effects are yielded and u can think of that as they would be "awaited".

From the library's (redux-saga) point of view async/await is to generators like a younger, dummy brother 😉 You can do much, much more with generators than with async/await.

Please also read this comment

[hoodwink73]

Hey @Andarist

Thanks for your efforts in Redux Saga.

Will you be open to adding a small section in the docs detailing why redux-saga uses generators over async/await and a disclaimer that we will not be using async/await?

There is a similar question raised in StackOverflow too.

[Andarist]

I'm totally open for adding it, just not for adding it myself. Would you like to compile those 3 comments into a single short-ish section of the README?

[hoodwink73]

Absolutely. Will raise a PR.

[Andarist]

Cool, thank you very much! 👍

[sincerekamal]

@Andarist Interested and eager to know what much more things redux-saga is doing with generators which is tough or impossible with async/await

[Andarist]

@sincerekamal cancellation for starters - u cant cancel promises (which are ultimately created when calling async functions), but u can stop iterating through an iterator (u can even call its return method)

[antialias]

u can even call its return method

return is a statement.

[alankar-anand]

I have used async await inside Redux saga. Here's the question on stackoverflow. Both can co-exist if someone wants to use it that way.

[Andarist]

@antialias

It's also iterator's method 😉

function *saga() {}
var it = saga()
it.return()

[antialias]

Cool! I'm apparently still learning about this stuff. Thanks @Andarist

[ceefour]

@Andarist I'm sorry to use this as a question, but I'd like to know how to do "await" with redux-saga ?

What I mean is, by dispatch()-ing an action, redux-saga will run it in background.

The problem is, I'd like the button (or whatever is the UI), to "await" the saga.

In essence:

try {
  await dispatchSomething();
  console.info("Yay it's done");
} catch (err) {
  console.error("Saga gave me error:", err);
}

Currently I'm doing something like this instead:

return new Promise((resolve, reject) => {
  dispatchSomething(resolve, reject);
}).then(res => console.info("Yay it's done"))
.catch(err => console.error("Saga gave me error:", err));

and the saga must call the given resolve / reject from the action, which seems to be weird...

[shellscape]

@Andarist I just had to jump in here and poke you on this 😄 while iterators seem to have a use case here, the developer experience could be improved by leveraging async/await (which I dare say is much more common these days) along side for those who don't need the advanced capabilities of generators. I ended up here because one of our devs asked me to review a PR, and while I'm more of a backend monkey these days, I'd never seen redux-saga in the wild. It totally threw me off to see generators still around! I hadn't seen them since the pre-2.0 days of Koa!

[Andarist]

async/await is very much supported - all the things you have to do is to:

yield call(asyncFn)
// or
yield asyncFn()

However, the first one is preferred.

I understand the generators are not as popular of a choice usually but they actually fit perfectly here. I also fail to see what using async/await would actually solve here - after all, async/await "just works" with Redux (u'd only need a very thin middleware). async/await pretty much nullifies everything that redux-saga offers so it just can't just be used as a primary user-facing API - the redux-saga would just not be redux-saga anymore with that.

There is, of course, a point in being able to call into async functions - but as mentioned, that's already covered.