I need to call api by checking some condition. But this api call is needed after any request / response. But I couldn't find anything useful for this.
So, I am looking for a solution to setup the project using redux-saga so that I can call an api on any request / response.
For eg. we can have different api calls from different places;
.fetch('/books')
.fetch('/copies')
etc.
Now, I want also to call an api on every fetch (before request and after response). Hope, this is now clear.
Have you tried effectmiddlwares in redux-saga: https://github.com/redux-saga/redux-saga/blob/master/docs/advanced/Testing.md#effectmiddlwares ?
Assuming you have a reliable way to identify actions that are responses you can use a pattern function to match all response actions and trigger another call.
For example:
// assuming your response success action types all look like "REQUEST_TYPE_SUCCESS"
function isResponse(action) {
return action.type.endsWith("SUCCESS")
}
function* makeApiCall(action) {
// maybe do some logic to determine the api call based on the action
yield call(asyncApiCall, args);
}
function* responseWatcher() {
// consider takeLatest or takeLeading instead of takeEvery depending on your use case
yield takeEvery(isResponse, makeApiCall);
}
And then add responseWatcher to your root saga however you are setting that up.
See the api reference for take if you need more info on the pattern arg to the take helpers: https://redux-saga.js.org/docs/api/#takepattern
Related
I am using redux-saga with React. Lets say i'm fetching some data from server that need some external client side calculation. My question is where to put them.
my saga looks something like this:
function* someEffect(action){
try{
//removed none related stuff from the code.
const data = yield call(someRequestFucntionThatUsesAxios, requestparams);
if(data.status>=200&&data.status<300){
yield put({type:SUCCESS, payload:data.data)};
}
catch(err){
}
}
In the above code data.data needs some calculation(basic math mostly). Now, which one of these options makes more sense?
handling those calculations in my connected components componentDidUpdate method.
handling them right after receiving it (before dispatching to to reducer).
(I know that reducer is no place for such behaviour but since it doesn't kill to ask,) handling it inside my reducer.
As you have said reducer is not the best place to modify the API response, neither saga is.
I would suggest you to use transformResponse function in axios, to modify the response just right after it is returned from API.
axios.get('/', {
transformResponse: (data) => {
// do whatever you like with the data
},
});
How can we get the data from the saga directly into our component ?
or
Is this a pattern we should not follow and directly make a service/ api
call from the component using some service layer.
I have been following this issue on git on if this is possible there are too many permutations and combinations and i am a bit confused ..
I tried this small example by refering this
stackblitz.
In this case when i try and return this
function* helloSaga() {
return new Promise(function(resolve, reject) {
resolve('start of new Promise');
});
}
and access it like this
let response = dispatch(action('SHOW')).then(data => {
console.log(data); // i cannot get this to work say if this were a api response .
})
Nothing happens .
Is this pattern acceptable if yes then how can we make it work and what am i missing it
And if this pattern is an anti-pattern then making service calls from a layer like getData() should be enough from componentDidMount() .
A generator function doesn't really return a value (or the promise in your case) as you'd expect with any "regular" function. It returns a generator-object that you can pause, continue, cancel etc.
Check https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function*
The way to go with redux-saga in a web app would be:
Trigger an action like "SHOW" in your example
Have a saga take your action "SHOW"
The saga would then do the async API request
Once the API request is done, the saga dispatches another action (something like FETCH_SUCCEEDED
Handle the action in your reducer and store the response in the redux store.
Once it's stored in the redux store, you can select it from any react component you want to (use connect from redux for that)
Here's your stackblitz with a minimal example:
https://stackblitz.com/edit/react-redux-sagas-demo-app-4tpevb?file=index.js
For a production app, you'd want to wrap the API request in a try{..}catch(){..} and handle the error with a proper action like FETCH_FAILED and display an error message in your FE (if it effects the user).
Here are two code samples:
onClick() { // click-handler of a button
axios.get(someUrl)
.then(response => {
// setData is a fn dispatching an action-creator passed through react-redux's connect()
setData(response.data);
});
}
or
// buttonClicked is also a fn dispatching an action-creator
// Difference being the middle-ware handles the entire async process
<button onClick={this.buttonClicked}>Click me</button>
The latter method will use Axios in some middleware, and then dispatch another action which will set the response data in the store.
So this means that the first approach will only dispatch one action, while the second approach will dispatch two actions.
Both ways obviously seem to work, but I would like to know what the best way would be. Is there a downside to either approach?
Disclaimer: This is an opinionated answer, and somewhat rambly.
The thing about promises is that they work the way a human being would think of a promise. So use them like that in your program. Typically IMO you should only use Promises when you know that an event would occur in the normal course of your program workflow, or when you are promising a result.
So for example if you ask for a socket connection, I promise to give one to you whenever I am able to, you don't have to wait for me, just go on and do your thing, as soon as I have done everything needed to get that back to you I will hand it to you; and you can move on in your workflow from the point that needs it. For example, (pseudo code):
var Socket = new Promise(function(resolve, reject) {
resolve(do_something_to_get_a_socket());
});
Socket.then(authenticate()).then(sendData());
etc.
Sticking a promise to an event handler like onClick should be a promise to do something for the user — use it in your code to create threads that will do the heavy lifting of complex processing, while the user is still able to interact with the interface.
For example, in a game a click could fire a dart and you promise that it will animate on the screen (and even if that glitches) you still promise that it will hit the target etc, but the user doesn't have to wait for the promise to be fulfilled to fire another dart.
So use Promises to make your program more readable by you and other coders, and use it to make workflow of your program more realistic to your usecase.
I heavily recommend something like: https://www.npmjs.com/package/redux-api-middleware
This middleware (or others like it) contain quite a few features you would most likely have to write yourself if you were to implement this with just axios in a callback. For example, it will automatically dispatch request, success, and failure actions based on the AJAX call's result.
When dispatching this action using the middleware, many things are taken care of for you.
{
[CALL_API]: {
endpoint: "http://example-api.com/endpoint",
method: "GET",
headers: { ... },
types: [
"GET_X_REQUEST", "GET_X_SUCCESS", "GET_X_FAILURE"
]
}
}
Something like this will automatically fire a "GET_X_REQUEST" action when it begins to load. Then a success or failure action (with appropriate data or error objects attached as a payload) when the AJAX call completes or fails.
Or any similar middleware where Redux ends up handling the entire async process.
I keep reading that I should use redux-thunk or redux-saga to handle side effects.
Why not simply use action creators like that to dispatch multiple actions :
function loadProductActionCreator(dispatch) {
dispatch({
type: 'load_product',
})
fetch('api/product').then(
function (r) {
return r.json();
}
)
.then(function (res) {
dispatch({
type: 'loaded_product',
data: res
})
})
}
I tried that and it worked (complete code). So I guess there must be some inconvenients I'm not aware of.
You code is similar to what thunk does.
As per redux docs, actions should be pure. And they should always return same values for same input parameters. By using fetch you are allowing action to return not specific value, rather value from server and that mean action response may vary upon time.
That is called side effects. And it's something what shouldn't be in redux actions by default.
But why?
Yes, you can type it inside action like you have, in small apps it does not matter.
In larger application there are benefits of using redux-saga:
actions are predictable, they just return payload like
{
type: 'FETCH_POSTS',
params: {
category: 'programming'
}
}
and then you build middleware which will take actions with all data required to perform request to real API
Possible advantages:
Cleaner codebase (but may be overhead on smaller applications)
Separation of "dummy" actions with all required information to perform requests and actual API middleware
Request parameters are visible directly in redux dev tools
Possible to easily debounce, throttle fetches which may be really tricky with redux-thunk
Possible to easily combine actions (wait for another event/fetch, chain events)
Possible to stop running tasks
From personal experience, on one project (larger codebase) we have started with redux-thunk, but later we needed to integrate more advanced features, like throttle, and some dependencies between actions. So we rewrote everything to redux-saga and it worked well for us.
You are kind of replicating redux-thunk here. A pure redux action creator should return an action object to be dispatched and not dispatch an action itself (see redux doc on action creator).
To better understand why your technic is a replication of redux-thunk, look at this post from its author
I'm trying to get some thoughts on what people would consider the best practices for how people organize network calls in their react+redux apps. I usually let my components make the calls, get data and then pass that into an action that will get reduced. Is this the best practice or is it better to separate networking out of my components and place that logic somewhere else in the app, maybe in the reducers?
The best place to make network calls is in your action creators. However, you're going to need some middleware to make that work best. Take a look at this promise-middleware (in fact, I'd suggest checking out that whole tutorial). If you use that middleware, you can have action creators that return a promise and also have three action types - one for the request, one to handle successful responses, and one to handle failed requests. Then you just listen for those 3 actions in your reducers.
So with that middleware, you could have an action creator like this:
function networkCall() {
return {
types: ['MAKE_REQUEST', 'REQUEST_SUCCESS', 'REQUEST_FAILURE'],
promise: () => {
return new Promise((resolve, reject) => {
$.ajax({
url: 'example.com/api'
type: 'GET'
});
})
}
}
}
Obviously you are free to build your own promise middleware, but that should set you in the right direction.
I think this is one thing that was done right in Angular. You have all your network calls neatly placed in your services. This can easily be done in Redux.
The docs rightly suggest that network calls are in your actions. I'd factor them out into a separate place, you can call it "services". There you would define all your constants such as your API server URL, authentication-related stuff, etc. This would be the only place that is aware of the implementation details of your network calls - which library you use (jQuery, axios, superagent, etc).
Your actions files would import function from those services and call them. If you decide later on to swap out your networking library, you wouldn't have to change your actions.
You could use an API middleware, either redux-api-middleware or something of your own (it isn't very hard to write one).
Then, for example, your action creators could return actions like
{type: 'API_GET', url: '/api/userList', nextType: 'USER_LIST'}
...that would be later handled by a middleware that would send the actual request and then dispatch a new action like:
{type: 'USER_LIST_FETCHED', status: 200, payload: [{id: 1, ...}, ...]}
{type: 'USER_LIST_FAILED', status: 404, payload: {message: '...'}}
I pretty much follow the pattern of the actions in the redux tutorials for Async Actions. It makes most sense to me to keep everything async in the actions -- away from both the components and the store/reducers.
I also use Redux Crud to standardize the actions related to network actions.