createAction #1 #2 This is a disaster part of typescript that will doom you all. Through years and languages I made an observation, and it is: If you give a w

createAction #1 #2 This is a disaster part of typescript that will doom you all. Through years and languages I made an observation, and it is: If you give a way for smart people to create a horrible mess, they will internalize it eventually. Sendmail.cf, template meatprogramming, #define hell, etc. Typescript “type manipulation” is one of these ways. It may seem very cool that you can define base types and then extend and reshape them in derivatives all you want. But types are not about solving puzzles in one go declaratively, they are about helping developers to understand which code may be incorrect. There is nothing wrong with declaring all the derivatives by copying type code and modifying it, because if there’s inconsistency, it will be caught later in tests, in interfaces, in your own code. Yes you create a dynamic structure of types, but it goes beyond human limits to understand or debug it. One way to fix that is “type assertions”, based on the same principle. E.g. instead of declaring type B as a programmatic derivative of type A (and/or/with dozen of type metaprogramming routines), you just write B as it is and then assert that B maps to A as designed. Or make an IDE do this for you automatically. These assertions will still be hard to read, but the resulting type B will remain both understandable and correct. Also, separately, please stop making polymorphic interfaces like “if you pass an object with key X after an object with key Y, that means mode of operation A, otherwise it’s mode B unless there is an array of numbers before the argument of type T, then it’s mode C”. They may look cool in readme.md, but are hard to remember and work with on both sides of an interface.