A new tool called Smartour, released last week, is developed entirely in TypeScript (TS). Apart from the incomplete use in previous business, this practice can be regarded as the first time for me to use TS in a real sense. Due to the different writing methods and the freshness of unfamiliar things, I had a lot of feelings in the process of project development, so I decided to write a small article to record it well.

TS helps people develop the good habit of “thinking before doing”

In previous development, my habit was to “get a rough idea and then change it as you go along”. The advantage of this is that the action is faster, and the efficiency is very high when things go well, but more often it is to constantly overturn their previous ideas. I believe that many people also have similar experience with me.

With TS, this problem can be reduced to some extent. Ts is known to be a strongly typed language, which means that it effectively limits the extent to which developers can “do whatever they want” during development. Take defining the parameters of a function as an example to see how I think about writing JS and TS differently.

When I write JS, my thought process goes like this.

  1. First of all, this parameter is an object, a property of that objectelIs a CSS selector; And properties of the objectkeyNodesIt’s an array with a series of elementskeyNode.
  2. This so-calledkeyNodeIs also an object that also contains a CSS selector propertyel, and an event parameter bound to a DOM elementevent.
  3. I’ll comment out this parameter object so I can remember its definition.
/** { el: '#demo-id', keyNodes: [{ el: '.item-1', event (e) { console.log(e) } }] } */
Copy the code
  1. Whenever I use this parameter in the future, I will manually ensure that the structure of the parameter is consistent with the annotation.

Instead of writing ts, my idea is like this:

  1. First of all, this parameter is an object, a property of that objectelIs a CSS selector; And properties of the objectkeyNodesIt’s an array with a series of elementskeyNode.
  2. And then I’ll go throughinterfaceDefine it:
interface HightlightElement {
    el: string,
    keyNodes: Array<KeyNode>
}
Copy the code
interface KeyNode {
    el: string,
    event: EventListener
}
Copy the code
  1. When you need this parameter, you just pass it in when you define the parameterinterfaceCan. If the parameter structure or content type is wrong, the VScode editor immediately alerts you, eliminating the need for manual checking.
someFunction (param: HightlightElement) { ... }
Copy the code

It can be seen that when writing JS, it is more “oneself and oneself agree, oneself judge whether to abide by the agreement”, while TS is “oneself and oneself agree, by the third party (editor) to judge whether to abide by the agreement”. The benefits are more benign constraints on thinking than the platitude of reducing errors. This kind of benign constraint enables us to define a series of things to do in the stage of thinking. If any problems are found in the process of operation, they can be traced back to the starting point of initial thinking in the first time, and the troubleshooting will be more efficient.

TS has its own documentation feature

When writing JS, we rely on annotations to determine the type, structure, and action of a variable or parameter. Without comments, you can only figure out the details by reading the source code and constantly debugging it. Many of us have had the experience of working on someone else’s project: “Why not comment! What does this function say? This parameter is what!” Js code without comments is crushing, but writing comments not only takes time, but also tests one’s ability to generalize. Saying nothing and even misleading notes can be overwhelming.

In TS, an alternative to comments is to look at the interface definition for a variable or parameter. In interface, we can easily see the structure of parameters, the type of internal attributes, whether they are optional and other details. Combined with VScode’s smart hints and jumps, it’s easier to look at other people’s code or maintain a history project — after all, it’s easier to write interfaces than to write comments, and it’s easier to look at interfaces than to guess code.

Speaking of self-documenting features, I’m also reminded of GraphQL, another popular technology. With the GraphQL community’s suite of tools, callers can read the standard definition of the interface when they call it. Interface developers don’t need to write additional documentation, because when they define the interface, they have already written the documentation.

The self-documenting feature is very useful for projects that are maintained by multiple people and can greatly reduce the cost of communication and understanding in a project. If any of the parameters in an interface are of any type, then there is no point in using TS.

TS reduces the time cost of setting up an environment

In order to use the novel features of JS as well as the compatibility of old browsers, we often use a series of tools to build a development environment. We may be used to webPack + Babel, but who can guarantee that we will be able to build one without looking at the documentation? Despite the complex documentation of each of these tools, there are many more “best practices” that can be found even when the environment is put together. It took a day to finish.

As a superset of JS, we can safely use the various advanced capabilities of JS in TS. Thanks to the built-in command line tool, there is no need to study Babel or the various preset-env plug-ins. Just specify the version to be built and the TS command line tool will automatically generate the corresponding VERSION of JS for us.

Of course, this does not mean that with TS we can completely abandon build tools. Build tools are still necessary for building complex applications (such as scenarios that contain various static resources and cross-format file references) and will remain so for a long time to come. But in keeping with the principle of “less than more”, reducing the use of even one tool is good for developers, as we all look forward to a time when code doesn’t matter to the environment.

The end of the

Since I am not a veteran player of TS, the above bits and pieces are personal freshness as a beginner. In these days of work, also deeply realized that there is no 100% idealized thing forever. Ts is good, but it needs to be looked at dialectically. Do we really need TS? Does it really make us more productive? Is it as ideal as others describe it? These questions need to be answered with practice. After all, TS is just a tool, and when and how to use it depends on the specific situation. To openly brag or deny something else is a sign of narrow-mindedness.