I'm using async/await throughout my codebase. Because of this my api calls are defined by async functions
async function apiFetchFoo {
return await apiCall(...);
}
I would like to call this function from my saga code. It seems like I can not do this:
// Doesn't work
function* fetchFoo(action) {
const results = await apiFetchFoo();
yield put({type: "FOOS_FETCHED_SUCCESSFULLY", foos: results});
}
However, this does work, and matches the redux saga documentation:
// Does work
function* fetchFoo(action) {
const results = yield call(apiFetchFoo);
yield put({type: "FOOS_FETCHED_SUCCESSFULLY", foos: results});
}
Is this the correct way to use Redux Saga alongside async/await? It is standard to use this generator syntax inside of the saga code, and the async/await pattern elsewhere?
Yes, that's the standard way to use Redux-Saga.
You should never be calling the await function directly inside the saga-generator, because redux-saga is for orchestrating the side-effects. Therefore, any time that you want to run a side-effect you should do it by yielding the side-effect through a redux-saga effect (usually: call or fork). If you do it directly without yielding it through a redux-saga effect, then redux-saga won't be able to orchestrate the side-effect.
If you think about it, the redux-saga generator is completely testable without the need of mocking anything. Also, it helps to keep things decoupled: if your apiFetchFoo returned a promise, the saga would still work the same.
As pointed out by Josep, await cannot be used inside a generator. Instead you need to use an async function. Also, note this is a limitation of async function itself. It is not imposed by redux-saga.
Beyond this, I also wanted to mention that it is a conscious choice by the redux-saga authors to not allow devs to express sagas as async/await functions.
Generators are more powerful than async/await and they allow advanced features of redux-saga like co-ordinating parallel tasks.
Moreover, expressing sagas as generators help us define Effects which are plain objects defining the side effect. Effects makes it very easy to test our sagas.
So, although your working code is fine, maybe not mixing up sagas and async function is a good idea.
Just define your apiFetchFoo to return a promise which resolves with the response to the request. And when this happens your saga will resume with the results.
const apiFetchFoo = () =>
fetch('foo')
.then(res => res.json())
As the previous answers says , Redux saga uses side effects which handles the async within it so the way of doing it , Is using yield and call if calling an API and so on so far
await always work within a function that's declared as async. #thumbRule
async function fetchList () {
let resp = await fetchApi([params]);
}
Related
is there any quick way in vs code to search for
method1 referenced inside method2?
I am trying to see if using remote-redux-devtools is useful for my project, and we are using next js which does server side calls via getInitialProps so I am trying to find all references to dispatch inside getInitialProps
rather than search for either term (dispatch or getInitialProps) via command + shift + F individually, i need a more specific search.
in this case I need to search for references to dispatch inside getInitialProps
If we can assume that your getInitialProps functions are of a form similar to this:
static async getInitialProps(ctx) {
const res = await fetch('https://api.github.com/repos/zeit/next.js')
const json = await res.json()
dispatchEvent(event)
return { stars: json.stargazers_count }
}
particularly with respect to the return statement on the final line, then this regex works to distinguish those getInitialProps functions with the sequence dispatch somewhere in that function.
^.*getInitialProps[\s\S]*?\bdispatch[\s\S]*?(return).*\n.*
If you want only dispatch as opposed to dispatchEvent you could use word boundaries around it like \bdispatch\b unless it is used as dispatch( then use \bdispatch( or similar.
See regex101 demo
The tutorial on async programming here talks about async await, but avoids discussing the Future API. I could find more information about the Future API here, but still I have some questions. These tutorials made me raise some questions, ideally I should have placed one for each questions, but since they are small and related I preferred to ask them all in one place.
What triggers/starts a Future execution?
From the text I can only conclude that once an async method returns the Future will be immediately triggered by the runtime.
What's the difference between Future.wait() and Future.then().then().then()?
Are return await myFuture; and return myFuture the same?
The text says an async method will return an incomplete Future once it sees an await or a return.
The text says:
Important: Async functions return Futures. If you don’t want your function to return a future, then use a different solution. For example, you might call an async function from your function.
How can we call an async function, get its return value, and not await, thus, not be an async function?
What triggers/starts a Future execution?
The code block for a Future is placed into the event queue, so it's executed when its turn in the event queue comes up. The Flutter in Focus Futures video has some good visuals about how this works.
What's the difference between Future.wait() and Future.then().then().then()?
They are different ways of handling multiple futures, but the differences are subtle. Future.wait handles errors slightly differently, and its values are returned as a list rather than in sequential code blocks, but in practice, the difference might not matter for your situation.
Are return await myFuture; and return myFuture the same?
No. In the first instance, execution is paused at the await until the Future is processed in the event queue. In the second instance, the Future itself is returned to the caller and execution continues as the caller wishes (probably until the Future is given a chance to be handled).
await is a language feature the essentially waits on the Future to complete at that point, whereas return simply returns the Future itself to the caller.
How can we call an async function, get its return value, and not await, thus, not be an async function?
If you need the return value, then you'd call the async function and then use it's Future directly rather than use await. Here's a silly example:
Future<int> getAsyncInt() async {
return 0;
}
void testAsync() {
getAsyncInt().then((value) {
print("Got an async int: $value");
});
}
In the above example, you can see we use an async function, but testAsync does not await the value (rather uses a Future, so the end result is the same).
If you don't need the return value though, you can just call the async function directly though:
Future<int> getAsyncInt() async {
return 0;
}
void testAsync() {
getAsyncInt();
}
In this second case, in fact, getAsyncInt() will indeed be called, even though it's return value is ignored by the caller.
These are good questions, BTW, hope that helps. async/await can be rather mysterious, but thinking of them as event queues really helps to understand in the flow of execution IMHO.
If I want to await a function, why does that have to be done in an async function only?
If I have this:
Function myFunc() {
return await myOtherFunc();
}
I get an error saying: “await expression is only allowed within an asynchronous function.”
I can understand if myOtherFunc() had to be asynchronous (it doesn't make sense to await an asynchronous function), but why does it care if the calling function is asynchronous or not. You can have a fork in a process within a synchronous function due to a call to an asynchronous function, right? So then why can’t you await that asynchronous function within the synchronous function?
NOTE: my question is NOT a duplicate of Javascript Await/Async Feature - What if you do not have the await word in the function?.
^ that question is asking what happens if await is not used in an async function. I'm asking why the function has to be async in order to use await. My response to DougBug below explains why they are different.
The picture in the following article might help explain it to you a bit.
https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/index
The basic idea though is that the async keyword allows the function to yield its execution up to a calling function.
As such any function that implements await must be marked async so that it can traverse back up the calling path until the first caller is only waiting on it to complete what it needs to do.
I've created some factory functions that give me simple (or more advanced) reducers. For example (simple one - base on action type set RequestState constant as a value):
export const reduceRequestState = (requestTypes: RequestActionTypes) =>
(state: RequestState = RequestState.None, action: Action): RequestState => {
switch (action.type) {
case requestTypes.start:
return RequestState.Waiting;
case requestTypes.success:
return RequestState.Success;
case requestTypes.error:
return RequestState.Error;
case requestTypes.reset:
return RequestState.None;
default:
return state;
}
};
Using those factory functions and combineReducers from redux I can compose them into fully functional reducer that handles most of my casual actions. That gives me readable code and prevents me from making silly mistakes.
Factories are good for common actions but when I need to add some custom behavior (for action type) which should modify some part of the store significantly I would like to write a custom part of the reducer that will handle that action for me.
The idea is to compose reducers in an iterate manner, so combineReducers but for an array. This way I could use my factories creating reducer and then combine it with my custom reducer that handles some specific actions. The combineReducers for an array would then call the first one, recognize that nothing has changed and call the second (custom) one to handle the action.
I was looking for some solution and found redux-actions but do not quite like the way it links actions and reducers making the semantics little different from what I'm used to. Maybe I do not get it, but eventually I like to see that my reducer is written as pure function.
I am looking for some hint that will show me the way.
Is there any library or project that uses any kind of higher order reducers and combines them in some way?
Are there any downsides regarding composing reducers like described above?
Yep, since reducers are just functions, there's an infinite number of ways you can organize the logic, and composing multiple functions together is very encouraged.
The "reducers in an array" idea you're looking for is https://github.com/acdlite/reduce-reducers. I use it frequently in my own app for exactly that kind of behavior - running a combineReducers-generated reducer first, then running reducers for more specific behavior in turn.
I've written a section for the Redux docs called Structuring Reducers, which covers a number of topics related to reducer logic. That includes useful patterns beyond the usual combineReducers approach.
I also have a list of many other reducer-related utilities as part of my Redux addons catalog.
I'm writing some exception logging code using the raven-js lib, and I'd like to log every redux action to create a breadcrumb trail of pre-exception activity.
I know this is a use case for middleware, but I'd find it much easier/more flexible to write a simple saga:
function* logReduxAction(action) {
// promisified Raven.captureBreadcrumb()
yield logBreadcrumb({ 'redux',action.type })
}
export const exceptionSagas = [
fork(takeEvery, '*', logReduxAction),
]
Is this an anti-pattern? Is capturing an action via saga notably less efficient than middleware? Or some other 'gotcha'?
Well redux-saga is a middleware. What you are asking is should you use ready-made middleware for logging events or come up with your own solution using sagas. I would say doesn't matter that much, use a solution which better suits you.