1. Redux docs encourage you to use @redux/toolkit which drastically reduces boilerplate. And even if you do opt into using vanilla redux: Typescript for some time now has supported string literal types which render enums obsolete almost.

2. Mutability is not at all a problem. Those types of bugs are obvious. On the other hand, mutability allows for a type of fine-grained control you will absolutely need. It is Javascript after all.

3. Redux _does_ allow "users to create complicated compounded subscriptions in a performant way using materialized views" which is a rather convoluted way of saying "memoize derived values." You are looking for the createSelector-API you had been shunning in the opening statement.

4. What in the name of god almighty is this:

        function Component({ children }) {
          const { data, loading, error } = useGetMyData();

          return (
            <div>
              {(function () {
                if (loading) {
                  return (
                <div>loading...</div>
              );
                }
                if (error) {
                  console.error("Uh oh!");
                  return (
                    <div style={{ color: "red" }}>{error.message}</div>
                  );
                }
                return (
                  <>
                    <div>Data:</div>
                    <div style={{ color: "green" }}>{data}</div>
                  </>
                );
              })()}
              {children}
            </div>
          );
        }

We are encouraged to pour yet another layer of abstraction on top of Javascript pulling in clones of the very libraries we had already been using. Only now, our knowledge about performance testing and tuning in ReactJS/Javascript is basically useless.

At this point, why not do away with all "boilerplate" and just use Elm?