Support for bluebird about redux-promise-middleware

[pburtchaell]

I'm busy for the rest of the week, but will look into this on Saturday.

[tomatau]

We follow FSA which describes the action to contain the error instance in it's payload, not sure how the two can align.

[pburtchaell]

Could it be implemented as a configuration option? I would be open to that, but since I do not use Bluebird I wouldn't want to implement it. Would you be open to making a PR @mlucool?

[mlucool]

Sure I can take care of it

[mlucool]

@tomatau What I suggested is inline with FSA and bluebird - both want error objects. We should have a data carrying Error in the library that stores data in a known place. Let's call this ErrorWithPayload instead of PromiseError?

class ExtendableError extends Error {
    constructor(message) {
        super(message);
        this.name = this.constructor.name;
        this.message = message;
        Error.captureStackTrace(this, this.constructor.name)
    }
}
// Use this with a promises when you need extra data:
// https://github.com/petkaantonov/bluebird/blob/master/docs/docs/warning-explanations.md#warning-a-promise-was-rejected-with-a-non-error
class ErrorWithPayload extends ExtendableError {
    constructor(message, {payload}) {
        super(message);
        this.payload = payload || {};
    }
}

const e = new ErrorWithPayload('foo', {my: 'data'});
console.log(e instanceof Error); // true - which is what FSA requires

// Usage
{
type: "MY_TYPE",
payload: new Promise((resolve,reject) => reject(e));
}

We pass all of e (i.e. the ErrorWithPayload) which is of type error and aligns with both. This provides a mechanism to trivially pass along more data.

Do you agree this fits with FSA @tomatau ?

[tomatau]

To me this seems to be more the responsibility and choice of people using the middleware rather than something that needs to be supplied? There would be other packages/utilities that aid in the creation of error objects.

I feel the error object payload should be an instance specific to the use case of the action rather than specific to the API of the middleware.

[pburtchaell]

After seeing more of what you want to add, I agree with @tomatau here. I would argue this middleware should not be responsible for creating an error object since the error itself doesn't actually originate directly from the middleware. In most cases errors will be traced to the function that returns the promise, e.g., a network quest with Fetch() or something of the like. The job of this middleware is to handle the error supplied by the promise and then fire the correct actions, e.g., fulfilled or rejected.

[pburtchaell]

Right now our rejected actions provide the error property with a value true in the rejected action object. I think what we should make the value of that property the Error object instead of a boolean. This still follows FSA. Thoughts @tomatau @mlucool?

[mlucool]

https://github.com/acdlite/flux-standard-action seems to indicate that error should only ever be set to true. "If error has any other value besides true, including undefined and null, the action MUST NOT be interpreted as an error."

I was not suggesting the middleware do anything extra with the error object I am proposing but expose it so everyone who wants to pass data in reject does not need to rewrite this. I can also write a 20 line lib which does the same. I only suggested it here because of how useful it is with promises and if we wanted to do further processing, it would then be standardized where the extra data is. If it's not a good fit, I am not adamant this is the right place and we can close this issue.

[tomatau]

I'm still not fully understanding the problem here.

const myActionCreatore = () => ({
  type: 'EXAMPLE',
  payload: {
    promise: new Promise(async (resolve, reject) => {
      // do stuff
      reject(
        new MyCustomError('example error payload', { extra: 'data' })
      )
    })
  }
})
/*
 {
  type: 'EXAMPLE_REJECTED',
  payload: new MyCustomError('example error payload', { extra: 'data' })
  error: true
 }
 */

This doesn't seem like a library is needed to reject with a custom error payload of an error instance.

You want us to provide a hook to modify the whole payload to be an error object when we resolve an error action object? It's important to note that both fulfilled and rejected actions are resolved, as we catch the error in the middleware to stop uncaught errors and allow it to be passed to the reducer chain.