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.
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
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
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!