3 ms·
I'm writing TS components daily, I'm not sure why, but I never encountered any of the issues you mentioned. I can only agree that typing HOC was hard when I di
by ponyous 8y ago
I'm writing TS components daily, I'm not sure why, but I never encountered any of the issues you mentioned.
I can only agree that typing HOC was hard when I did it the first time.
- littlecranky67 8y agoThen let me ask you: How do you type .defaultProps? How do you type the "state" property on the class? If you did explicitly repeat the type already specified in the Generic Type Argument: Component<IProps, IState> you would know what I mean with too verbose (you have to repeat a type that could be infered, but due to TS restrictions isn't able to). If you did not repeat the type for those fields, you lost typesafety without noticing it. You can then go ahead and assign { foo: "bar" } to state (or use it in setState) and will not get a compilation error (which you shold as foo is not a known property for your state). And I sure as hell bet you do not use "strict" compilation in TS, which opens typing issues everywhere.
- ponyous 8y agoWe are using strict mode. If I do `setState({ undefinedStateKey: 123});` it warns me. Just checked. It may be linting not TypeScript. We have IState defined only as Generic Type Argument. We define defaultProps as static in class. And you are right defaultProps are not being type-checked against Generic Type Argument IProps.
- littlecranky67 8y agoWell if you are in strict mode, it should break the build with an error, not a warning. This seems to be a linting rule. But you see the issue with defaultProps and state here. You can basically assign anything to defaultProps or use in setState() even so you were explicit of the props type in the Generic Type Argument.
- deleted 8y ago[deleted]