Support Flux Standard Actions (FSA)

[jokeyrhyme]

Flux Standard Actions are a specification found here: https://github.com/acdlite/flux-standard-action

The redux documentation itself mentions FSA: http://rackt.github.io/redux/docs/basics/Actions.html

Other than type, the structure of an action object is really up to you. If you’re interested, check out Flux Standard Action for recommendations on how actions could be constructed.

Is it worth making FSA an option or perhaps switching over to it?

[gajus]

@jokeyrhyme CRC is a broader standard than FSA. FSA is a legacy driven standard, https://github.com/acdlite/flux-standard-action/issues/15.

What is the reason you want to use "type" property instead of "name"?

[jokeyrhyme]

Well, "name" feels like it could be action instance specific, where as "type" feels like a value that multiple similar actions might have in common.

For example:

{
  type: 'ACTION_WITH_VALUE',
  payload: { value: 'foo' }
}

{
  name: 'ACTION_WHERE_VALUE_IS_FOO',
  data: { value: 'foo' }
}

All this is just words anyhow, but that's sort of the difference between "name" and "type" for me.

Also, while this doesn't negate your legacy argument, DOM Events also have a "type" property, and there are certainly similarities between Flux Actions and DOM Events:

• https://developer.mozilla.org/en-US/docs/Web/API/Event/type

[jokeyrhyme]

To try another way of articulating this...

To me, "type", "class", "shape" ( https://facebook.github.io/react/docs/reusable-components.html )... when Actions have this in common, I understand that I can look in the same place for the data, and that they have a common purpose.

To me, "name", "label", "id"... those terms by themselves don't give me an idea about purpose or shape or interface or contract or anything.

[jokeyrhyme]

I do think "data" makes more sense than "payload", personally, but FSA is older than CRC, and there seems to already be more people using that style:

• https://www.npmjs.com/package/flux-standard-action
• https://www.npmjs.com/package/canonical

If the only difference is the name, then why not just use the same names that everyone else is using, and focus on the other parts of CRC that add value?

[gajus]

@jokeyrhyme Leave this with me. I am busy designing CONSTRUCT method spec and implementing it in the react-immutable and react-immutable-examples. https://github.com/gajus/canonical-reducer-composition/issues/1

Will get back to this before the end of the day, read all the arguments again, do some research and decide on what should be the way forward. I you have anything to add in the mean time, that'd be very useful.

[jokeyrhyme]

For some context, I'm currently using my own minimal combineReducers() function:

• https://github.com/jokeyrhyme/wow-healer-bootcamp/blob/master/utils/combineReducers.js

I came by this project after looking for an implementation that's closer to Redux's in terms of error detection and developer assistance, which led me to redux-immutable, and then here.

I'm very new to Redux and Immutable, and only slightly less new to Flux. I'm far from an expert, and I'm not sure how much sense I'm making. :P

[ahdinosaur]

If the only difference is the name, then why not just use the same names that everyone else is using, and focus on the other parts of CRC that add value?

:+1: to CRC being compatible with FSA. while CRC might be more right in using name and data over FSA's type and payload, it's not going to help CRC be successful if 'being right' causes unnecessary breakages and inability to use the ecosystem of FSA-compatible libraries.

[ahdinosaur]

btw, forked canonical and redux-immutable to be compatible with FSA, just for playing around with at the moment.

[gajus]

The solution is to use middleware for converting between the two standards.

https://github.com/gajus/redux-convention#middleware

[gajus]

https://github.com/gajus/canonical-reducer-composition/blob/master/README.md#flux-standard-action