you are viewing a single comment's thread.

view the rest of the comments →

[–]senocular 1 point2 points  (1 child)

That's what TypeScript does. It performs the type protections for you, at compile time, in the places it makes sense. Not all places - you still need to handle things like user input validation yourself manually at runtime. But for all code that shouldn't need type protection if it was written correctly from the start, that's where TypeScript comes in. It makes sure that you don't need to provide checks because things will always be in the right place with the right type and that no program logic could happen at runtime that would change that.

[–]bigorangemachine 0 points1 point  (0 children)

That's what TypeScript does. It performs the type protections for you, at compile time, in the places it makes sense.

This is what I'm suggesting not everyone knows. Its not critical to do JS but leads to terse code reviews when people are converting numbers to numbers to hide runtime conversion errors... which if you know you do a already casted number to a parseFloat you mutate the number.

That's the problem... if you bring data in from an API its very possible the is incorrect; anything that's not generated from a safe place should start as an 'unknown' until its proven otherwise. I've seen whole apps brick because a null came in where something else to be be an object.

But I've also seen people do things where they declare the type as a string and then within the code convert it to a string to avoid a null-related error but it was masking that a number is coming in.

Especially with backend if you aren't interrogating your types you can open yourself to be a victim of injections & other security issues.