Au-delà de la sécurité des types : rendre TypeScript plus intelligent en créant un sélecteur d'exécution

Avis de non-responsabilité

Hé, avant de commencer, permettez-moi de clarifier quelque chose : même si je parlerai beaucoup de mon package, ts-runtime-picker, ce n'est pas un article promotionnel. Je partage simplement mon expérience et le parcours que j’ai parcouru avant de le construire. (Mais bon, si vous êtes curieux, voici le lien vers le package ?).

Comment TypeScript m'a conduit à une nouvelle idée (et un package)

Remontons un peu en arrière. Je travaille donc avec TypeScript depuis un moment maintenant. Je ne me qualifierais pas de pro de TypeScript, mais j'ai construit quelques grands projets et travaillé avec dans mon entreprise. Vous savez, les projets habituels : des projets « hello world », d'autres un peu plus complexes, et bien sûr, une bonne part de voyages sur Google pour comprendre « qu'est-ce que cette erreur signifie ? » ou "Comment puis-je sélectionner à nouveau des champs dans une interface ?" (Vous comprenez. ?)

Un jour, j'ai rencontré un problème alors que je travaillais avec les fonctions cloud de Firebase. J'étais sur le point de terminaison createUser, écrivant ma logique de validation, coupant les données et gérant la folie habituelle des requêtes CRUD. Tout se déroulait bien jusqu'à ce que je tombe sur ce morceau de code d'un ancien développeur :

firebase.collection("users").add(request.data.user);

... et mon pro TypeScript intérieur criait. ?

Je veux dire, allez, c'était un énorme signal d'alarme. Droite? Insérer directement des données utilisateur non filtrées de cette manière était risqué : que se passerait-il si les données de la demande manquaient d'une certaine validation et que nous finissions par insérer des champs indésirables dans la base de données ? Pas génial.

J'ai rapidement supprimé le code, mais ensuite, je me suis figé pendant une seconde. ? J'ai regardé mon écran en pensant : « Attendez, si j'attribue simplement request.data au type d'interface utilisateur, TypeScript ne m'empêcherait-il pas de faire quelque chose comme ça ? Cela ne devrait-il pas résoudre le problème ? (Jetez un coup d'œil plein d'espoir à mon IDE, en attendant que les lignes rouges ondulées apparaissent.)

Mais attendez… ?‍♂️ TypeScript n'est pas magique. C'est seulement une vérification au moment de la compilation, n'est-ce pas ? Il n’existe pas au moment de l’exécution. TypeScript est un masque pour la sécurité des types, mais il n'applique rien lors de l'exécution du code. Cela n'empêche pas vraiment l'insertion de champs supplémentaires au moment de l'exécution.

Alors, j'ai appelé un de mes coéquipiers et lui ai demandé : « Hé mon frère, si nous avons un objet nommé alphabets avec toutes les lettres de l'alphabet, et que nous créons une interface OnlyTwoLetters qui n'autorise que les lettres « a » et « b', que se passe-t-il lorsque nous transférons l'objet alphabets vers cette interface ? »

// Object with all alphabet letters
const alphabets = {
  a: 'Apple',
  b: 'Banana',
  c: 'Cherry',
  d: 'Date',
  e: 'Eggplant',
  f: 'Fig',
  // ... all the way to z
};

// Interface that only allows 'a' and 'b'
interface OnlyTwoLetters {
  a: string;
  b: string;
}

// Casting alphabets to OnlyTwoLetters
const filteredAlphabets = alphabets as OnlyTwoLetters;

console.log(filteredAlphabets);

Sans perdre un instant, mon coéquipier a dit : « Haha, eh bien, vous obtiendrez toujours toutes les lettres de l'alphabet car TypeScript ne peut pas vraiment arrêter cela lors de l'exécution. »

Merde. Je le savais. J'étais sous l'effet de l'espoir -espérant que TypeScript pourrait comme par magie m'empêcher de faire des erreurs au moment de l'exécution. ?

Mais ensuite, ça m'a frappé : et si TypeScript pouvait appliquer cela au moment de l'exécution ? Et si nous pouvions convertir un objet en une interface spécifique et demander à TypeScript de supprimer automatiquement toutes les propriétés qui n'étaient pas définies dans l'interface ?

Cela résoudrait mon problème.

La naissance de ts-runtime-picker

Alors, avec ce moment d’ampoule, j’ai pensé : « Pourquoi ne pas en faire une réalité ? » Si je pouvais diffuser request.data sur l'interface utilisateur, TypeScript pourrait m'aider automatiquement à supprimer toutes les propriétés supplémentaires, rendant ainsi l'insertion de l'objet en toute sécurité dans Firebase. ?

Et juste comme ça, l'idée de ts-runtime-picker est née. L'objectif était simple : créer un package qui permettrait aux utilisateurs de TypeScript de filtrer les propriétés indésirables d'un objet, en fonction des champs définis dans une interface spécifique.

La meilleure partie ? Cela m'éviterait la validation manuelle et le filtrage des champs. Fini le temps de :

firebase.collection("users").add(request.data.user);

Comment ça marche : laissez TypeScript faire son travail

Avec ts-runtime-picker, l'ensemble du processus est automatisé. Vous pouvez convertir un objet en interface et le package garantira que seules les propriétés définies dans l'interface sont conservées. Voici comment cela fonctionne en action :

Avant : Validation manuelle

// Object with all alphabet letters
const alphabets = {
  a: 'Apple',
  b: 'Banana',
  c: 'Cherry',
  d: 'Date',
  e: 'Eggplant',
  f: 'Fig',
  // ... all the way to z
};

// Interface that only allows 'a' and 'b'
interface OnlyTwoLetters {
  a: string;
  b: string;
}

// Casting alphabets to OnlyTwoLetters
const filteredAlphabets = alphabets as OnlyTwoLetters;

console.log(filteredAlphabets);

Après : Avec ts-runtime-picker

const filteredData = {
  name: requestData.name,
  age: requestData.age,
};

firebase.collection("users").add(filteredData);  // More work, less fun.

La meilleure partie ? Ce code est sûr par défaut. Pas besoin de vérifications manuelles ou de manipulation d’objets. ts-runtime-picker le gère automatiquement pour vous en filtrant tous les champs qui n'existent pas dans l'interface utilisateur. Vous pouvez simplement vous concentrer sur votre logique de base sans vous soucier de l'insertion accidentelle de champs. ?

Le pouvoir de la paresse (et comment cela peut conduire à l'innovation)

Alors, vous vous demandez peut-être : "Est-ce que cela est venu par pure paresse ?" Et à cela, je dis : Oui, mais aussi, non. ?

Bien sûr, l’idée initiale est venue de ma paresse : je ne voulais pas filtrer manuellement les champs à chaque fois que j’avais besoin d’insérer des données. Mais bon, parfois la paresse mène au génie ! Le désir de rendre les choses plus faciles peut être un moteur d'innovation.

En fait, malgré la « paresse » initiale, j'ai passé 8 heures à construire le package. Ouais, c'est vrai. ?

Mais c’est comme ça que ça se passe parfois. "Le besoin donne naissance à l'invention", et ce besoin d'éviter des contrôles fastidieux et répétitifs a conduit à une nouvelle solution qui a finalement rendu ma vie (et, je l'espère, celle de beaucoup d'autres) beaucoup plus facile.

Ainsi, même si je peux accuser la paresse d'avoir lancé le bal, c'est la nécessité de résoudre le problème qui a donné naissance à ts-runtime-picker. Et c’est ainsi que parfois, être coincé ou paresseux n’est pas nécessairement une mauvaise chose : c’est le berceau de quelque chose de nouveau et d’utile !

Conclusion

Et c'est l'histoire derrière le package ts-runtime-picker. Un voyage de la frustration de TypeScript à la création d'un outil qui résout un problème réel. Ce package est ma façon d'aider les utilisateurs de TypeScript à tirer pleinement parti de la sécurité des types, non seulement pendant le développement mais également lors de l'exécution.

Si vous en avez assez de filtrer manuellement les champs ou si vous craignez que des données indésirables ne s'infiltrent, essayez ts-runtime-picker. C'est une chose de moins à craindre, et cela rend le travail avec TypeScript un peu plus intelligent. ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!