0

In a vanilla NodeJS tutorial I noticed the instructor always trying to define his variables in a way to guarantee no surprising assignments or values such as this one:

p.name = typeof (coinPair.name.toUpperCase()) === 'string' ? coinPair.name.toUpperCase() : false

I started to use this method in many of my codes to sort of guarantee if the value is not going to be assigned as expected it better be assigned to false (or some other specific default) so that it's easier to detect app crash reasons and avoid unexpected behavior.

When I started to use TypeScript, I realized its' native type safety features, which made me ask: Is the method used above still reasonable when using static strict typing my variables? Will it be useful when TypeScript already will not allow type changes during execution?

A developer I was discussing with was arguing that TypeScript transpiles to JavaScript at the end of the day, and claiming that its' type safety is only useful for debugging and that during runtime it's still javaScript without the TypeScript safety. He claimed that a variable defined as string with TypeScript may still accept a number (perhaps coercing even?).

I am confused now. Should TypeScript type safety measures suffice or I should still use the above method as necessary?

Arto Kalishian
  • 496
  • 1
  • 6
  • 11
  • Also worth reading: https://stackoverflow.com/questions/34834033/should-i-throw-on-null-parameters-in-private-internal-methods – Pace May 08 '19 at 21:17
  • 2
    Please don't return `null`s when your program gets unexpected input, throw an error instead. Returning `false` is even worse, its so arbitrary, its like returning `-4.2`. Also `typeof (coinPair.name.toUpperCase()) === 'string'` will never be false, its either true or it errors out. Your instructor clearly missed some classes. – Tamas Hegedus May 08 '19 at 21:29
  • This is my code not the instructor's. The instructors code is here and I'd like to know your opinion about it: https://github.com/pirple/The-NodeJS-Master-Class/blob/master/Section%203/FINAL/lib/handlers.js – Arto Kalishian May 08 '19 at 22:24

1 Answers1

1

If you only use your code for yourself or your team and everything you or your team create is in TypeScript then you don't need those kinds of checks. Otherwise, if you are sharing, or plan to share your code it will need boundaries. Even code you don't write should have boundaries. Where these boundaries are and is a design and development decision. Some libraries have large boundaries (e.g. a language's standard library) and others have very small controlled boundaries.

At these boundaries you may choose to do the above checks. As your peer claims, nothing in TS will protect you at runtime. If you created a TS module and publish it on NPM you should be publishing the JS. A JS developer can import/require your module and use it in their JS code and pass in whatever they want.

Also, even if you were certain your callers would also be using TypeScript you could still have these kinds of boundary-checking issues. For example, checking if objects are undefined or null, making sure JSON passed in from a web request is valid, etc. However, JS is such a loose language that it tends to require fairly exhaustive boundary checks so it's no surprise you'd see them in TS tutorials as JS developers who migrated are pretty used to having to do them.

At this point it probably gets opinion based. For example, I know many developers that sprinkle null checks exhaustively throughout a code base. In general I personally see this as a symptom of poor design and lack of awareness of boundaries. I am personally fairly against the idea of performing validity checks & asserts so that a bug is detected earlier. Such checks complicate the readability of code and reduce it's maintenance.

Pace
  • 41,875
  • 13
  • 113
  • 156
  • Very informative. Thanks! If you believe the validity checks are not necessary then what is your definition for a robust app? Also do you know any good books that talk about boundaries? – Arto Kalishian May 08 '19 at 22:29
  • 1
    A robust application is an application that responds as the end user expects regardless of user or other external input. Not every function needs to be robust for the application to be robust. As for books about boundaries, Clean Architecture might be a nice one although there are a lot of blog posts about it too you can read instead of a book. – Pace May 09 '19 at 06:44