Au cours des derniers mois Au cours des derniers mois, j'ai été chargé de déterminer comment écrire et gérer des widgets autonomes pour mon travail à temps plein. Même s'il était relativement simple de s'assurer qu'ils étaient fonctionnels, j'ai rapidement réalisé que leur maintenance était un tout autre défi

Dans cet esprit, j'ai commencé un projet parallèle pendant mon temps libre et je l'ai rendu open source. Cela m'a permis de partager mes idées et les stratégies qui m'ont aidé à garantir la qualité de mes widgets.

Comment je les ai fait à l'origine ?

Comme mes widgets nécessitaient un haut niveau de réactivité, je me suis fortement appuyé sur l'API du composant Svelte et j'ai utilisé Rollup pour le regroupement. "C'était simple et direct jusqu'à ce que je rencontre les problèmes suivants :

• Mon CSS inutilisé augmentait au fil du temps et je ne savais pas non plus si seul le CSS du composant souhaité était intégré.

• Il est difficile de gérer JavaScript via des widgets sans saisie stricte. C'est rapidement devenu un désastre puisque j'ai dû partager certains utilitaires comme le décodage et l'authentification JWT.

Comment je l'ai changé ?

J'ai commencé à réfléchir à la manière dont je pourrais établir des valeurs par défaut et, plus important encore, intégrer un système de types. Cela a conduit à la création de mon projet parallèle, svelte-standalone.

L'objectif de svelte-standalone était :

• Assurez-vous d'un CSS bien minifié et supprimez les CSS inutilisés lors du regroupement.
• Assurer un système de type de choix bien pris en charge et réutilisé sur toutes mes applications.

Remarque : le système de types choisi était TypeScript.

• Assurer les tests unitaires et d'intégration.
• Assurez-vous de pouvoir vérifier visuellement mes widgets avant et après leur analyse par cumul.

Comment j’ai réalisé tout cela ?

Après m'être assuré de la compatibilité TypeScript avec les plugins Rollup et le préprocesseur Svelte, j'ai pris du recul et décomposé mon projet en étapes clés. En gros j'avais :

1. Un .svelte.
2. Un fichier embed.js chargé de démarrer l'instance du fichier .svelte et de l'ajouter au corps.

À partir de là, j'ai remarqué que mon fichier intégré était donc fondamentalement répliqué par défaut sur tous mes widgets et j'ai commencé à les générer. J'ai donc pu utiliser les outils Codegen pour générer 3 fichiers en fonction de mes fichiers sveltes et de mon envie de gérer les types dans toute l'application :

1. declaration.d.ts - m'a permis d'importer directement mon composant svelte et de l'envelopper en utilisant le type SvelteComponent, j'ai donc transformé mes composants svelte en typage fort par défaut.
2. types.ts - activé pour que je puisse écrire une configuration par défaut basée sur les accessoires déclarés dans déclaration.d.ts.
3. embed.ts - activé le démarrage/arrêt de mon composant de manière standard pour tous mes widgets !

Et voilà ! Cette approche a résolu mes problèmes avec le système de types et amélioré la maintenabilité de mes widgets.

Comment j'ai relevé les défis CSS :

Les principaux défis liés au CSS auxquels j'ai été confronté étaient les suivants : Comment puis-je purger et réduire mon CSS sans problème ? Comment puis-je écrire du CSS qui soit à la fois facile à collaborer et à intégrer dans différents environnements ?

La solution était assez simple : utilisez simplement Tailwind CSS.

Avec cette approche, j'ai identifié les avantages suivants :

• Plus de styles conflictuels : Utiliser Tailwind m'a permis de ne plus m'inquiéter des styles conflictuels. Par exemple, lorsque j'ai affaire à une application héritée fortement dépendante de Bootstrap, j'ai simplement appliqué un préfixe et un indicateur important à mon widget, et les conflits ont été résolus.

• Intégration transparente : lors de l'importation de mon widget dans une autre application Tailwind, je pourrais facilement omettre certaines directives Tailwind pour réduire la taille de mon bundle.

• Purge et minification sans effort : la minification est devenue simple, et avec le PurgeCSS intégré de Tailwind, j'avais juste besoin de configurer correctement l'indicateur de contenu pour chaque widget. Cela garantissait que seuls les styles nécessaires étaient inclus dans le lot final.

Comment ai-je résolu les problèmes de test ?

J'ai été confronté à un défi pour garantir des tests complets pour mes widgets, couvrant les tests unitaires, les tests d'intégration et les tests visuels.

Mon objectif principal était de visualiser mes composants avant et après leur traitement avec Rollup. Pour y parvenir, j'ai suivi les étapes suivantes :

• Livre d'histoires strictement typé : J'ai implémenté un livre d'histoires strictement typé basé sur mes fichiers déclaration.d.ts et types.ts. Cela a permis de générer automatiquement une histoire par défaut pour chacun de mes widgets.

• Intégration Vite : J'ai utilisé Vite pour charger le composant fourni sur une route Svelte. Il était également pratique de générer un composant de route par défaut basé sur mes fichiers TypeScript.

C'était tout ! J'apprécierais de tout cœur vos commentaires ! Consultez également svelte-standalone.

Que vous ayez des questions, des suggestions ou des préoccupations, n'hésitez pas à me contacter !