Two Key Points To Focus When Learning TypeScript

I started writing TypeScript at the end of 2015. Since then I have written three medium-sized TypeScript projects. Even though TypeScript is very pleasant to learn (good resources, online playground, smooth learning curve, etc.) it can become a painful experience if the developer a) aims too high too soon or b) tries to force TypeScript/JavaScript to something that is not idiomatic. In this blog post, instead of sharing many tiny tips, I'll try to share two aspects that new TypeScript developers could focus on.

Aim for strictness

TypeScript is a very pragmatic language both from a developer and also project standpoints. The developer who hasn't written a single line of TypeScript can gradually learn the language and leverage the existing ECMAScript understanding.

From project standpoint TypeScript is a safe bet, the team can migrate to TypeScript without a complete rewrite.

TypeScript allows developers to define the strictness level, strictness in TypeScript context means what is permitted and what isn't by the compiler.

If I were to start a new project with TypeScript, I would add setting strict: true to the tsconfig.json because I understand what the compiler is trying to say if I get an error.

{
    "compilerOptions": {
        "strict": true
    }
}

The setting strict combines multiple checks that the developer leaves on or disables one by one. What I think is cool is that when the TypeScript compiler gets type system improvements, it can spot even more errors. Those new checks will be automatically enabled with the strict option.

As an example, how strictness would increase the number of errors spotted was when strictFunctionTypes check was introduced in TypeScript 2.6. I updated TypeScript and got new errors. As it was an entirely new check, I didn't quite understand what was wrong with the code. I could turn the strictFunctionTypes option off, learn what the compiler is trying to tell me and then decide if the check makes sense in our project.

It is also a good learning experience to read about the background of the error. The tool can teach us new things. Similar case was back in 2011 when I was writing C#, and JetBrains' ReSharper showed me a more compact version, and I could not understand how it worked. I asked in the StackOverflow how it works and Mr. Jon Skeet & Marc Gravell both answered. Learned a lot!

There might be cases when you don't know how to use TypeScript to model, say, input and output of your function which can lead to frustration. Be kind to yourself and mark that particular code with an

Write idiomatic JavaScript

Possibility to write classes (introduced in ECMAScript 2015 which TypeScript supports) and interfaces (TypeScript) can lead to a misunderstanding that you should do C# or Java -style Object-oriented programming (OOP). It is essential to understand the possibilities that JavaScript offers, like first-class functions, and not just write using the style what you may have learned in other languages.

In case of classes, there is nothing inherently wrong with using classes in JavaScript as long as the usage is appropriate, but it is a good thing to understand that they might not be the only solution or they might not work identically compared what you have seen in other languages.

JavaScript classes, introduced in ECMAScript 2015, are primarily syntactical sugar over JavaScript's existing prototype-based inheritance. The class syntax does not introduce a new object-oriented inheritance model to JavaScript. --MDN Web Docs - classes

The same thinking critical thinking should be applied to TypeScript specific features. What I see too often in C# code is unnecessary inheritance where the developer has moved properties to a base class with only one class deriving from the base class. There is a risk that TypeScript's beautiful type system is not used in full-extent and unnecessarily complicated solutions are brought from other languages.

For example, the backend implementation might have a base class and derived classes that are just data transfer objects (DTOs). It is straightforward to convert C# class with only properties to interface in TypeScript and do the inheritance with keyword extends. When doing so, the developer should think about if there is a better way to model the same data. For example, union types could be used.

Few blog posts that cover data modeling and differences to C#/Java:

• Type System Differences in TypeScript (Structural Type System) VS C# & Java (Nominal Type System
• Different Approaches To Modeling Data With TypeScript

Conclusion

I think having few simple "instructions" in your brain can lead to better quality. The one I try to follow on a daily basis is the "The Boy Scout Rule".

"Always check a module in cleaner than when you checked it out." No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. What would be the result?

Maybe these two key points that I mentioned are not as powerful as the boy scout rule, but I think if you keep them in your brain while learning TypeScript there might be a positive effect.

If you have any questions, don't hesitate to ask!

Discuss on Hacker News