You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sorry if you've addressed this already, I searched but came up empty.
Why is it that rather than dispatching a new action for success/failure, you instead just pass it to next? I definitely understand the request one being passed to next but why the other two? It renders previously provided middleware useless for those actions then.
For some context, my use case is that I've got an authentication middleware before redux-api-middleware, which intercepts RSAA actions to add an auth header, but I also wanted said middleware to handle the success action in the case of a login request.
I've never run into an issue outside of this use case so it's not a huge deal, I can work around it, but I was just wondering if there was some reason behind this architecture decision, whether it be a best practice or something else?
I've dispatched a lot from custom middleware when handling side-effects but I'm also not maintaining open source middleware being used by a lot of people, so maybe there's considerations you're taking that I've never thought of. Am I doing it wrong? Is there a wrong/right way here?
The text was updated successfully, but these errors were encountered:
Good question :). I ran into this early on as well, but eventually came to appreciate the current functionality, since passing to the next middleware can avoid the previous middleware in the chain, rather than always starting over from the top. We can always attach another middleware after redux-api-middleware to process the resulting FSAs, and dispatch a new action or perform a transform (if necessary) and pass along to next middleware. This avoids having the "request/response" FSAs from being passed to unnecessary middleware, like redux-api-middleware itself.
I often use redux-observable along with redux-api-middleware for larger scale things or with legacy rpc/rest apis, which you might also find useful for these sorts of use-cases :). Can get a little tricky for optimizations, but I added an RFC issue for "callable RSAA" utils which has helped me in my projects. If interested, here is that issue:
Sorry if you've addressed this already, I searched but came up empty.
Why is it that rather than dispatching a new action for success/failure, you instead just pass it to
next
? I definitely understand the request one being passed to next but why the other two? It renders previously provided middleware useless for those actions then.For some context, my use case is that I've got an authentication middleware before
redux-api-middleware
, which intercepts RSAA actions to add an auth header, but I also wanted said middleware to handle the success action in the case of a login request.I've never run into an issue outside of this use case so it's not a huge deal, I can work around it, but I was just wondering if there was some reason behind this architecture decision, whether it be a best practice or something else?
I've dispatched a lot from custom middleware when handling side-effects but I'm also not maintaining open source middleware being used by a lot of people, so maybe there's considerations you're taking that I've never thought of. Am I doing it wrong? Is there a wrong/right way here?
The text was updated successfully, but these errors were encountered: