[undecidabot]

Looks like another biased comparison to me. You could easily rewrite the TypeScript reducer example (which fails to compile btw) to be similarly concise while being as safe.

  interface State {
    movies: string[]
  }

  // you may also use { tag: "Action", payload: string }
  // if you prefer something more structured
  type Action =
    | ["AddMovie", string]
    | ["RemoveMovie", string]
    | ["Reset"]

  const defaultState: State = { movies: [] }

  const reducer = (state: State, action: Action): State => {
    switch (action[0]) {
      case "AddMovie": return { movies: [action[1], ...state.movies] }
      case "RemoveMovie": return { movies: state.movies.filter(m => m !== action[1]) }
      case "Reset": return defaultState
    }
  }

  const someAction: Action = ["AddMovie", "The End of Evangelion"]

TypesScript's type system is actually very flexible and advanced [1] compared to most type systems since it had to adapt to the very "dynamic" structuring of JavaScript in the wild.

[1] https://www.typescriptlang.org/docs/handbook/advanced-types....

[hajile]

ReasonML variants are type constructors. Your example completely eliminated all action creators (constructors). Once you add those functions back, most of the type bloat reappears.

I wouldn't want to work on a project where everyone was creating object literals and passing them to dispatch everywhere.

[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).

[mikewhy]

This is what my redux stuff looks like with TypeScript:

    const constants = {
      addMovie: 'movies/addMovie',
    }

    export const addMovie = createAction<string>(constants.addMovie)

    export const reducer = createReducer(initialState, {
      [constants.addMovie]: (state, action: ReturnType<typeof addMovie>) => ({
        ...state,
      })
    })

But this forgoes applying any constraints to `dispatch` / the ability to have one giant union of all possible action types your app supports.

[nirvdrum]

I'm fairly new to both TypeScript and ReasonML (both within the past month). The author's reducer example closely matches that of the official Redux documentation [0], so I'm not really sure it's biased. But, I could buy that it's not a best practice. Absent anything else, I've been using the patterns demonstrated in the docs. Is there a better resource I should be following?

[0] -- https://redux.js.org/recipes/usage-with-typescript

[WorldMaker]

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.)

[nirvdrum]

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.

[yawaramin]

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);

[undecidabot]

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.