Why SHOULD payload be an error object? error: true should be enough about flux-standard-action HOT 5 OPEN

@everdimension after using FSA for a while, yes I do agree with you that dispatched action is different.

For one thing, Error is not that serializable (JSON.stringify(new Error('abc')) gets an empty object string {}).

But on the other hand, putting Error (in a serializable format) in meta is not a good idea because meta can be used by middlewares and you run the risk of overwriting that information.

IMO, { payload: <serializable error>, error: true } vs { error: <serializable error> } is about the same. You have to check for if (action.error) {...} anyway.

As for your first suggestion — extending the javascript Error object — I have to think about it, but I'm not sure it's such a good idea.
My understanding is that you should extend an Error instance with custom information only for debugging purposes, not to pass it around as data.

I do see the value of carrying custom information by extending Error is very valuable.

The are three consumers of an Error: some Engineer, some logging mechanism, and the JavaScript engine.

The JavaScript engine doesn't care, it just spilled out the error.
The logging mechanism does care. Theerror.message often lacks the context for the logging to produce any meaningful message.
The engineer does care. It is never a good idea to try handling the error by parsing the error message. That is fragile, unreliable, and slow.

from flux-standard-action.

How do you carry the "request original data" in case of error? I was using payload to track id's of affected resources, but following this guide the payload attribute should be an error.

My state:

export interface Item {
  objectID: string,
  listPrice?: number,
  dealPrice?: number,
}

export interface State {
  [objectID: string]: Item;
}

My previous reducer:

export default function reducer(state: State = {}, action: ActionTypes): State {
  switch (action.type) {
    case ITEM_FETCH_REQUESTED:
    case ITEM_FETCH_SUCCEEDED:
    case ITEM_FETCH_FAILED:
      return {
        ...state,
        [action.payload.objectID]: item(state, action), // <= how to get the objectID of a failed entity?
      };
    default:
      return state;
  }
}

from flux-standard-action.

You can extend Error to add more information to it.

IMO, as with rejecting promise, the rejecting parameter should be an Error.

In fact, I believe rejecting promise MUST reject with an Error.
That's how it works in async/await situation:

function foo() {
  return Promise.reject(new Error('something'))
}

async function boo() {
  try {
    await foo()
  }
  catch (err) {
    // `err` should always be of type `Error`
  }
}

https://stackoverflow.com/questions/42453683/how-to-reject-in-async-await-syntax/42453798#42453798

from flux-standard-action.

@unional

In fact, I believe rejecting promise MUST reject with an Error.
That's how it works in async/await situation

I see your point, but I'd say that the dispatched action is of different nature compared to a promise chain.
When using async or promises, you can easily keep the initial request object in scope and access it in the catch block.

On the other hand, the idea of flux actions is that they can come into your app independently. When you're receiving an action, you usually do not have another action (which might've been an "initiator" in some sense) in scope or in a closure.

Dispatched action should be sufficient in a way that a reducer can describe the state update accordingly. Making payload a faceless error strips this crucial information from the action.

As for your first suggestion — extending the javascript Error object — I have to think about it, but I'm not sure it's such a good idea.

My understanding is that you should extend an Error instance with custom information only for debugging purposes, not to pass it around as data.

from flux-standard-action.

For one thing, Error is not that serializable (JSON.stringify(new Error('abc')) gets an empty object string {})

btw, regarding this, I have created iso-error to mitigate the problem.

from flux-standard-action.