Open dvshnt opened 8 years ago
That's actually a very interesting proposal. In fact, I had to use an ugly hack in the testing of a boolean [CALL_API].bailout
property — it doesn't return anything, so I have a setTimeout
there —, which bothers me. Maybe your idea is a better way of handling [CALL_API].bailout
. Its current behavior comes right out of the real-world
example in the redux
repo, and I have never really thought it over.
I'm very interested in seeing what your implementation will be, so please report back. I'll think about it in the meantime too. The fact that redux-api-middleware
is now in the 1.0.0-beta
stage is a happy coincidence!
Am going to think about this bailout implementation though. One nebulous idea surrounding it is how to differentiate a bailout from other standard errors...
First, do you have a PR to demonstrate this? I'm not sure what you mean but that may be because i haven't gotten to the Auth part.
Second, i see you added a schema parameter to getJSON()
in your fork and wonder if thats worth including. Do you use it in production this way?
Use Case: Using Auth middleware to check if user logged in (via a Token). In the case they are not logged in (there is no Token or it is expired), should be able to throw an error and get out before making the request that you already know will fail.
Maybe this defeats purpose of bailout, but think I am going to fork and implement..