Flux standard action compliance?

[Qrysto]

What if I want my actions to be FSA-compliant? Some libraries such as redux-promise are best used with FSA, and having an "optimist" property does not work well for me personally.

[ForbesLindesay]

Fork this library and write your own? You haven't explained why it doesn't work for you. It's very unclear that FSA is a good idea, or even widely used.

[yched]

FSA is notably used by https://github.com/acdlite/redux-actions https://github.com/pauldijou/redux-act so it is kind of widely used I guess ?

[mwalsher]

+1

[necolas]

Having the same issue in an app that requires actions to be FSA. It would be nice to be able to configure where the optimist data is added for those of us using FSA to bring some consistency to action shape.

[threepointone]

You simply have to replace the bit of your redux stack that checks fsa shapes, with one that accepts an optimist key. Here's an example of a redux middleware that does so - https://gist.github.com/threepointone/bef4a28d577707af38b2

[timkindberg]

Maybe put optimist info into the meta field?

[quicksnap]

Looking at the code, the optimist reducer factory could be modified to accept a second param, a function mapping the action to the optimist key, and defaulting to action.optimist.

Something like this: https://github.com/ForbesLindesay/redux-optimist/compare/master...quicksnap:patch-1

The above is incomplete, but I think it could be made backward-compatible with current API.

I like using FSAs personally, but I haven't found non-FSAs to cause me any trouble. Food for thought if anyone wants to complete the PR.

[ForbesLindesay]

@quicksnap I would be willing to accept that approach if completed along with a pull request since it potentially has value beyond FSAs.

[quicksnap]

Might as well whip it up! Probably won't take too long.

[quicksnap]

PR #9

[jchook]

If non-FSA actions break your middleware, I would consider that a bug with your middleware.