DEV Community

Discussion on: How TypeScript squashed all known bugs

Collapse
 
owenpattison profile image
Owen Pattison

So your aTypeScriptMethod would have a strict typing of number which means it will only accept that type.

This means when you later set age from dataFromBackend.age the let would be cast as a string.

Therefore when you try to pass the function a string you would see a compilation error, that would give you feedback saying you have tried to pass a string to the method rather than a number resulting in your code not compiling until you resolve the casting of age.

Collapse
 
blindfish3 profile image
Ben Calder • Edited

Owen - Either I'm misinterpreting your answer or it is simply wrong. Typescript only does compile-time type-checking. All it knows about data coming from outside is what hypothetical type you have assigned to your input parameters; but no run-time type checking or data-validation is embedded into the compiled code that actually handles the data: it has been compiled to plain JavaScript with no type checking.

In the example given Typescript is no help at all: the application would simply crash. I've seen this happen recently in an application taking data from a PHP backend out of our control. The data didn't conform to the data type we expected and our application bombed because someone forgot to add the proper checks. This was in QA so no big deal; but could have been really problematic if it had slipped through the net.

I think it would be unfair to call this a flaw in Typescript; but it is really important that people understand this. Typescript is not a substitute for doing proper type-checking/validation on data that is outside your control.

Thread Thread
 
integerman profile image
Matt Eland

If that was to me, you need to read it in context.

tsc doesn't generate type checking logic, it does static tranpilation analysis based on what you've told it about the types. If you tell it the Web API result returns a number, it'll roll with it and find no issues (assuming you treat it like a number). Since it transpiles down to JavaScript, the variable will still get assigned a string and you get the same sort of an issue down the road. That's why it's important to get your type definitions correct as well as potentially validate them at the boundaries with a typeof check.

Also bear in mind union types and nullability are supported in TypeScript and should be considered and used. The benefits once you understand them are great, however.

Thread Thread
 
blindfish3 profile image
Ben Calder

Matt - my response saying the answer given was incorrect was not directed at you. I've edited it to make that clearer ;)

Collapse
 
integerman profile image
Matt Eland

Put simply, typings tell the compiler what you think something is and it handles enforcement based on those assumptions. You think your incoming web service values are strings, so you define them that way and convert to number as needed when looking at the results.

Thread Thread
 
blindfish3 profile image
Ben Calder • Edited

Matt - I think you've misinterpreted the example problem: the string being passed in dataFromBackend.age can't be converted to a number; so your proposed solution could still cause a crash. The main problem lies here (my emphasis below):

You think your incoming web service values are strings

Actually you "think" your values are numbers masquerading as strings but you still don't have an absolute guarantee*; so you need to add some kind of guard in the code that converts to number to handle non-standard data. Without suitable handling your entire application could crash. As an extreme example I know of an OS map library that would crash your browser and require a reboot if you passed it a string instead of a number...

* except maybe if your backend is written in Typescript and shares the same type-definition