4 ms·
> Don't use the `any` type The problem here is two-fold: 1. Culture and existing code. Popular libraries use any when they should be using unknown or just not
by frenchyatwork 7y ago
> Don't use the `any` type
The problem here is two-fold:
1. Culture and existing code. Popular libraries use any when they should be using unknown or just not de-serializing stuff and making you explicity parse it yourself. The reason why these are popular is because culture and because of #2.
2. Creating type guards is a pain, especially if you're trying to go from unknown to something with a complex structure. If types were something you could reflect on in run time, like most other interpreted languages, this would be a lot easier.
- no_wizard 7y agoTo address culture, someone has to start doing it better, no reason it can't be those who know there is a better way, so I treat that as a red herring myself. You could always make a strongly typed wrapper around a library, for instance. Creating type guards might be a pain, sure. I think assertion functions will go a long way in this regard https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-7.html#assertion-functions https://www.typescriptlang.org/docs/handbook/release-notes/t... I also think that its an overestimated pain. If you are using interfaces to type your objects (commonly, this seems to be the pain point) then I don't think its terribly difficult to construct type guards around that. There is also the reflect-metadata polyfill (that I think TC39 is eventually going to make a standard) for run time type information. Using decorators could be valuable combined with `emitDecoratorMetadata` option https://rbuckton.github.io/reflect-metadata/ https://rbuckton.github.io/reflect-metadata/