DEV Community

Discussion on: Convince me that types are awesome

Collapse
 
briwa profile image
briwa • Edited

One of the best advantages of types is that it lets you catch errors before the code is executed. With the right precompiler/language server, you can see that your code is faulty even in your IDE. I can only speak for Javascript to give you an example.

function sum (num1, num2) {
  return num1 + num2
}

const total = sum.apply(null, [1,2])
// Returns 3.

It is a sum function that takes in two numbers as the arguments. However, a common mistake is to think that the sum function can take in multiple arguments then get a sum of them. Maybe the function is imported into a different file and you might have already forgotten about the interface.

const anotherTotal = sum.apply(null, [1,2,3])
// You're expecting it to return 6, but... it's actually still 3.

Unfortunately, you wouldn't know that you're making a mistake until you run the code in the browser and test the feature that is using the code, or you have your unit tests running. The scariest part is, in the browser, it won't even throw an error.

With Typescript, you can spot this in your IDE even before it is run anywhere else. This is how it looks like, more or less:

const anotherTotal = sum.apply(null, [1, 2, 3])
//                                ❌ ^^^^^^^^^
//  Argument of type '[number, number, number]' is not assignable to parameter of type '[number, number]'.
//    Types of property 'length' are incompatible.
//      Type '3' is not assignable to type '2'. ts(2345)

This is just a really simple example. Of course, the mistake is obvious on this one, but, as the software gets more complicated, the argument for the necessity of typing (IMO) is going to get more and more valid. For more info on this topic (Typescript), I've written an article about this (shameless plug 😋):

Another advantage that I find it useful is the documentation. With a good IDE integration, Typescript (or any strongly-typed language) code is sort of self-documented, but if you want to take it up a notch, you can easily generate a user-facing documentation from it without a hassle, using libraries like Typedoc. It would help a lot for, say, you're creating a library in Typescript and you want to put up a page for the API documentation.

But I also understand the other side of the story. I've read this article, and I can see that the overhead of using Typescript (or any strong-typed language, for that matter) can be too expensive to some. I would say, if you still want to skip typings, at least have a good documentation and a good testing coverage. Without these two (and also typings), I'm not sure if maintaining the code would still be productive when the code is growing in complexity and also the number of devs maintaining it ;) Just my two cents.

Collapse
 
mandaputtra profile image
Manda Putra

How about user input? you define as a number but user inputted string? you catch the error or the compiler throw the error?

Collapse
 
briwa profile image
briwa • Edited

If you're talking about Typescript, it won't catch them, because in my opinion Typescript is not meant to be used to define user interfaces and user inputs (unless you're talking about .tsx files, but it's going to get too specific, which is out of topic). In general, side effects I/O such as user inputs should be validated/specified by an end-to-end test.

In HTML, you can definitely set a "type" to your inputs (for example <input type="number" /> for number-only inputs). But again, the context matters. If you have a use case and you have your own set of expectations of what a strongly-typed language should do, maybe I can understand your problem better.

EDIT: @stojakovic99 answer is more apt, I guess it's better for me to say that strongly-typed languages help you to define/catch errors before runtime, and outside of that (like user inputs) it should be handled differently (maybe an e2e test).

Collapse
 
stojakovic99 profile image
Nikola Stojaković • Edited

User input is done during the runtime, so, you need additional measures to catch the error. Personally, for TypeScript I use class-validator and treat whole API request as DTO. For Java I use bean validation.

Thread Thread
 
mandaputtra profile image
Manda Putra • Edited

Yes, that's it, I use typescript before I do what you do too, this is why I'm still not using it (Unless I use Angular). if I want to sell TS to somebody else definitely not the typing system. the IDE and OOP make the refactoring code better, autocomplete, what else, typing system doesn't make less bug and maintaining code better.

Just use this, basarat.gitbooks.io/typescript/doc... reading this makes me use typescript for 2 months. then back again to plain javascript, some problem with another lib still sometimes occurs in TS (usually typings). I can't stand that :(

Collapse
 
jckuhl profile image
Jonathan Kuhl

User input cannot be caught by Typescript, because user input is brought in at runtime.

You don't run Typescript, you compile it to JavaScript and run the JavaScript, so by the time it's running, type information is discarded.

However, Typescript will help you prepare a function to receive user input by setting up the appropriate types, but that's as far as it can go.