Über die letzten Monate In den letzten Monaten hatte ich die Aufgabe herauszufinden, wie ich eigenständige Widgets für meinen Vollzeitjob schreiben und verwalten sollte. Während es relativ einfach war, sicherzustellen, dass sie funktionsfähig waren, wurde mir schnell klar, dass die Wartung eine ganz andere Herausforderung darstellt
Vor diesem Hintergrund habe ich in meiner Freizeit ein Nebenprojekt gestartet und es als Open Source bereitgestellt. Dadurch konnte ich meine Erkenntnisse und Strategien weitergeben, die mir geholfen haben, die Qualität meiner Widgets sicherzustellen.
Wie habe ich sie ursprünglich gemacht?
Da meine Widgets ein hohes Maß an Reaktivität erforderten, verließ ich mich stark auf die Svelte-Komponenten-API und nutzte Rollup zur Bündelung. „Es war einfach und direkt, bis ich folgende Probleme bekam:
Mein ungenutztes CSS nahm mit der Zeit zu und ich war mir auch nicht sicher, ob nur das CSS der gewünschten Komponente gebündelt wurde.
Schwierige Handhabung von JavaScript über Widgets ohne strikte Eingabe. Es wurde schnell zu einem Chaos, da ich einige Dienstprogramme wie JWT-Dekodierung und Authentifizierung teilen musste.
Wie habe ich es geändert?
Ich begann darüber nachzudenken, wie ich einige Standards festlegen und, was noch wichtiger ist, ein Typsystem integrieren könnte. Dies führte zur Entstehung meines Nebenprojekts svelte-standalone.
Das Ziel von svelte-standalone war:
- Stellen Sie ein gut minimiertes CSS sicher und entfernen Sie nicht verwendetes CSS beim Bündeln.
- Stellen Sie sicher, dass ein Typsystem Ihrer Wahl gut unterstützt und in allen meinen Apps wiederverwendet wird.
Hinweis: Das Typsystem der Wahl war TypeScript.
- Stellen Sie Unit- und Integrationstests sicher.
- Stellen Sie sicher, dass ich meine Widgets vor und nach dem Rollup-Parsen visuell überprüfen kann.
Wie habe ich das alles erreicht?
Nachdem ich die TypeScript-Kompatibilität mit Rollup-Plugins und dem Svelte-Präprozessor sichergestellt hatte, trat ich einen Schritt zurück und zerlegte mein Projekt in wichtige Schritte. Im Grunde hatte ich:
- Eine .svelte.
- Eine embed.js-Datei, die dafür verantwortlich ist, die Instanz der .svelte-Datei zu starten und sie dem Textkörper hinzuzufügen.
Dadurch bemerkte ich, dass meine Einbettungsdatei im Grunde eine Standarddatei war, die auf alle meine Widgets repliziert wurde, und begann mit deren Generierung. So konnte ich mithilfe von Codegen-Tools drei Dateien basierend auf meinen schlanken Dateien und meinem Wunsch, die Typen in der gesamten App zu verwalten, generieren:
- declaration.d.ts – aktiviert, dass ich meine Svelte-Komponente direkt importieren und mit dem SvelteComponent-Typ umschließen konnte, sodass ich meine Svelte-Komponenten standardmäßig stark typisiert gemacht habe.
- types.ts – aktiviert, dass ich eine Standardkonfiguration basierend auf den Requisiten schreiben kann, die in deklaration.d.ts deklariert wurden.
- embed.ts – Start/Stopp meiner Komponente auf standardmäßige Weise für alle meine Widgets aktiviert!
Und voilà! Dieser Ansatz löste meine Probleme mit dem Typsystem und verbesserte die Wartbarkeit meiner Widgets.
Wie ich CSS-Herausforderungen gemeistert habe:
Die größten CSS-bezogenen Herausforderungen, denen ich gegenüberstand, waren: Wie kann ich mein CSS problemlos bereinigen und minimieren? Wie kann ich CSS schreiben, an dem man leicht zusammenarbeiten und das man in verschiedene Umgebungen integrieren kann?
Die Lösung war ziemlich einfach: Verwenden Sie einfach Tailwind CSS.
Mit diesem Ansatz habe ich die folgenden Vorteile identifiziert:
Keine widersprüchlichen Stile mehr: Durch die Verwendung von Tailwind konnte ich mir keine Sorgen mehr über widersprüchliche Stile machen. Als ich es beispielsweise mit einer älteren App zu tun hatte, die stark von Bootstrap abhängig war, habe ich einfach ein Präfix und ein wichtiges Flag auf mein Widget angewendet und die Konflikte wurden gelöst.
Nahtlose Integration: Beim Importieren meines Widgets in eine andere Tailwind-App konnte ich bestimmte Tailwind-Anweisungen leicht weglassen, um meine Bundle-Größe zu reduzieren.
Müheloses Bereinigen und Minimieren: Das Minimieren wurde unkompliziert, und mit Tailwinds integriertem PurgeCSS musste ich nur das Inhaltsflag für jedes Widget richtig konfigurieren. Dadurch wurde sichergestellt, dass nur die erforderlichen Stile im endgültigen Paket enthalten waren.
Wie habe ich die Testprobleme gelöst?
Ich stand vor der Herausforderung, umfassende Tests für meine Widgets sicherzustellen, die Unit-Tests, Integrationstests und visuelle Tests umfassten.
Mein primäres Ziel war es, meine Komponenten sowohl vor als auch nach der Verarbeitung mit Rollup zu visualisieren. Um dies zu erreichen, habe ich folgende Schritte unternommen:
Streng typisiertes Storybook: Ich habe ein strikt typisiertes Storybook basierend auf meinen Dateien „declaration.d.ts“ und „types.ts“ implementiert. Dadurch war es praktisch, für jedes meiner Widgets automatisch eine Standard-Story zu generieren.
Vite-Integration: Ich habe Vite verwendet, um die gebündelte Komponente auf einer Svelte-Route zu laden. Es war auch praktisch, eine Standardroutenkomponente basierend auf meinen TypeScript-Dateien zu generieren.
Das war alles! Über ein Feedback würde ich mich sehr freuen! Schauen Sie sich auch Svelte-Standalone an.
Egal ob Sie Fragen, Anregungen oder Bedenken haben, kontaktieren Sie mich gerne!
Das obige ist der detaillierte Inhalt vonErstellen eigenständiger Widgets mit Svelte: Meine Reise und Lösungen. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
