1

I'm building my first React front end and see a number of conventions for messages sent via the Dispatcher. e.g.

{
  type: ActionTypes.RECEIVE_RAW_MESSAGES,
  rawMessages: rawMessages
}

https://github.com/facebook/flux/blob/master/examples/flux-chat/js/actions/ChatServerActionCreators.js#L21

and

{
  source: 'VIEW_ACTION',
  action: action
}

http://facebook.github.io/react/blog/2014/09/24/testing-flux-applications.html#putting-it-all-together

What is the best message format to use & why?

pherris
  • 17,195
  • 8
  • 42
  • 58
  • Like @BinaryMuse said in his answer, you can use whatever format you like, as long as the store knows what to do. And there is no real point in the source property -- see also: http://stackoverflow.com/questions/26154695/flux-dispatcher-view-actions-vs-server-actions/26164414 – fisherwebdev Apr 17 '15 at 09:52
  • Thx @fisherwebdev I was thinking I might wrap messages with a source so I can extend a client timer holding session timeout when the browser interacts with the server, but I suppose could just as easily dispatch new actions. – pherris Apr 17 '15 at 14:01
  • Or source can be a property of the action itself. – fisherwebdev Apr 18 '15 at 01:03

2 Answers2

3

The short answer is, it probably doesn't really matter—as long as your stores look for the right data. I always use the following format:

{
  type: 'ACTION_TYPE', // usually defined by a constant
  payload: { ... } // a payload of JSON serializable types
}

If your app needs to distinguish between actions that are initiated by the user and actions that come from the server or some other source, you may considering adding a source key; I personally use separate action types or data within the payload for this purpose.

I always make payload an object (never a raw value) so that data can be added easily without changing receiving sites. For example, instead of

dispatch({type: ACTION_TYPE, payload: id})

I would recommend

dispatch({type: ACTION_TYPE, payload: {id: id}})

Of course, some of this may be dictated by which flux implementation (if any) that you use. The Facebook dispatcher is very agnostic (you can send pretty much anything you want), but some implementations require specific keys (like type, etc).

Michelle Tilley
  • 157,729
  • 40
  • 374
  • 311
  • Thank you. I ended up using actionType for broad action categorization and action.status for more granular state. `{ actionType: Constants.api.user.LOGIN, action: { params: {}, response: {}, state: Constants.request.COMPLETE } }`. Since I am using the vanilla Dispatcher as of now, I may extend this model to include UI vs API triggered events with another attribute added by calling specific Dispatcher methods. I am creating this object in a lot of places however (code and tests), so I also see a utility class in my future. – pherris Apr 15 '15 at 17:15
  • and +1 for this "I always make payload an object (never a raw value) so that data can be added easily without changing receiving sites." I totally agree. – pherris Apr 15 '15 at 17:16
  • I wouldn't add anything more to the action other than the TYPE and PAYLOAD. I've been working in flux since it was introduced and it can lead to problems real quick. Stuff like 'state' are actually different actions. – frostymarvelous Apr 12 '16 at 17:17
  • Just to clarify. To login, dispatch an action with type LOGIN_PROCESSING, then after completion, dispatch LOGIN_SUCCESS or LOGIN_FAILURE. The payload can contain the extra stuff like the error message etc. – frostymarvelous Apr 12 '16 at 17:18
0

Flux Standard Action is a project to standardize Flux actions.

In short, an action must have a type, and may have a error, payload, or meta.

Examples

{
  type: 'ADD_TODO',
  payload: {
    text: 'Do something.'  
  }
}

For an error:

{
  type: 'ADD_TODO',
  payload: new Error(),
  error: true
}

The meta field is indented for "any extra information that is not part of the payload". I haven't seen this used, so I'd try to stick to payload.

cgenco
  • 3,370
  • 2
  • 31
  • 36