IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Microsoft annonce la disponibilité de TypeScript 3.1 RC
Qui s'accompagne des types de tableau et de tuple mappables

Le , par Stéphane le calme

494PARTAGES

12  0 
Types de tableau et de tuple mappables

Mapper des valeurs dans une liste est l’un des schémas les plus courants de la programmation. À titre d’exemple, regardons le code JavaScript suivant :

Code TypeScript : Sélectionner tout
1
2
3
function stringifyAll(...elements) { 
    return elements.map(x => String(x)); 
}

La fonction stringifyAll prend un nombre quelconque de valeurs, convertit chaque élément en chaîne, place chaque résultat dans un nouveau tableau et renvoie ce tableau. Si nous voulons avoir le type le plus général pour stringifyAll, nous le déclarerons comme suit:

Code TypeScript : Sélectionner tout
declare function stringifyAll(...elements: unknown[]): Array<string>;

Dans son essence, cette portion de code déclare : « cette chose prend un nombre quelconque d'éléments, et retourne un tableau de chaînes ». Cependant, nous avons perdu un peu d’informations sur les éléments de cette transformation.

Plus précisément, le système de types ne se souvient pas du nombre d’éléments transmis à l’utilisateur, de sorte que notre type de sortie n’a pas non plus de longueur connue. Nous pouvons faire quelque chose comme ça avec des surcharges:

Code TypeScript : Sélectionner tout
1
2
3
4
5
declare function stringifyAll(...elements: []): string[]; 
declare function stringifyAll(...elements: [unknown]): [string]; 
declare function stringifyAll(...elements: [unknown, unknown]): [string, string]; 
declare function stringifyAll(...elements: [unknown, unknown, unknown]): [string, string, string]; 
// ... etc

Plutôt lourd n’est-ce pas ? Et nous n'avons même pas encore couvert quatre éléments. Vous finissez par créer des cas particuliers de toutes les surcharges possibles et vous vous retrouvez avec ce que Microsoft appelle le problème de la « mort par milliers de surcharges ». Bien sûr, nous pourrions utiliser des types conditionnels au lieu de surcharges, mais vous auriez alors un tas de types conditionnels imbriqués.


Si seulement il y avait un moyen de mapper uniformément chacun des types ici, pas vrai ?

Eh bien, TypeScript a déjà quelque chose qui s’y apparente. TypeScript a un concept appelé type d'objet mappé qui peut générer de nouveaux types à partir de ceux existants. Par exemple, en fonction du type de personne suivant,

Code TypeScript : Sélectionner tout
1
2
3
4
5
interface Person { 
    name: string; 
    age: number; 
    isHappy: boolean; 
}

nous pourrions vouloir convertir chaque propriété en une chaîne comme ci-dessus:

Code TypeScript : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
interface StringyPerson { 
    name: string; 
    age: string; 
    isHappy: string; 
} 
  
function stringifyPerson(p: Person) { 
    const result = {} as StringyPerson; 
    for (const prop in p) { 
        result[prop] = String(p[prop]); 
    } 
    return result; 
}

Toutefois, stringifyPerson est assez général. Nous pouvons abstraire l'idée de types Stringify-ier en utilisant un type d'objet mappé sur les propriétés d'un type donné:

Code TypeScript : Sélectionner tout
1
2
3
type Stringify<T> = { 
    [K in keyof T]: string 
};
Pour ceux qui ne sont pas familiers, voici comment cela se lit : « pour chaque propriété nommée K dans T, produit une nouvelle propriété de ce nom avec le type chaîne ».

Il est maintenant temps de réécrire notre fonction pour l'utiliser:

Code TypeScript : Sélectionner tout
1
2
3
4
5
6
7
8
9
function stringifyProps<T>(p: T) { 
    const result = {} as Stringify<T>; 
    for (const prop in p) { 
        result[prop] = String(p[prop]); 
    } 
    return result; 
} 
  
stringifyProps({ hello: 100, world: true }); // has type `{ hello: string, world: string }`

On dirait que nous avons ce que nous voulons! Cependant, si nous essayions de changer le type de stringifyAll pour retourner un Stringify:

Code TypeScript : Sélectionner tout
declare function stringifyAll<T extends unknown[]>(...elements: T): Stringify<T>;

Et puis essayons d’appeler sur un tableau ou un tuple, nous n’obtiendrons que quelque chose de presque utile avant TypeScript 3.1. Jetons un coup d’œil à une ancienne version de TypeScript comme 3.0:

Code TypeScript : Sélectionner tout
1
2
3
4
5
let stringyCoordinates = stringifyAll(100, true); 
  
// No errors! 
let first: string = stringyCoordinates[0]; 
let second: string = stringyCoordinates[1];

On dirait que nos index de tuple ont été mappés correctement ! Vérifions la longueur maintenant pour nous assurer que tout est correct.

Code TypeScript : Sélectionner tout
1
2
3
 let len: 2 = stringyCoordinates.length 
//     ~~~ 
// Type 'string' is not assignable to type '2'.

Mince ! Une chaîne ? Eh bien, essayons d’itérer nos coordonnées.

Code TypeScript : Sélectionner tout
1
2
3
stringyCoordinates.forEach(x => console.log(x)); 
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
// Cannot invoke an expression whose type lacks a call signature. Type 'String' has no compatible call signatures.

Qu'est-ce qui cause ce message d'erreur grossier ? Eh bien notre type mappé Stringify a non seulement mappé nos membres de tuple, il a également mappé sur les méthodes de Array, ainsi que la propriété length ! Donc, forEach et length ont toutes le même type de chaîne !

Bien que son comportement soit cohérent sur le plan technique, la majorité de l’équipe de TypeScript a estimé que ce cas d'utilisation devrait fonctionner. Plutôt que d'introduire un nouveau concept de mappage sur un tuple, les types d'objet mappés ne font désormais que « faire ce qui est bien » lors d'une itération sur des tuples et des tableaux. Cela signifie que si vous utilisez déjà des types mappés existants tels que Partial ou Required de lib.d.ts, ils fonctionnent automatiquement sur les tuples et les tableaux.

Propriétés sur les déclarations de fonction

En JavaScript, les fonctions ne sont que des objets. Cela signifie que nous pouvons y appliquer des propriétés à notre guise :

Code TypeScript : Sélectionner tout
1
2
3
4
5
6
7
export function readFile(path) { 
    // ... 
} 
  
readFile.async = function (path, callback) { 
    // ... 
}

L’approche traditionnelle de TypeScript à cet égard a été une structure extrêmement polyvalente appelée espaces de noms (ou encore « modules internes » si vous êtes suffisamment âgés pour vous en souvenir). En plus d'organiser le code, les espaces de noms prennent en charge le concept de fusion des valeurs, où vous pouvez ajouter des propriétés aux classes et aux fonctions de manière déclarative:

Code TypeScript : Sélectionner tout
1
2
3
4
5
6
7
8
9
export function readFile() { 
    // ... 
} 
  
export namespace readFile { 
    export function async() { 
        // ... 
    } 
}

Bien que peut-être élégant pour leur temps, la construction n’a pas bien vieilli. Les modules ECMAScript sont devenus le format préféré pour organiser le nouveau code dans la communauté TypeScript & JavaScript, et les espaces de noms sont spécifiques à TypeScript. De plus, les espaces de noms ne fusionnent pas avec les déclarations var, let ou const, donc le code suivant (motivé par defaultProps de React):

Code TypeScript : Sélectionner tout
1
2
3
4
5
6
7
export const FooComponent => ({ name }) => ( 
    <div>Hello! I am {name}</div> 
); 
  
FooComponent.defaultProps = { 
    name: "(anonymous)", 
};

ne peut pas être simplement converti en

Code TypeScript : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
export const FooComponent => ({ name }) => ( 
    <div>Hello! I am {name}</div> 
); 
  
// Doesn't work! 
namespace FooComponent { 
    export const defaultProps = { 
        name: "(anonymous)", 
    }; 
}
Tout cela peut être frustrant car cela rend la migration vers TypeScript plus difficile.

Compte tenu de tout cela, Microsoft a estimé qu'il serait préférable de rendre TypeScript un peu plus « intelligent » sur ces types de modèles. Dans TypeScript 3.1, pour toute déclaration de fonction ou déclaration de const initialisée avec une fonction, le vérificateur de type analyse la portée contenant pour suivre toutes les propriétés ajoutées. Cela signifie que les deux exemples - à la fois le readFile et les exemples FooComponent - fonctionnent sans modification dans TypeScript 3.1 !

En prime, cette fonctionnalité, associée à la prise en charge de JSX.LibraryManagedAttributes par TypeScript 3.0, facilite considérablement la migration d’une base de code React non typée vers TypeScript, car elle comprend quels attributs sont facultatifs en présence de defaultProps:

Code TypeScript : Sélectionner tout
1
2
3
// TypeScript understands that both are valid: 
<FooComponent /> 
<FooComponent name="Nathan" />

Source : Microsoft

Voir aussi :

Google s'oriente vers TypeScript et voici pourquoi, selon Evan Martin, un ingénieur de la firme qui travaille sur le langage
Babel : la version 7.0 du transpileur JavaScript est disponible avec le support de TypeScript et bien d'autres nouvelles fonctionnalités
La Release Candidate de TypeScript 3.0 vient de sortir : tour d'horizon des nouveautés de cette version majeure du surensemble typé de JavaScript
TypeScript 2.9 est disponible et intègre plusieurs nouveautés, le langage continue de compléter son système de typage

Une erreur dans cette actualité ? Signalez-nous-la !