Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Non-FSA actions cause handleAction reudcers to emit confusing error messages

See original GitHub issue

In #141 an invariant checks that each action is an FSA before attempting to process it. When attempting to upgrade to 1.0.0, this causes issues in a large app I am working on where our more recent actions follow the FSA pattern, but older actions do not. When those older actions were triggered, the invariant caught them and prevented the reducers that are actually intended to process that type of action from receiving it.

This is at odds with allowing larger apps to migrate incrementally; we need to update all of our actions / reducers to upgrade.

Further, the error message generated by #141 was actually misleading; the actions had a type attribute, which is a stronger redux convention than FSA, but had attributes that aren’t on the FSA whitelist (https://github.com/acdlite/flux-standard-action/blob/master/src/index.js).

It seems like there are a couple decisions to be made:

Should using this package require that all of your actions be FSA?
Should using this package require that all of your actions have a type?

If the answer to (1) is “yes”, then we can close this issue (although we should probably document this in the README).

If the answer to (1) is “no”, then I can use an answer to (2) to write a PR. Let me know what y’all think.

IMO, reducers created by handleAction should only complain if an action is emitted with a type that they are listening for that is not an FSA. That opinion seems to be at odds with this request, which makes it sound like someone encountered an incident where they were emitting an action without a type that was hard to diagnose. In that scenario, it seems like the action wasn’t created via createAction, and so I sort of expect that onus to fall on the developer (although I could certainly be convinced that there are better options available).