Why SHOULD payload be an error object? error: true should be enough

I think this is quite limiting.

You say this —

• An action whose error is true is analogous to a rejected Promise

Isn’t that enough? What if I deal with a server that sends helpful error code and messages in case of failure? For example a 401 response may include something like this:

{
  "code": "WRONG_PASSWORD",
  "message": "Password field should not be empty"
}

So I naturally dispatch this object as payload and set { error: true }.

I guess what you’re implying is that I should put this error object inside the meta property. This seems contradictory to me. This is object is obviously payload.

---

Another thing that bothers me is that I can’t find a payload of type Error useful for anything. It can only hold a string, so it’s pretty useless to keep in state, isn’t it? (not to say that strings are useless, but you can see that we could pass much more information about the error)

[unional]

@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.

[wedneyyuri]

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;
  }
}