Async/Await

[redux-saga]

Async/Await

[Andarist]

BTW is there any docs page discussing A/A vs redux-saga?

No, various comments might be found across issues, but they are not consolidated into 1.

Is the reason for async await-based sagas incapable of performing effects the fact, that what is yielded with redux-saga is a POFO object (representing the effect), whereas with A/A it's a promise, natively?

async/await is all or nothing (can result in a single value only), it returns a promise and resolves intermediary promises with builtin mechanism. Generators do not progress on their own - they need to be called (.next()) to progress, whats more - arbitrary values can be injected (.next(value)), we can call .next right away (for sync effects) in the same call stack or can call it later (async effects) - and some effects might even be a mix of sync/async, like take(channel), if there are pending messages in the channel we resolve immediately, if there are not we wait until something pops up in the channel. Generators are producers which can result in many (even infinite) results. Also because whole control is in hands of redux-saga we can implement things like cancellation, which is not possible with async/await.

Generators might seem like an overkill, they are certainly less familiar to most of JS developers - but they are uniquely powerful. You can implement async/await on top of a simple generator-based runner, but you cant do the opposite - it's impossible to implement yielding generator on top of async/await.

[b4stien]

Hey @yelouafi, the link you mentioned is not reachable anymore, can you update it? This page is the first link googling redux saga and async/away

[Andarist]

@ducin i guess you can write simple sagas as async functions, they are just functions returning promises with some sugar syntax on top of it, BUT that won't let you yield any effects in those "async" sagas, which is the true power of redux-saga

All places, where we actually yield async stuff would make sense, but call is synchronous - would that be a problem

call is by no means synchronous, it can call synchronous functions, but it can also call asynchronous ones. What matters is that this is a "blocking" effect - called function (sync/async/generator) must finish and only then "calling" saga will get resumed.

And the only reason for call is clean testing (which is , as a side effect, disabling async await)?

True reason for having effects is that they are lazy - which opens new techniques. It's the runtime that executes those effects, so in theory we can modify yielded effect, inspect it etc to have it executed in certain way. As a bonus of being lazy they do not get executed automatically in tests.

[fhelwanger]

I think the link @yelouafi pointed to is in the docs now. Check: http://redux-saga.github.io/redux-saga/docs/basics/DeclarativeEffects.html

[corysimmons]

Generators might seem like an overkill, they are certainly less familiar to most of JS developers - but they are uniquely powerful.

Super interesting. Kinda makes me sad async/await exploded in popularity before people (me) really got to explore generators.

Thanks for sticking to guns on generators. Now I have a good reason to grok them.

[Andarist]

The point is - with generators u don't need to handle signals at all. We can just "abort" at any time. If you are looking for an async/await-based solution then you are not looking for redux-saga. Generators are just used here for a reason and they solve problems that this library was set to solve - they were not chosen on a whim.

[Andarist]

In this case, the generators are managed by the redux-saga. It "executes" them - so the user doesn't have to worry about this at all. When the saga gets canceled then our runtime simply calls sagaIterator.return() and that's it. The user, usually, doesn't have to do anything to handle the cancellation in their saga.

[slorber]

@christianalfoni i'm not sure but maybe my answer here could also help answer your question:
#6

[yelouafi]

As @slorber said, async/await makes testing difficult. see Declarative effects section

[yelouafi]

closing this. feel free to comment, I can reopen it if you like

[ducin]

redux-saga won't be internally rewritten to use async/await instead of lower-level coroutines, according to #987. But is it safe for developers to write sagas as async functions? All places, where we actually yield async stuff would make sense, but call is synchronous - would that be a problem? And the only reason for call is clean testing (which is , as a side effect, disabling async await)?

[ducin]

@Andarist thanks for great explanation!
Ok, so basically, replacing generators/promises with async/await would limit the range of possibilities. Is the reason for async await-based sagas incapable of performing effects the fact, that what is yielded with redux-saga is a POFO object (representing the effect), whereas with A/A it's a promise, natively?

BTW is there any docs page discussing A/A vs redux-saga?

[wenfangdu]

Also because whole control is in hands of redux-saga we can implement things like cancellation, which is not possible with async/await.

@Andarist async/await cancellation is certainly possible with AbortSignal.

[Andarist]

Yes, but that forces the author of the async function to handle it at each step of the async task, propagate it to all of its child "tasks" (aka other async functions) etc.

async thisIsHowCancelableAsyncFunctionLooksLike(signal) {
  const res = await doSmth(signal)
  if (signal.aborted) throw new DOMException('AbortError')
  const res2 = await doAnotherThing(res, signal)
  if (signal.aborted) throw new DOMException('AbortError')
  return res2
}

Do you want to write code like that? Cause I don't.

[wenfangdu]

@Andarist Thanks for the quick response, but the cancellation rarely happens, in reality, the code will look like this:

async function thisIsHowCancelableAsyncFunctionLooksLike(signal) {
  const res = await doSmth()
  return thisNeedsAbort(res, signal) // signal is handled within thisNeedsAbort
}

[wenfangdu]

@Andarist Thanks for the insight, could you please provide a minimal example of manual aborting with a generator? Never used generators in depth before since they are somewhat confusing to me.