The question is as much how exhaustive you want your Redux usage typed, and also how much you want to stick to the "action creator" pattern. A lot of the action creator ceremony is to avoid throwing the wrong types of data to Redux dispatch and make it easier to refactor things when the data requirements for an action change. Typescript handles a lot of that no matter what, and you can lean on the Typescript type system more and the "action creator" pattern less, but it won't look "Redux enough" to more JS-focused developers and that may or may not be a source of friction.

Which is a long way around to: the pattern in that recipe is a good one, it's quite exhaustive in making sure everything is typed, and it's quite familiar to almost any Redux dev you will meet whether they come from JS or TS. You can get away with other patterns/recipes if you want looser typing or "looser redux", based on the compromises you are willing to take, but currently there's no strong recommendation for any such alternative pattern because the common recipe is "good enough", even if it has lots of little bits of extra "ceremony". (Ceremony isn't necessarily a bad thing, sometimes those rituals are helpful in getting your thoughts down and making sure you have everything you need planned out.)

But that's also part of why the example in the author's post is unfair to Typescript. It's as strict on types as the Typescript pattern, but it's "looser redux". It sort of has action creators, but those aren't proper functions from a JS perspective because they are type constructors that don't properly exist in JS. They also don't exactly correspond to/produce the usual sort of "plain JS objects" that Redux expects when dispatching ({ type: "DISCRIMINATOR_STRING", … }), which will worsen and even in some cases may break Redux debug tools/experiences.

(Semi-related, there is a Stage 1 proposal for pattern matching in front of TC39 that would also help reduce the switch case that TS needs to pattern matching closer to the ReasonML example. TS sticking to Stage 3+ proposals now means that it won't get some of these sort of nice to have things until JS does.)

Okay, thanks for elaborating. I think the part I had overlooked was the variant constructor not being a function. I had mentally mapped that as a `dispatch` call with the variant being the payload. But, yeah, it looks like the author either made a mistake or took a shortcut there.

BuckleScript (ReasonML's-to-JavaScript compiler) has an annotation that automatically creates functions from variant constructors. E.g.:

    [@bs.deriving {accessors}]
    type msg =
    | Increment
    | Decrement
    | Reset
    | Set(int);

    let action = set(2);

I don't have experience with Redux so I cannot comment on that, but I do believe my rewrite is equivalent to the ReasonML example (it should express the same thing and still be typesafe).

While I'm sure the author did not intentionally try to make TypeScript look bad, (imo) they didn't put enough effort to make it look good either. There's a lot more to TypeScript that this post fails to mention. ReasonML is a good language (I think OCaml was just fine though), but TypeScript is good too.

The author says "ReasonML is everything TypeScript tries to be (and a bit more) without all that JavaScript weirdness.", but I strongly disagree. Embracing "all that JS weirdness" is the whole point of TypeScript, and what makes it so successful. Unlike most typed languages, TypeScript (for better or for worse) adapts its type system to the developer's code, not the other way around. This is why its type system is much more expressive than many other type systems including ReasonML's.