Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling RequestErrors status codes #178

Open
amangeot opened this issue Mar 19, 2018 · 3 comments
Open

Handling RequestErrors status codes #178

amangeot opened this issue Mar 19, 2018 · 3 comments
Labels

Comments

@amangeot
Copy link

amangeot commented Mar 19, 2018

Hello,
I have been using this middleware for a while without any problem so far. I'm curious how one can handle request errors such as a 502 Bad Gateway globally, in order to differentiate connection issues, from bad gateways.

For example, below is a 502 Bad Gateway, logging actions via a middleware coming after redux-api-middleware.

How can one access the response status code (502) inside a middleware?

Thank you,

image

@amangeot amangeot changed the title Handling RequestErrors Handling RequestErrors status codes Mar 19, 2018
@nason
Copy link
Collaborator

nason commented Mar 22, 2018

Hi @amangeot, three thoughts:

  1. What you're seeing here is a design decision that would be changed by Dispatch failure FSA when fetch fails #175

    • Right now, if a request fails due to network error or malformed request a second REQUEST type will be dispatched with an error flag. With that change, an ERROR type would be dispatched.
  2. A fetch option was recently added that would allow you to catch specific response codes more easily -- https://github.com/agraboso/redux-api-middleware#rsaafetch

  3. You could use a custom payload function like https://github.com/agraboso/redux-api-middleware#failure-type-descriptors

Please let me know if any of these were helpful!

@nason nason added the question label Mar 22, 2018
@amangeot
Copy link
Author

amangeot commented Dec 5, 2018

Thank you @nason for the v3, it looks easier to catch network errors from failure type descriptors

Do you have a suggestion on how to refactor network error handling, for example by checking if the fetch response is undefined, without having to edit the 112 RSAA definitions we have?

Can we inject fetch option via a middleware for instance?

@amangeot
Copy link
Author

amangeot commented Dec 5, 2018

I went for a middleware to work on RSAA failure type descriptor's meta, which I intercept later with another middleware to handle errors. Here is the code that works with v3 fetch errors, with failure types being dispatched in network failures:

import { RSAA } from 'redux-api-middleware'

import { FETCH_FAILURE } from './apiMiddlewareExtension.constants'

const REQUEST_TYPE_DESCRIPTOR = 0
const SUCCESS_TYPE_DESCRIPTOR = 1
const FAILURE_TYPE_DESCRIPTOR = 2

/**
 * Inject meta field to intercept fetch failing (no response) on RSAA actions
 * *
 * For failure type descriptor, see
 * @see {@link https://github.com/agraboso/redux-api-middleware#failure-type-descriptors|GitHub}
 */
export default function apiMiddlewareExtension ({ dispatch, getState }) {
  return (next) => async (action) => {
    if (RSAA in action) {
      const failureDescriptor = action[RSAA].types[FAILURE_TYPE_DESCRIPTOR]
      const meta = failureDescriptor.meta

      return next({
        [RSAA]: {
          ...action[RSAA],
          types: [
            action[RSAA].types[REQUEST_TYPE_DESCRIPTOR],
            action[RSAA].types[SUCCESS_TYPE_DESCRIPTOR],
            {
              ...(typeof failureDescriptor === 'string' ? { type: failureDescriptor } : failureDescriptor),
              meta: (action, payload, res) => {
                const metaToInject = !res ? { [FETCH_FAILURE]: true } : undefined

                if (typeof meta === 'function') return { ...meta(action, payload, res), ...(metaToInject || {}) }
                else if (meta) return { ...meta, ...(metaToInject || {}) }
                else return metaToInject
              }
            }
          ]
        }
      })
    }

    return next(action)
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants