[undecidabot]

Yes, I eliminated the action creators. I don't see why they're necessary (maybe there's something about redux I'm missing?). The type constructors of ReasonML cannot be used as functions, so I think my rewrite is fair.

If you insist on having the action creators, they can easily be written as one liners each, which is a lot less bloated than the original example.

  export const addMovie = (movie: string): Action => ({ tag: "AddMovie", movie });

What's the issue with passing object literals? I know it looks a bit hacky and messy, but if it's typesafe (which it is) then it doesn't seem like a real issue.

[hajile]

No action creator is a serious refactor concern.

Let's say you need to update your function signature with an additional, optional parameter with a default value. You can go to the definition of the action creator and change it. Since you've defined an interface for the action object, finding reducers that use it will be reliable and easy.

If such a creator doesn't exist, you must grep your codebase for every instance of the object and ensure they deal with the optional bit. Murphy's Law guarantees that someone will have decided to procedurally generate the object making finding every instance very hard. Next, you have that reducer lookup, but you don't have a shared interface, so you're stuck in grep land once again to find all the reducers.

Finally, copy-pasting an object literal all over generally results in a larger bundle than reusing an action creator which is smaller and also minifies better.

[undecidabot]

If the lack of action creators is a serious concern, then the one-liner-each action creator I suggested should be sufficient without adding much bloat. How would the ReasonML example deal with that change though? Can the variant constructors take in optional parameters?

Using Murphy's Law is not very convincing. Even with action creators Murphy's Law guarantees someone would have just constructed the objects manually anyways. Having to grep the tag is not ideal, but it's not likely to be a problem in practice.

I doubt that the bundle would be significantly larger (especially after compression). Using actions creators introduces additional (function call) overhead too (and that would be insignificant as well).