3 ms·

Thanks for reading the article! > That is the whole point in creating a library. To hide complexity in a nice easy to use interface/API. I think that's a fair

by qudat 4y ago

Thanks for reading the article! > That is the whole point in creating a library. To hide complexity in a nice easy to use interface/API. I think that's a fair point, but generating types that satisfy all use cases is very challenging to get right -- disproportionately so. I could see a world where -- without proper tooling and growing complexity -- typescript libraries becomes so difficult to maintain that people give up or burn out. Maybe that's a pessimistic outlook but I already feel that way some days.

Chabsff 4y ago
In strongly-typed programming languages, which includes Typescript, figuring out the types *of the interface* is not something that's done after the fact. `@types/*` is an exceptional project meant to back-port JS libraries to TypeScript, but that's the exception, not the rule. If you write a library in TypeScript, determining what types are present as part of the interface is one of the very first thing that should be done.
- mrkeen 4y ago
  > In strongly-typed programming languages, which includes Typescript, figuring out the types is not something that's done after the fact. Too broad a statement. There's loads of value in having a compiler figure out types for you after/when you write the code.
  - Chabsff 4y ago
    Hard disagree as far as the portions of it that are part of the user-facing public interface are concerned. But granted, as a general rule you are correct. I was referring specifically to API interfaces.
  - overgard 4y ago
    If you're talking about type-inference, sure, I guess it's fine. If you're talking about figuring out what types you're going to accept, you should absolutely be defining that on your own up-front. If you don't even know what your types are how is an end user going to figure it out?