Table of contents
2.1 Problems posed by type inference
2.3 Problems without assertions
2.4 Another way of writing assertions
2.5 View the type of DOM element
3.2.1 Compatibility between interfaces
3.2.2 Compatibility between interfaces and classes
1 Type inference
Type inference is a built-in mechanism of ts. You don’t need to comment on some variables, it will give you a type by default
For example, these two ways of writing are the same
If you give it directly, if you change the type later, you will still be prompted for an error
With this mechanism, you can not write a variable annotation, and then write annotations as needed
The same is true for functions. For example, the following one automatically infers that c is of type number
2 Type assertions
2.1 Problems posed by type inference
Type assertion is to solve the problem of wrong type speculation. Not all functions are declared by us, such as console.log()
The built-in function will also guess a type for you. Sometimes this is what you need, and sometimes this is not what you need, such as document.querySelector()
document.querySelector() will return different results according to different parameters, which is relatively broad. And your ts does not take the initiative to contact html, and you always ask ts to get it when html needs it. At this time, there will be problems in the judgment of ts itself
2.2 Basic use
For example, I now want to define alink as HTMLAnchorElement type, then you can write like this
This way you can get the type you want to use
You can’t directly write the front with a colon, because this is the return value, which means that your definition conflicts with the inference of the return value
2.3 Problems without assertions
HTMLAnchorElement means a tag element, if you do not perform type assertion, you will report an error when you use the href attribute of alink
It's okay to assert
2.4 Another way of writing assertions
Type assertion can also be written in this way, which has the same effect as using as
2.5 View the type of DOM element
Then you open this html file, you will see something printed in the terminal
At the bottom of the printed thing, you can see the type of this element
3 types of compatibility
3.1 Class Compatibility
I now have two classes Point_A and Point_B, the content of the two classes is the same, at this time we can declare PointB with the rules of PointA, this is called type compatibility
Less rules, more instances, compatible
Many rules, few examples, incompatibility
3.2 Interface Compatibility
3.2.1 Compatibility between interfaces
The same rules can be cross-used, p1 created by the Point_C rule can be created by the same Point_D rule constraint as Point_C to create p2
Less rules, more instances, compatible
Many rules, few examples, incompatibility
3.2.2 Compatibility between interfaces and classes
A class instance can be created using the rules of the interface
3.3 Function Compatibility
The function needs to consider the number of parameters parameter type return value variable
3.3.1 Number of parameters
A rule with many parameters can instantiate a function with few parameters
3.3.2 Parameter types
For general types, parameter types need to be equal. For complex types (such as interfaces), those with more rules can be compatible with those with fewer instances (the logic of compatibility with individual interfaces is opposite. Here you need to understand it as the number of parameters, and those with more parameters can The number of compatible parameters is small)
3.3.3 Return value type
For general types, the return type needs to be the same. For complex types, those with fewer rules can be compatible with those with more instances (consistent with the compatibility of individual interfaces)
