Clause de non-responsabilité

Hé, avant de commencer, permettez-moi de clarifier quelque chose: Bien que je parle beaucoup de mon package, ts-runtime-picker , ce n'est pas un article promotionnel. Je partage juste mon expérience et le voyage que j'ai fait avant de le construire. ( mais hey , si vous êtes curieux, voici le lien vers le package?).

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

Revenons un peu. Donc, je travaille avec TypeScript depuis un certain temps maintenant. Je ne m'appellerais pas un Pro TypeScript, mais j'ai construit quelques grands projets et travaillé avec elle dans mon entreprise. Vous savez, les projets habituels - certains «Hello World», certains légèrement plus complexes, et bien sûr, une bonne part de voyages à Google pour déterminer «ce que diable cette erreur signifie-t-elle?» ou "Comment puis-je choisir à nouveau les champs d'une interface?" (Vous obtenez le point.?)

Un jour, j'ai rencontré un problème tout en travaillant avec les fonctions de cloud Firebase. J'étais sur le point de terminaison CreateUser , rédigeant ma logique de validation, rétablissant les données et manipulant la folie de demande de grossisseurs habituelle. Tout se déplaçait en douceur jusqu'à ce que je rencontre ce morceau de code d'un développeur précédent:

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

... et mon TypeScript In Inner Pro a crié. ?

je veux dire, allez , c'était un drapeau rouge massif. Droite? L'insertion des données utilisateur non filtrées comme celle-ci était risquée - que si les données de demande manquaient une certaine validation et que nous avons fini par insérer des champs indésirables dans la base de données? Pas génial.

J'ai rapidement supprimé le code, mais ensuite, j'ai gelé une seconde. ? J'ai regardé mon écran en pensant: "Tenez-vous, si j'attribue simplement demande.data au type d'interface utilisateur, ne m'empêcherait-il pas quelque chose comme ça? Cela ne devrait-il pas résoudre le problème?" (Cue un coup d'espoir sur mon IDE, en attendant que les lignes ondulées rouges apparaissent.)

Mais attendez…? ‍️ typescript est pas magie. Ce n'est qu'un chèque de compilation, non? Il n'existe pas dans l'exécution. TypeScript est un masque pour la sécurité de type, mais il n'applique rien lorsque le code est en cours d'exécution. Il ne vraiment empêche les champs supplémentaires d'être insérés au moment de l'exécution.

Donc, j'ai appelé l'un de mes coéquipiers et j'ai demandé: «Hé frère, si nous avons un objet nommé Alphabets avec toutes les lettres de l'alphabet, et nous créons une interface uniquement surwoletters qui n'autorise que les lettres« et «B», que se passe-t-il lorsque nous jetons les alphabets objet à 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 manquer un battement, mon coéquipier a dit: "Haha, eh bien, vous obtiendrez toujours toutes les lettres d'alphabet parce que TypeScript ne peut pas vraiment arrêter cela dans l'exécution."

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

Mais alors, ça m'a frappé: Et si TypeScript pouvait appliquer cela lors de l'exécution? Et si nous pouvions jeter un objet à une interface spécifique et avoir TypeScript dépouiller automatiquement des propriétés qui n'étaient pas définies dans l'interface?

que résoudrait mon problème.

La naissance de Ts-Runtime-Picker

Alors, avec ce moment d'ampoule, je pensais: "Pourquoi ne pas en faire une réalité?" Si je pouvais lancer request.data à l'interface utilisateur, TypeScript pourrait m'aider automatiquement supprimer toutes les propriétés supplémentaires, ce qui rend l'objet sûr à insérer 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 à partir d'un objet, basé sur les champs définis dans une interface spécifique.

la meilleure partie? Cela me sauverait de la validation manuelle et du filtrage des champs. Il était passé l'époque de:

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

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

Comment cela fonctionne: Laissez TypeScript faire son travail

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

avant: validation manuelle

interface User {
  name: string;
  age: number;
}

const requestData = { name: 'John', age: 30, address: '123 Street' };

// Manually check and remove unwanted fields:
const filteredData = {
  name: requestData.name,
  age: requestData.age,
};

firebase.collection('users').add(filteredData);  // Not very elegant.

après: avec ts-runtime-picker

import { pick } from 'ts-runtime-picker';

interface User {
  name: string;
  age: number;
}

const requestData = { name: 'John', age: 30, address: '123 Street' };

// Automatically filters out non-existent properties:
const safeData = pick(requestData, User);

firebase.collection('users').add(safeData);  // Much cleaner!

la meilleure partie? Ce code est sûr par défaut. Pas besoin de contrôles manuels 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 du champ. ?

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

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

Bien sûr, l'étincelle initiale de l'idée est venue de moi étant un peu paresseuse - 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 à l'éclat! Le désir de facilite les choses peut être un moteur de l'innovation.

En fait, malgré la «paresse» initiale, j'ai passé 8 heures en construisant 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 les vérifications répétitives fastidieuses a conduit à une nouvelle solution qui a finalement rendu ma vie (et j'espère que beaucoup d'autres personnes) sont beaucoup plus faciles.

Donc, même si je peux blâmer la paresse pour faire rouler la balle, c'était 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 lieu de naissance 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 dactylographiée à la création d'un outil qui résout un vrai problème. Ce package est ma façon d'aider les utilisateurs de typeScript à tirer pleinement parti de la sécurité des types - pas seulement pendant le développement mais aussi dans l'exécution.

Si vous êtes fatigué de filtrer manuellement les champs ou de vous inquiéter des données indésirables se faufilant, donnez ts-runtime-picker un coup. C'est une chose de moins à s'inquiéter, et cela rend le travail avec TypeScript un peu plus intelligent. ?