5 ms·
Good stuff. I don't get the example for #3. I understand using "unknown" instead of "any", but both examples look effectively the same in terms of type safety.
by deepfriedrice 6y ago
Good stuff.
I don't get the example for #3. I understand using "unknown" instead of "any", but both examples look effectively the same in terms of type safety.
I also don't get the example for #4. Side effects are the inherit "blind spot" of TypeScript. If you're really worried about your API changing on you, it seems like you'd be better off modeling it in something like JSON schema. Unless maybe your API is trivial.
- deleted 6y ago[deleted]
- jgwil2 6y agoIn the fixed version of #3, the function return type is `Product[]` instead of `any`. The example is further refined in #4. What type guards are good for is marrying the compile time checks with runtime safety. They allow TSC to infer that in a given code path, the type can be narrowed down to something more specific. This is nice because it lets a single function e.g. handle a few different types without littering your code with `as` or `!`.
- ivan888 6y agoI 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 agoTypeScript'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 agoThis 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 agoThat 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 agoCool library, the type guards look interesting. Too bad it's not more automatic but yeah it's not very much extra code
- knocte 6y agoWhen 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 agoIt’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 agoPresumably because of type erasure during compilation. If you had access to a runtime representation of a TS type you could do something like that.
- deleted 6y ago[deleted]
- bradstewart 6y agoA value of type "any" is assignable to anything, a value of type "unknown" is assignable to nothing. unknown forces a type cast.
- Normal_gaussian 6y agounknown forces type checking, not casting. It is essentially a union of all possible types that you have to refine down.