What is the Flux Standard Action convention for structuring a payload?

Question

I want to use the Flux Standard Action standard to write the actions for my Redux app, and I'm unsure how the payload itself should be structured. The example given on the Flux Standard Action github repo is:

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

Now what if I'm passing multiple pieces of information in my payload? In a simple todo app for example, say my payload passes a todo object (rather than just the todo's text in the above). I'm unsure whether it should be structured like this:

{
  type: 'ADD_TODO',
  payload: {
    title: 'Do something.',
    priority: 'HIGH',
    completed: false
  }
}

Or whether a todo object should be nested inside the payload, like this:

{
  type: 'ADD_TODO',
  payload: {
    todo: {
      title: 'Do something.',
      priority: 'HIGH',
      completed: false
    }
  }
}

It looks like the difference is whether the payload is meant to BE or to CONTAIN the data consumed by the reducers. Put another way, whether my reducers should expect a certain type of data as the payload (the payload IS a todo object), or whether they should specify what they're getting out of the payload (the payload CONTAINS a todo object).

Thaadikkaaran · Accepted Answer · 2016-12-05T09:09:08.457

4

In computing and telecommunications, the payload is the part of transmitted data that is the actual intended message. The payload excludes any headers or metadata sent solely to facilitate payload delivery.

As per above quote, payload should be just the data your reducer looks for. something like,

{
  type: 'ADD_TODO',
  payload: {
    title: 'Do something.',
    priority: 'HIGH',
    completed: false
  }
}

Your reducer would generate the new state based on the action which you pass and our action is responsible to tell the reducer that what needs to be done.

When your reducer gets an FS Action which has type: 'ADD_TODO' , it knows that it has to add a todo and the todo is with payload property.

So it is explicit that your actions payload would be a todo. It is not necessary to tell that what is there in the payload. Because the FSA itself tells that this action contains a payload which is of type todo.

edited Dec 05 '16 at 09:09

answered Dec 05 '16 at 08:22

Thaadikkaaran

5,088
7
37
59

Thank you, that makes a lot of sense. One more question - in [this answer](http://stackoverflow.com/a/29632652/5914982), Michelle prefers to "always make payload an object (never a raw value) so that data can be added easily without changing receiving sites" and would always do payload: { id: id } rather than just payload: id. Would you agree or disagree with this in a scenario such as 'REMOVE_TODO' where only the id would be needed? – ailurus Dec 06 '16 at 04:54
I do agree with Michelle's answer. With `REMOVE_TODO` action, your reducer knows that the action has the payload of type `todo` with ignored properties. Because `REMOVE_TODO` action needs only `id` property. – Thaadikkaaran Dec 06 '16 at 05:36
I see, the whole idea of Flux Standard Actions is making a lot more sense to me now. Thank you for your answers! – ailurus Dec 06 '16 at 07:51
...in other words, `payload` can contain anything you want that makes sense in the context of your reducer or middleware, right? – Todd Feb 21 '18 at 18:15

What is the Flux Standard Action convention for structuring a payload?

1 Answers1