About Generics of C++ TpeScript Series

Preface:

When I interview, I usually like to ask candidates some strange questions. For example, if you are the author of a library, how do you implement a certain function? There is generally no correct answer to this type of question. The main purpose is to test whether the candidate has a deeper understanding of this library. The secondary purpose is that it is fun. It’s fun to have fun, but you also have to be serious when it’s time to be serious. Once, I interviewed a classmate who had used TypeScript , which was eye-opening (from my experience, some large companies in China occasionally use it, but small companies basically don’t). Then I asked, how do you understand generics? After asking, I regretted it because I didn’t know the answer either. But I didn’t regret the answer afterwards, because the candidate replied to me, “I don’t know what generics are…”

The impact of this incident on the candidates may be big or small, but it had a big impact on me. It prompted me to write an article about generics. But since I planted this seed, I have begun to regret it. The more I get to know generics in TS, the more I feel that there is nothing much to write about this topic. First of all, generics in TS are like air, often used but difficult to describe. Second, it is too broad and difficult to cover everything.

Today’s post will be different from previous ones in this series. This article will start from the problems that C++ templates need to solve, introduce the problems that TS generics need to solve, and briefly introduce some slightly advanced usage scenarios.

1. Template

Speaking of generics, we have to mention the originator of generics, templates. Templates in C++ are known for being both tedious and powerful, and have been talked about by various major textbooks for many years. For now, generics in Java, .NET, or TS can be considered to implement a subset of C++ templates. I don't agree with the subset statement. Because in terms of purpose, TS and C++ templates are completely different.

C++ templates were created to create type-safe general purpose containers. Let's talk about general containers first. For example, if I write a linked list or an array, this data structure doesn't care much about the type of specific data in it, it can implement the corresponding operations. But js itself does not pay attention to type and size, so the array in js is originally a universal container. For TS, the emergence of generics can solve this problem. Another thing worth comparing is generation. C++ templates ultimately produce corresponding classes or functions, but for TS, TS cannot generate anything. Some students may ask, doesn’t TS ultimately generate JS code? This is a bit imprecise, because TS ultimately separates the JS code without doing anything to the original logic.

Another purpose of C++ templates is metaprogramming. This metaprogramming is quite powerful, and it mainly optimizes program execution through programming constructs at compile time. As far as TS is concerned, it currently only makes one similar optimization, that is, const enum can be inlined at the execution location, that's all. Regarding this type of optimization, the end of the previous article also mentioned optimization based on type inference, but currently, TS does not have this function. If these simple optimizations are not supported, then more complex metaprogramming is even more impossible (metaprogramming requires logical deduction of generic parameters and ultimately inlining them to where they are used).

That’s all I have to say about C++ templates. After all, this is not an article about template metaprogramming, and I’m not an expert. If you have more questions about templates, you can ask Brother Lunzi. After talking about so many templates, I mainly want to say that generics and templates in TS are very different! If you are switching from C++ or Java to front-end development, you still need to re-understand the generics in TS.

2. Generics

I think there are mainly 3 main uses for generics in TS:

• Declare a generic container or component. For example: various container classes such as Map , Array , Set, etc.; various components, such as React.Component .
• Constrain the type. For example: use extends to constrain the incoming parameters to conform to a certain structure.
• Generate new types
  

As for the second and third points, since they have been clearly mentioned in the previous article, I will not repeat them here. Regarding the first point, let me give you two examples:

The first example is about generic containers. Suppose I want to implement a simple generic linked list. The code is as follows:

class LinkedList<T> { // Generic class value: T;
  next?: LinkedList<T>; // You can use itself for type declaration constructor(value: T, next?: LinkedList<T>) {
    this.value = value;
    this.next = next;
  }
  log() {
    if (this.next) {
      this.next.log();
    }
    console.log(this.value);
  }
}
let list: LinkedList<number>; // Generic specialization is number
[1, 2, 3].forEach(value => {
  list = new LinkedList(value, list);
});
list.log(); // 1 2 3

The second is a generic component. If I want to implement a general form component, I can write it like this:

function Form<T extends { [key: string]: any }>({ data }: { data: T }) {
  return (
    <form>
      {data.map((value, key) => <input name={key} value={value} />)}
    </form>
  )
}

This example not only demonstrates generic components, but also demonstrates how to use extends to define generic constraints. The generic form component in reality may be more complicated than this, the above is just to demonstrate the idea.

So far, we have finished talking about TS generics! But this article is not over yet, let's take a look at some advanced usage techniques of generics.

3. Generic recursion

Simply put, recursion is a way of solving problems in which the output of a function can continue to be used as input for logical calculations. Let’s take a simple example. For example, if we want to calculate addition, we define an add function, which can only calculate the sum of two numbers. But now we have three numbers, 1, 2, and 3, that need to be calculated. How can we solve this problem with existing tools? The answer is simple. First, add(1, 2) is 3, and then add(3, 3) is 6. This is the idea of ​​recursion.

Recursion is so common in real life that we often overlook its existence. The same is true in the world of programming. Here is an example to illustrate how recursion is implemented in TS. For example, I now have a generic type ReturnType<T>, which can return the return type of a function. But now I have a function with a very deep call hierarchy, and I don’t know how deep it is. What should I do?

Idea 1:

type DeepReturnType<T extends (...args: any) => any> = ReturnType<T> extends (
  ...args: any
) => any
  ? DeepReturnType<ReturnType<T>> // Reference itself here: ReturnType<T>;

Explanation of the above code: A generic type DeepReturnType is defined here, and the type constraint is a function that accepts any parameters and returns any type. If its return type is a function, it continues to call itself with the return type, otherwise it returns the return type of the function.

Behind any intuitive and simple solution there is a but. However, this cannot be compiled. The main reason is that TS is not currently supported. I don’t know whether it will be supported in the future, but the official reason is very clear:

• This circular intent makes it impossible to form an object graph unless you defer it in some way (through laziness or state).
• There's really no way to know if type deduction has finished.
• We can use finite types of recursion in the compiler, but the question is not whether the type terminates, but how computationally intensive and memory-allocation-lawful it is.
• A meta-question: do we want people to write code like this? Such use cases exist, but the types implemented in this way may not be suitable for consumers of the library.
• Conclusion: We are not ready for this kind of thing.
  

So, how do we achieve this kind of demand? There is a method, such as the official idea, we can use a limited number of recursion. Here are my ideas:

// Two-layer generic type type ReturnType1<T extends (...args: any) => any> = ReturnType<T> extends (
  ...args: any
) => any
  ? ReturnType<ReturnType<T>>
  : ReturnType<T>;
// Three-layer generic type type ReturnType2<T extends (...args: any) => any> = ReturnType<T> extends (
  ...args: any
) => any
  ? ReturnType1<ReturnType<T>>
  : ReturnType<T>;
// Four layers of generic types, which can meet most cases type DeepReturnType<T extends (...args: any) => any> = ReturnType<T> extends (
  ...args: any
) => any
  ? ReturnType2<ReturnType<T>>
  : ReturnType<T>;
  
// Test const deep3Fn = () => () => () => () => "flag is win" as const; // Four-layer function type Returned = DeepReturnType<typeof deep3Fn>; // type Returned = "flag is win"
const deep1Fn = () => "flag is win" as const; // one layer function type Returned = DeepReturnType<typeof deep1Fn>; // type Returned = "flag is win"

This technique can be extended to define deep structures such as Exclude , Optional , or Required .

4. Default generic parameters

Sometimes we like generics very much, but sometimes we don’t want consumers of classes or functions to specify the generic type every time. At this time, we can use default generic parameters. This is widely used in many third-party libraries, such as:

// Generic component that receives PSC class Component<P,S,C> {
  props: P;
  state: S;
  context:C
  ....
}
// Need to use class MyComponent extends Component<{}, {}, {}>{}
​
// But what if my component is a pure component that does not need props, state, and context? // I can define class Component<P = {}, S = {}, C = {}> like this:
  props: P;
  state: S;
  context:C
  ....
}
// Then you can use class MyComponent extends Component {}

I think this feature is very practical, it implements partial instantiation in C++ templates in a very natural way in JS.

5. Generic Overloading

Generic overloading has been mentioned several times in the official documentation. This kind of overloading depends on some mechanisms of function overloading. Therefore, let's first take a look at function overloading in TS. Here, I use the map function in lodash as an example. The second parameter of the map function can accept a string or function , such as the example on the official website:

const square = (n) => n * n;
​
// Map of receiving functions
map({ 'a': 4, 'b': 8 }, square);
// => [16, 64] (iteration order is not guaranteed)
 
const users = [
  { 'user': 'barney' },
  { 'user': 'fred' }
];
​
// Receive the map of string
map(users, 'user');
// => ['barney', 'fred']

So, how to express such a type declaration in TS? I can use function overloading, like this:

// This is just for demonstration, correctness is not guaranteed. In real scenarios, the correct type needs to be filled in here, not any
interface MapFn {
  (obj: any, prop: string): any; // When receiving a string, scenario 1 (obj: any, fn: (value: any) => any): any; // When receiving a function, scenario 2 }
const map: MapFn = () => ({});
​
map(users, 'user'); // Overload scenario 1 map({ 'a': 4, 'b': 8 }, square); // Overload scenario 2

The above code uses a rather peculiar mechanism in TS, that is, the definition of functions, new and other class functions can be written in interface . This feature is mainly to support callable objects in js. For example, in jQuery , we can directly execute $("#banner-message")， or call its method $.ajax().

Of course, you can also use another more traditional approach, such as the following:

function map(obj: any, prop: string): any;
function map(obj: any, fn: (value: any) => any): any;
function map(obj, secondary): any {}

Here, function overloading is basically explained. Generalized to generics, it's basically the same. Here is an example of a question raised by a friend. I will not elaborate on this question here. The solution is probably this:

interface FN {
  (obj: { value: string; onChange: () => {} }): void;
  <T extends {[P in keyof T]: never}>(obj: T): void;
  // For obj of type T, it never receives other keys.
}
​
const fn: FN = () => {};
​
fn({}); // OK fn({ value: "Hi" }); // Wrong fn({ onChange: () => {} }); // Wrong fn({ value: "Hi", onChange: () => ({}) }); // OK

For the React ecosystem, here is an example of generic overloading that is worth reading, that is the connect function. You can move to its source code to learn more.

Overall, I didn’t like this article very much. The reason is that generics in TS are widely used, but due to its original design, their playability is poor. But I support this design concept. First, it can meet our requirements for defining types. Second, it is simpler and easier to use than C++ templates.

This is the end of this article about C++ TypeScript series on generics. For more related TypeScript generics content, please search 123WORDPRESS.COM's previous articles or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!