Which design decisions are you thinking of?

Mostly that updates can only happen on explicit changes to the state. Also a React application doesn't acknowledge the possibility of a component existing which is not a React component. I most recently ran into this issue when trying to add an OpenLayer map to an application. In a vanilla JS application it's trivial, but React was difficult to coerce into breaking it's own rules to accommodate it.

Elm solves this particular issue well with Ports [1]. It respects the possibility that there may be things going on that haven't been explicitly planned for.

    actions are insanely laborious to construct

On a second read through, this is edging on hyperbole. Maybe a more honest presentation of the facts is that Redux actions grow tedious to write. You start with an action type declaration:

    export const SOME_ACTION = "SOME_ACTION";

Then you create an action creator:

    export function performSomeAction(data) {
       return {
          type: SOME_ACTION,
          data
       }
    }

And then of course you need to write a case statement in a reducer to deal with the data and somehow effect the state.

It's tedious because it's trying to recreate the pattern matching functionality of passing union types around in functional languages. In SML, Haskell, Elm etc. you can elegantly decompose and consume types with case statements and pattern matching, which are built into the languages [2, 3].

[1] https://guide.elm-lang.org/interop/javascript.html [2] https://stackoverflow.com/a/14604042 [3] http://www.cs.cornell.edu/courses/cs312/2004fa/lectures/lect...