Création de widgets autonomes avec Svelte : mon parcours et mes solutions

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. S'il était relativement simple de s'assurer qu'ils étaient fonctionnels, j'ai vite réalisé que les entretenir é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 j'aie 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 supporté et réutilisé sur toute mon application.

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

• Assurer les tests unitaires et d'intégration.
• Assurez-vous que je puisse 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 un defaultConfig basé 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 tracas ? 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 !

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!