¿Cuál es el tipo de registro en mecanografiado?

¿Qué Record<K, T>significa en mecanografiado?

Typecript 2.1 introdujo el Recordtipo, describiéndolo en un ejemplo:

// For every properties K of type T, transform it to U
function mapObject<K extends string, T, U>(obj: Record<K, T>, f: (x: T) => U): Record<K, U>

ver Typecript 2.1

Y el Tipos avanzada página menciona Recordbajo los tipos mapeados en dirección al lado Readonly, Partialy Pick, en lo que parece ser su definición:

type Record<K extends string, T> = {
    [P in K]: T;
}

Readonly, Partial y Pick son homomórficos, mientras que Record no lo es. Una pista de que Record no es homomórfico es que no se necesita un tipo de entrada para copiar propiedades de:

type ThreeStringProps = Record<'prop1' | 'prop2' | 'prop3', string>

Y eso es. Además de las citas anteriores, no hay otra mención Recorden typescriptlang.org .

Preguntas

1. ¿Alguien puede dar una definición simple de lo que Recordes?

2. ¿Es Record<K,T>simplemente una forma de decir "todas las propiedades en este objeto tendrán tipo T"? Probablemente no todas las propiedades, ya que Ktiene algún propósito ...

3. ¿El Kgenérico prohíbe claves adicionales en el objeto que no lo son K, o las permite y solo indica que sus propiedades no se transforman T?

4. Con el ejemplo dado:

    type ThreeStringProps = Record<'prop1' | 'prop2' | 'prop3', string>

¿Es exactamente lo mismo que esto ?:

    type ThreeStringProps = {prop1: string, prop2: string, prop3: string}

1. ¿Alguien puede dar una definición simple de lo que Recordes?

A Record<K, T>es un tipo de objeto cuyas claves de propiedad son Ky cuyos valores de propiedad son T. Es decir, keyof Record<K, T>es equivalente a K, y Record<K, T>[K]es (básicamente) equivalente a T.

2. ¿Es Record<K,T>simplemente una forma de decir "todas las propiedades en este objeto tendrán tipo T"? Probablemente no todos los objetos, ya que Ktiene algún propósito ...

Como observa, Ktiene un propósito ... limitar las claves de propiedad a valores particulares. Si desea aceptar todas las claves posibles con valores de cadena, puede hacer algo como Record<string, T>, pero la forma idiomática de hacerlo es utilizar una firma de índice como { [k: string]: T }.

3. ¿El Kgenérico prohíbe claves adicionales en el objeto que no lo son K, o las permite y solo indica que sus propiedades no se transforman T?

No "prohíbe" exactamente claves adicionales: después de todo, generalmente se permite que un valor tenga propiedades no mencionadas explícitamente en su tipo ... pero no reconocería que tales propiedades existen:

declare const x: Record<"a", string>;
x.b; // error, Property 'b' does not exist on type 'Record<"a", string>'

y los trataría como propiedades en exceso que a veces se rechazan:

declare function acceptR(x: Record<"a", string>): void;
acceptR({a: "hey", b: "you"}); // error, Object literal may only specify known properties

y a veces aceptado:

const y = {a: "hey", b: "you"};
acceptR(y); // okay

4. Con el ejemplo dado:

   type ThreeStringProps = Record<'prop1' | 'prop2' | 'prop3', string>

   ¿Es exactamente lo mismo que esto ?:

   type ThreeStringProps = {prop1: string, prop2: string, prop3: string}

¡Si!

Espero que ayude. ¡Buena suerte!

Un registro le permite crear un nuevo tipo a partir de una unión. Los valores en la Unión se utilizan como atributos del nuevo tipo.

Por ejemplo, digamos que tengo una Unión como esta:

type CatNames = "miffy" | "boris" | "mordred";

Ahora quiero crear un objeto que contenga información sobre todos los gatos, puedo crear un nuevo tipo usando los valores de CatName Union como claves.

type CatList = Record<CatNames, {age: number}>

Si quiero satisfacer esta CatList, debo crear un objeto como este:

const cats:CatList = {
  miffy: { age:99 },
  boris: { age:16 },
  mordred: { age:600 }
}

Obtienes seguridad de tipo muy fuerte:

• Si olvido un gato, me sale un error.
• Si agrego un gato que no está permitido, aparece un error.
• Si luego cambio CatNames, aparece un error. Esto es especialmente útil porque es probable que CatNames se importe desde otro archivo y se use en muchos lugares.

Ejemplo de reacción en el mundo real.

Utilicé esto recientemente para crear un componente de estado. El componente recibiría un accesorio de estado y luego representaría un icono. He simplificado mucho el código aquí con fines ilustrativos

Tuve una unión como esta:

type Statuses = "failed" | "complete";

Usé esto para crear un objeto como este:

const icons: Record<
  Statuses,
  { iconType: IconTypes; iconColor: IconColors }
> = {
  failed: {
    iconType: "warning",
    iconColor: "red"
  },
  complete: {
    iconType: "check",
    iconColor: "green"
  };

Entonces podría renderizar mediante la desestructuración de un elemento del objeto en accesorios, así:

const Status = ({status}) => <Icon {...icons[status]} />

Si la unión de estados se extiende o cambia más tarde, sé que mi componente de estado no se compilará y recibiré un error que puedo solucionar de inmediato. Esto me permite agregar estados de error adicionales a la aplicación.

Tenga en cuenta que la aplicación real tenía docenas de estados de error a los que se hizo referencia en varios lugares, por lo que este tipo de seguridad fue extremadamente útil.