5 ms·

I also don't understand 4. This looks terrible. Why use TypeScript if we have to make very manual assertions about the structure? Isn't that the purpose of TS i

I also don't understand 4. This looks terrible. Why use TypeScript if we have to make very manual assertions about the structure? Isn't that the purpose of TS itself?

jakelazaroff 6y ago
TypeScript's type checking is static, so on its own it can't know that values it receives from elsewhere (like JSON coming from a string) is the correct type. The only option is for the programmer to check at runtime, which allows TypeScript to know the type along the code path in which the check succeeds.
- ivan888 6y ago
  This makes sense; but it still doesn't feel like the right answer. Facilities should exist for runtime type checking based on TS definitions, and syntactic features should enable a 'hard check' of the actual object when necessary
  - jakelazaroff 6y ago
    That runs counter to one of the goals of TypeScript, which is to make no runtime changes. It’s easy enough to do this in userland. I wrote a tiny library called narrows which has worked great for me: https://www.npmjs.com/package/narrows https://www.npmjs.com/package/narrows
    - ivan888 6y ago
      Cool library, the type guards look interesting. Too bad it's not more automatic but yeah it's not very much extra code
    - knocte 6y ago
      When I read your comment I had high expectations about narrows. After I looked at it, I have a sour feeling in my mouth. Why there can't be a way (or a library) to do very easy type guards in TypeScript? Something as simple as the keyword `is` in C#
      - jakelazaroff 6y ago
        It’s for the reason I mentioned before: one of TypeScript’s primary goals is that it generates no runtime code. If you run the TypeScript compiler, it will generate exactly the same JavaScript code with the types removed*. Since there is no such JavaScript feature, there will be no such TypeScript feature. I’ll add that writing manual type guards is fairly infrequent, so in practice there’s not a lot to gain here. *Modulo polyfilling newer ES features if you compile for a lower version of the spec.
      - giantDinosaur 6y ago
        Presumably because of type erasure during compilation. If you had access to a runtime representation of a TS type you could do something like that.
  - curtisf 6y ago
    There are libraries that do type-safe schema validation (an article I found in a quick Google is linked below). That you can do something so sophisticated is a testament to TypeScript's type system. However, if you were writing JavaScript, I think it's (unfortunately) uncommon to have this kind of proactive validation. So, for people writing TypeScript as "JavaScript + types" (which is a perfectly fine way to use it), they would just use a type assertion, which is just writing down the assumption that the JavaScript programmer makes when consuming but not validating external data. https://2ality.com/2020/06/validating-data-typescript.html#picking-a-library https://2ality.com/2020/06/validating-data-typescript.html#p...

I also don't understand 4. This looks terrible. Why use TypeScript if we have to make very manual assertions about the structure? Isn't that the purpose of TS itself?

jakelazaroff 6y ago

TypeScript's type checking is static, so on its own it can't know that values it receives from elsewhere (like JSON coming from a string) is the correct type. The only option is for the programmer to check at runtime, which allows TypeScript to know the type along the code path in which the check succeeds.

ivan888 6y ago
This makes sense; but it still doesn't feel like the right answer. Facilities should exist for runtime type checking based on TS definitions, and syntactic features should enable a 'hard check' of the actual object when necessary
- jakelazaroff 6y ago
  That runs counter to one of the goals of TypeScript, which is to make no runtime changes. It’s easy enough to do this in userland. I wrote a tiny library called narrows which has worked great for me: https://www.npmjs.com/package/narrows https://www.npmjs.com/package/narrows
  - ivan888 6y ago
    Cool library, the type guards look interesting. Too bad it's not more automatic but yeah it's not very much extra code
  - knocte 6y ago
    When I read your comment I had high expectations about narrows. After I looked at it, I have a sour feeling in my mouth. Why there can't be a way (or a library) to do very easy type guards in TypeScript? Something as simple as the keyword `is` in C#
    - jakelazaroff 6y ago
      It’s for the reason I mentioned before: one of TypeScript’s primary goals is that it generates no runtime code. If you run the TypeScript compiler, it will generate exactly the same JavaScript code with the types removed*. Since there is no such JavaScript feature, there will be no such TypeScript feature. I’ll add that writing manual type guards is fairly infrequent, so in practice there’s not a lot to gain here. *Modulo polyfilling newer ES features if you compile for a lower version of the spec.
    - giantDinosaur 6y ago
      Presumably because of type erasure during compilation. If you had access to a runtime representation of a TS type you could do something like that.
- curtisf 6y ago
  There are libraries that do type-safe schema validation (an article I found in a quick Google is linked below). That you can do something so sophisticated is a testament to TypeScript's type system. However, if you were writing JavaScript, I think it's (unfortunately) uncommon to have this kind of proactive validation. So, for people writing TypeScript as "JavaScript + types" (which is a perfectly fine way to use it), they would just use a type assertion, which is just writing down the assumption that the JavaScript programmer makes when consuming but not validating external data. https://2ality.com/2020/06/validating-data-typescript.html#picking-a-library https://2ality.com/2020/06/validating-data-typescript.html#p...