How to understand TS of static type checking | creators training camp

What is the TS

In short, TS is a superset of JS, adding static type checking that JS does not have. TS not only supports the latest language specification of ES, but also integrates some new features of JS in the community.

Static type checking

The biggest, biggest feature of TS is static type checking/data type prediction. It’s important to understand what static type checking is doing and what it solves, otherwise you might end up remembering a bunch of TS apis but not knowing how to use them and in which scenarios. It’s like memorizing a lot of Vue’s APIS, but you don’t understand Vue’s responsiveness.

Here’s a static type check. Let’s see a little demo like this:

const age:number = 18 

interface user {
    name:string,
    age:number,
}
    
const person:user = {
  age: 18.name: 'liuliuqi',}Copy the code

Defines an age of type number and an object person that satisfies the interface (user). I did do static typing, but this example is a little confusing for those of you who are new to TS. I know exactly what data types I need, and I add a layer of type judgment. Not superfluous?

Conclusion: TS essentially strengthens the deterministic nature of JS variables, which is unnecessary because the scene is not complex enough because JS variables are of a certain type.

Usage scenarios

We start with a scenario with a question:

Let’s say the Nuggets hold a creator contest and announce a list of participants a week later. The latitude of the list includes the basic information of the contestants, the rank, the rights and interests corresponding to the rank, the article with the highest overall exposure of each author, and the ranking based on the rank, exposure, likes and other different dimensions. We need to make this list and have a filter that can switch the list to show the ranking in different dimensions

What do you do on the front end and what do you do on the back end when you get this requirement

The front end usually expects the back end to provide a List interface to get a list of data, and each item of the list is a large object that contains the data we need for each dimension.

The back end will assemble a list of interfaces from many dimensions and throw it to the front end. In the previous example, basic user information, level information, level corresponding rights and interests information, article information, ranking information of different dimensions… And so on normally exist in different tables, corresponding to different sub-services (applications). The backend will coupling the interfaces of these dimensions to return a large interface.

One of the items in the list we might be evaluating

// Take the title of the first article ranked by the contestant
item.article[0].name

// take the title of the first TAB of the contestant's ranked first article
item.article[0].tags[0].name
Copy the code

If the business scenario is complex enough, this string can be long enough. See if this feels a little familiar. There is no sense of security or certainty. Before t sub s, we always had a little bit of trouble evaluating this.

Just to be careful, let’s write a safe get value for lodash

// return undefined if not
// Loadsh get encapsulates the method to determine that the value is not empty
get(item, 'article[0].tags[0].name')
Copy the code

This code avoids the error can not read property of undefined. But it’s a little uncomfortable because we’re on the compatible back end. The back-end interface is an aggregation interface. In our expectation, if a field such as tags has no value, we want to return an empty array [] rather than null. We don’t need to introduce get. what

item.article[0].tags[0].name
Copy the code

This was fine, until one day a back terminal service changed the tags field to tag during iteration. Can not read property of undefined. The page directly hung. The front end students quickly located the problem and solved the online problem in ten minutes.

Here the front end is still very passive. Although there is a good agreement with the back end eldest brother value is empty, but there is no agreement on the specific field return, step back will even if agreed, and then iteration several versions. How do you make sure that’s the agreement? From the front end point of view, the problem is that sub-services update fields that are not synchronized to the front end. But transposition of the following, this zha notice, eight poles can not hit a. It’s ok for people to focus only on their own application fields, but type constraints between back-end services are back-end business, not front-end students.

The agreement is not reliable, so what to do. That’s where TS comes in.

We add a type definition to the interface return value

interface listItem {
    // Indicates that the returned item must contain the article field
    Article is an array type, and each item in the array must satisfy the articleType type
    article:articleType[],
}
    
interfance articleType {
    name: string,
    Tags must have tags fields, and tags must either be tagItem arrays of type tagsType
    // An empty array
    tags: tagsType[] | []
}

Copy the code

Before we started development, we communicated with the backend students to confirm the above type definition description.

So we can be very confident when we write the business logic and manipulate the data that comes back. Because we are certain that the data returned by the back end must be consistent with our type convention, if they have tampered with the field. That’s their pot. If you need to defend yourself, show him the type definition. Perfect.

For the front end, the operational variables are pretty deterministic. Let’s say you write code that mistakenly values tags as objects. TS will immediately tell you that the value of tags is an array, not an object. This is static type checking. Will ensure that we operate variables must be in accordance with the type definition specification, to avoid the uncertainty and error in pure JS when the artificial value.

conclusion

TS essentially reinforces the deterministic nature of how we manipulate JS variables. In complex business scenarios, this certainty can reduce the complexity of business maintenance and can improve the robustness of business code. The benefits are very substantial.

I will write here first, and then fill in the advanced knowledge of TS, progressive introduction and real application scenarios in the business.

“A front-end learning small transparent, hard to learn front-end knowledge, at the same time to share some of their own thinking about life, welcome to discuss and exchange. If my article is helpful to you, please click a like, will be very grateful for your encouragement.”

How to understand TS of static type checking | creators training camp The campaign is under way…