A
A
Alexander2021-10-28 12:55:28
typescript
Alexander, 2021-10-28 12:55:28

Write types first or rely on compiler type inference?

I saw that a colleague describes types before defining data structures themselves, etc.
As for me, it turns out to be too verbose, plus then he himself starts to get confused in these numerous types and ends up having to cast and fight with the compiler.

I, on the contrary, only try to write types where it is necessary, and where the TS cannot deduce them correctly by itself.

Which approach do you think is better?

Answer the question

In order to leave comments, you need to log in

3 answer(s)
S
Stanislav Makarov, 2021-10-28
@Nipheris

There is no religion in this matter and cannot be. There are quite specific rules when writing types is very useful.
If you DO NOT specify the type, and count on auto-inference, then you do not need any specific type, but the SAME AS ... somewhere else. For example, same-as the type of a constant or same-as the return type of a function. In other words, if I write: then it is not so important for me what specific type the id will have, it is important for me that it be the type of the return value of the "findIdByName" function. For me, this is a priority. Moreover, if at some point the return type of this function changes, then this code will continue to compile and, probably, even WORK (it depends on what we are going to do with the id later).
const id = findIdByName("abc");
Completely opposite situation - interfaces. In a broad sense. Function interfaces, class interfaces, interfaces in the sense of data types created with "interface". Especially if this function/class/interface is used by many others. Then on the contrary, you SHOULD NOT allow the types of parameters or the type of the return value to change just like that. This is doubly important if you are writing a library and we are talking about its public interface - any change to the interface then must be supported by versioning (for example, semantic). You can't just start returning a string instead of a number, especially through an oversight - you will break your clients, and you don't even know how and where.

A
antares4045, 2021-10-28
@antares4045

The question is purely religious. If your team does not have codestyle requirements, then write in a way that is easier for you and don’t worry.
But if you turn on the bore for a while, then I really want to note that you took the typescript to write in js anyway. All these stories with automatic type inference pissed people off: skipping one letter they got a program that works, but does something wrong. And if this "one letter" is somewhere in the corner case, then the error can remain uncovered for years. It is possible to cover all code with unit tests. But this is a long time and a business (at least an average one) will never go to such expenses. In addition, there can also be jambs in tests ... And then people "remembered" another way to avoid such errors: if the user writes the types himself, then the computer will catch very gross semantic errors: the typeseript is specially made so that your code does not run .
But as you yourself noted, they tried to shut up the problem of errors in the code by forcing the programmer to write more code in which there may also be errors, and as a result, most of the time is spent on "love with a static analyzer". If you have enough confidence in yourself and in those who will maintain your code, then it is probably better to spend time writing meaningful code and not a ballerplate that will just make sure that you have not made very simple mistakes.

A
Aetae, 2021-10-28
@Aetae

There is no definite answer to this question.
I like it when everything comes out on its own. It's nice and convenient. But there are no guarantees that exactly what is needed will be output "on its own", and that you haven't screwed up somewhere imperceptibly. Therefore, in important / difficult places, I write types in advance. But only in them.
Often, out of habit from other languages, the description of a data structure that is set right there begins with a type, but this is absolutely redundant in TypesScript, because on the contrary, you can get a type from a ready-made structure, which reduces a bunch of extra code.
Well, there is a religious trend "types first", but this, in my opinion, is pure mazahizm. And absolutely not worth the imaginary benefits.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question