MAISON CODE .
/ TypeScript · Code Quality · DX

Mode strict : pourquoi nous appliquons TypeScript

JavaScript est le chaos. TypeScript est l'ordre. Comment nous utilisons Zod et TS pour empêcher « undéfini n'est pas une fonction » en production.

AB
Alex B.
Mode strict : pourquoi nous appliquons TypeScript

Le commerce électronique est une infrastructure essentielle. Un bug ici n’a pas seulement l’air mauvais ; ça coûte de l’argent. JavaScript, avec son typage lâche, est un handicap. Vous passez une chaîne là où un nombre est attendu ? Accident. Vous essayez d’accéder à .price sur un produit qui est nul ? Écran blanc.

Le bouclier TypeScript

Nous fonctionnons selon une politique Mode strict uniquement.

1. Validation du contrat API avec Zod

Nous ne faisons pas confiance à l’API. Même Shopify. Lorsque nous récupérons des données, nous les analysons via des schémas Zod.

importer { z } depuis 'zod' ;

const ProductSchema = z.object({
  identifiant : z.string(),
  titre : z.string(),
  fourchette de prix : z.object({
    minVariantPrice : z.object({
      montant : z.string().transform(val => parseFloat(val)), // Forcer le nombre
      code de devise : z.string(),
    })
  })
});

// Si l'API renvoie des déchets, cela est immédiatement lancé, assurant ainsi la sécurité de l'interface utilisateur.
const produit = ProductSchema.parse(apiResponse);

2. Composants génétiques

Notre bibliothèque d’interface utilisateur est entièrement typée. Vous ne pouvez pas utiliser notre composant <PriceTag /> sans transmettre un currencyCode valide. L’IDE (VS Code) vous criera dessus avant même d’essayer d’exécuter le code.

3. Sécurité de type de bout en bout

Avec des outils tels que GraphQL Code Generator, nous générons des types TypeScript directement à partir de nos requêtes. Si nous modifions la requête GraphQL pour récupérer « description » au lieu de « corps », nos composants React sont automatiquement informés du changement.

Conclusion

TypeScript ralentit la première heure de développement (écriture des types). Cela accélère les 100 prochaines heures (refactoring, débogage, mise à l’échelle). Dans une équipe de 10 ingénieurs, c’est le seul moyen de dormir la nuit.