Description
Contrary to the documentation, the current implementation dispatches two consecutive request FSAs when a network error occurs.
In README.md it says in section "Lifecycle", bullet point no. 3:
Now that redux-api-middleware is sure it has received a valid RSAA, it will try making the API call. If everything is alright, a request FSA will be dispatched with the following property: (…)
(…)
If such an error occurs, a different request FSA will be dispatched (instead of the one described above). It will contain the following properties: (…)
The important thing to note here is "a different request FSA (…) instead of the one described above".
However, the actual code in src/middleware.js sends two request FSAs in case of exceptions thrown during the fetch call:
// We can now dispatch the request FSA
next(await actionWith(
requestType,
// (…)
));
try {
// Make the API call
var res = await fetch(endpoint, { method, body, credentials, headers });
} catch(e) {
// The request was malformed, or there was a network error
return next(await actionWith(
{
...requestType,
// (…)
},
// (…)
));
}This is problematic as we now cannot be sure which of the two request FSAs is which, or rather: once the non-error request FSA has fired, we should be able to assume that the request is either handled successfully, i.e. a success FSA shows up, or fails with a failure FSA. Receiving another request FSA, now with error set, is counter-intuitive (and doesn't match the documentation).
However, I'm not really sure how best to proceed from here. Since the fetch call can fail for all kinds of reasons, even late in the request (server accepted but then closed connection unexpectedly), it seems impossible to simply delay the first, non-error request FSA until we can be sure that no error will be thrown.
Instead, we should probably always send a failure FSA, i.e. both when the server responds with a status code other than 2xx and when a network error occurs. In this case, it would be sufficient to change the documentation and simply replace requestType in the code above with failureType.
Incidentally, this seems to also match the documentation regarding Failure Type Descriptors where the code sample shows the following if-check:
meta: (action, state, res) => {
if (res) {
return {
status: res.status
statusText: res.statusText
};
} else {
return {
status: 'Network request failed'
}
}
}In the current implementation, the res argument to meta is always set. With the proposed change, it would either be set (server responded with code other than 2xx) or unset (network error occurred).
In case this issue is accepted, please let me know if I should prepare a pull request for the proposed change (documentation and code).