Flux-compatible store behaviour?

[simonhildebrandt]

Firstly, cheers for such a great suite of tools. I was particularly pleased to come across the ReduxStore machinery - it's a terrific way to provide an integration point that I'm excited to explore.

Unfortunately it led me down a rabbit hole for a few hours, when a poorly implemented check for FSA-compatibility was silently dropping the actions created by Uppy.

Clearly our problem, of course, but I did wonder - the Uppy actions don't look like the ones generated by other systems, and certainly don't conform to the FSA standard. Would Uppy be interested in a patch that introduces conformance? It seems like it would be a pretty clean change.

Thanks again for all your great work.

[goto-bus-stop]

I think our only difference is that we have a id property on our actions that should be on meta.id for FSA compatibility, right?

I'd be fine with that—it would be a breaking change and we haven't fully sussed out how we want to handle those, so a PR may be in the waiting list for a while.

[kvz]

Perhaps we could add a flag so that people can opt into the new behavior, and then with 2.0 we drop the flag & old behavior, and make the new way the default behavior. If possible, maybe that’s an acceptable route to allow both merging to master rather quickly and maintaining bc, but also enjoy a cleaner code base when 2.0 hits(?)

[goto-bus-stop]

Hmm, I thought that would be hard because the @uppy/store-redux API is split: one part that you give to Uppy, which dispatches actions, and one part that you give to Redux, which handles actions. The reducer part actually doesn't have a way to configure it.

But, we could just dispatch new-style actions and make the reducer handle both variations.

@simonhildebrandt if you would like to send a PR that introduces an opt-in for FSA compliance, it'd be great :)

[arturi]

This has been added to backlog, and we welcome PRs too.