Not that it's a big secret, but this year has really put a crimp in my plans (I know, right?).
However, in January and February, I was able to meet some personal goals with an open-source project and a new eBook for my subscribers.
So even though I'm a little late to the party, I'm currently transitioning the project over to TypeScript.
2. It's application-scalable (modular)
With the ability to create separate classes, interfaces, and services, this innately makes your code more manageable when working with a large number of files.
It's even flexible enough to transpile down to the latest ECMAScript version through a configuration file.
3. It's considered a popular language
Developers have spoken!
4. It's fully matured
Since TypeScript 4.0 just came out, it's been fully tested and now it's basically at the point where Microsoft is simply adding new features to the language. At version 4.0, I believe it can be considered a full-fledged Internet language.
Not bad, but the project required additional components from Bootstrap to work. I'll come to that bridge when I cross it.
Things I Learned During the Conversion
When I started converting the code over, I realized there were some similarities in TypeScript associated with C#. Since Anders Hejlsberg created C#, it made sense that I would see similar programming concepts in TypeScript as I did in C#.
The process for converting the code is still a "work in progress," but during this conversion, I followed these steps to make it all TypeScript.
1. Create Classes and Interfaces
One of the first things I did was to build out a class hierarchy. There should be a trace of logical partitioning in your application.
Your classes lay the groundwork for communicating with each other (Think TRIM).
You now have the ability to write full-blown classes. I took advantage of that in the code.
2 Create Modules
One class represents a single file. That's the standard.
Each module should contain one or more of these class files you created. Again, think like an onion and build on top of each layer.
While you can place multiple classes inside of one file, it makes it harder to find later when you need to make adjustments to your classes or interfaces.
Also, shoving all classes in one file is not a suitable, long-term strategy.
3. Replace Events with Fat Arrow Syntax
I replaced every event with the "fat arrow" syntax (or Lambdas for you C# folks).
This eliminated the definition of a
var self = this; statement and resulted in expected behavior when I wanted to know what
4. Use Flexible DOM Manipulation
Since I was accessing DOM elements and developers could change the DOM elements to match their own design of classes, divs, and attributes, I decided to make the TypeScript classes accept DOM Selectors and use default selectors if they didn't pass them.
Once the template was returned from the server, the library would map out the visible components on the screen and start the application.
5. Make the tool "DevOps-able"
Yet, with introducing TypeScript to my project, I need to rethink my pipeline. It requires a little bit more care when building the project since I now have a second project in the pipeline.
Put the time in upfront to create a pipeline and you'll benefit from the dividends later.
Your DevOps pipeline should "build all the things and do all the stuff" required to deploy your software to a server or to a person's machine.
This is how you get single button deploys.
I know I'm forgetting something from this list, but after getting back into the project from January/February, I feel I'll be adding more to this list after chatting with others about their approach.
Also, I will be introducing the project soon...so stay tuned.
How has TypeScript helped you in projects? Have you used it with a JS framework? Did you have problems? Post your comments below and let's discuss.