Einführung in SvelteKit 1.0: Das Full-Stack-Framework für Svelte

Jan 05, 2024

Von Matthew Tyson

Softwarearchitekt, InfoWorld |

Wie kürzlich bekannt gegeben wurde, hat SvelteKit nach einer langen Betaphase seinen mit Spannung erwarteten Meilenstein 1.0 erreicht. SvelteKit 1.0 bietet ein vollständig realisiertes Anwendungsframework zum Erstellen von Full-Stack-JavaScript-Anwendungen mit Svelte-Frontends. Lass uns einen Blick darauf werfen.

Svelte ist ein reaktives Front-End-Framework, vergleichbar mit React oder Vue auf hohem Niveau, aber mit einem eigenen Blickwinkel auf die Dinge. SvelteKit ist das Full-Stack-Anwendungsframework für Svelte, ähnlich wie Next oder Nuxt, aber wiederum mit eigenen Konventionen.

Die Natur eines Full-Stack-Anwendungsframeworks besteht darin, dass es in der Lage sein muss, das Front-End und Back-End Ihrer Anwendung unter einem einzigen Dach zu vereinen. Ein Full-Stack-Framework muss diese Fragen beantworten:

Das Herzstück jedes Anwendungsframeworks ist die Routing-Engine, die den Code, der die Seiten generiert, mit den URLs im Browser verknüpft. Die meisten JavaScript-Frameworks wie SvelteKit haben sich an das allgemeine Layout von Next.js gewöhnt, bei dem die Dateien und Verzeichnisse dem URL-Pfad zugeordnet sind.

Das Stammverzeichnis von SvelteKit ist /src/routes (standardmäßig). /src/routes entspricht also der Root-URL, zum Beispiel localhost:5173/ im Browser. Unterverzeichnisse werden dem URL-Pfad zugeordnet, sodass /src/routes/foo/bar zu localhost:5173/foo/bar wird.

Mehrere Dateikonventionen innerhalb der Verzeichnisse definieren die Seiten und Endpunkte. Diese Dateitypen beginnen mit einem Pluszeichen (+), was darauf hinweist, dass sie eine besondere Bedeutung für das Framework haben. (Alle anderen Dateien werden ignoriert, sodass Sie Hilfsdateien in denselben Verzeichnissen ablegen können.)

Jede Seite ist eine Svelte-Komponente, definiert in einer +page.svelte-Datei. Eine Datei unter /src/routes/foo/bar/+page.svelte wird zur Webseite unter localhost:5173/foo/bar, definiert durch die in dieser Datei erstellte Svelte-Komponente. (Durch die Bereitstellung der Standardseite auf der Route fungiert diese Datei in einer ähnlichen Rolle wie index.jsx in anderen Frameworks.) Mit anderen Worten: +page.svelte ist nur eine Standard-Svelte-Komponente, die der normalen Svelte-Syntax folgt.

Obwohl +page.svelte nur eine Front-End-Svelte-Komponente ist, kann es für seine Arbeit auf andere spezielle Dateien zurückgreifen. SvelteKit hat auch einige praktische Optimierungen auf Lager. Standardmäßig rendert SvelteKit +page.svelte serverseitig. Zur Steuerung dieses Prozesses wird die Geschwisterdatei +page.js (mit der Erweiterung .js) verwendet. Die beiden Komponenten +page.svelte und +page.js arbeiten zusammen, um das Full-Stack-Verhalten der Seite zu definieren.

Mit der +page.js-Komponente können wir eine Ladefunktion definieren, die Vorarbeiten ausführen kann, die die Seitenkomponente benötigt, und außerdem steuern kann, wie das Framework die Seite im Hinblick auf das Rendering-Verhalten behandelt. Diese Komponente unterstützt drei konstante Exporte:

Weitere Informationen zum Rendern von Seiten mit diesen Optionen finden Sie in der SvelteKit-Dokumentation. Hier konzentrieren wir uns auf die von +page.js exportierte Ladefunktion. Standardmäßig wird es zusammen mit +page.svelte sowohl auf dem Server als auch auf dem Client ausgeführt. Die Ladefunktion kommuniziert mit der Svelte-Komponente über eine Datenvariable. Was auch immer die Exportfunktion von +page.js zurückgibt, wird auf die Export-Let-Datenvariable von +page.svelte gesetzt.

Da die Ladefunktion +page.js sowohl auf dem Client als auch auf dem Server ausgeführt wird, muss sie Funktionen enthalten, die sowohl in der Browser- als auch in der Back-End-Umgebung funktionieren. Wenn Sie eine Funktion benötigen, die nur auf dem Server ausgeführt wird, können Sie +page.server.js verwenden. Die dortige Ladefunktion wird ausschließlich im Backend ausgeführt. Wenn das serverseitige Rendering (SSR) die Kontrolle hat, können die Daten in das Rendering integriert werden; Wenn das clientseitige Rendering aktiv ist, wird der Code auf dem Server ausgeführt und serialisiert und übertragen. (Weitere Informationen zur Auswahl zwischen einer „universellen“ Ladefunktion und einer nur serverseitigen Ladefunktion finden Sie in der SvelteKit-Dokumentation.)

Zusätzlich zum Laden kann +page.server.js eine Aktionsfunktion zur Verarbeitung von Formulardaten definieren. (Dies ähnelt der Art und Weise, wie Remix Formulare erstellt und ermöglicht, dass Formulare funktionieren, wenn JavaScript nicht verfügbar ist.)

Wenn Sie einen URL-Parameter (auch „Slug“ genannt) benötigen, können Sie ihn in Klammern setzen. Beispielsweise stellt /src/routes/foo/bar/[id] eine ID-Variable für +page.js (oder +page.server.js) als Teil des Parameterarguments für die Ladefunktion bereit: Export async function load ({ fetch }) { param.id }.

Sie können mit +server.js auch reine Serverrouten für die Verarbeitung von API-Endpunkten definieren. Diese Funktion verarbeitet die bekannten REST-Methoden wie GET, PUT usw. Jedes davon wird durch den Export einer Funktion behandelt, die der Methode entspricht; Beispielsweise verarbeitet die Exportfunktion GET({ url }) die GET-Methode, die diese Datei ankommt. Eine /src/routes/foo/bar/+server.js GET-Funktion antwortet also auf eine localhost:5173/foo/bar GET-Anfrage.

Auch wenn wir sie hier nicht behandeln, gibt es noch ein paar weitere spezielle Seiten, die Sie kennen sollten:

Beachten Sie, dass Layouts hierarchische Layouts unterstützen und Sie deren Verhalten optimieren können.

Links sind einfache -Links und keine spezielle Komponente. SvelteKit untersucht die Links in der Anwendung und wenn sie auf eine Seite innerhalb der Anwendung selbst verweisen (und nicht auf einen externen Link), übernimmt die Navigation von SvelteKit. SvelteKit berücksichtigt Webstandardanweisungen wie Prefetch für Links.

Die Verbindungsbereiche zwischen Anwendungsschichten, in denen Front- und Back-End kommunizieren, unterstützen starke Typisierung über TypeScript- oder JSDoc @typedef-Annotationen in JavaScript. Wenn Sie beispielsweise JavaScript verwenden, würde die Funktion „load()“ mit einer Annotation wie /** @type {import('./$types').PageLoad} */ versehen. SvelteKit würde diese Anweisung verwenden, um die Typensicherheit zu gewährleisten. Dadurch würde auch sichergestellt, dass der Objekttyp, der im Datenobjekt der Datei +page.svelte ankommt, eine PageData-Klasse ist, wie durch /** @type {import('./$types').PageData} */ definiert.

In ähnlicher Weise werden Ladefunktionen für +page.server.js mit /** @type {import('./$types').PageServerLoad} */ dekoriert. Alle diese Typen werden von SvelteKit automatisch generiert, damit Sie sie in Ihren Anwendungen verwenden können.

Eine der größten Möglichkeiten, wie ein Framework die Entwicklung erleichtern kann, besteht darin, die Bereitstellung der Anwendung in der Produktion zu vereinfachen. SvelteKit antwortet auf diesen Bedarf mit Adaptern, die die Dev-Mode-App in ein bereitstellbares Paket für eine Vielzahl von Zielumgebungen umwandeln. Sie können die Bereitstellung auf einer statischen Site, einem Node- oder Express-Stack oder am Edge mit einem Dienst wie Vercel durchführen.

Standardmäßig verwendet SvelteKit einen „Auto“-Adapter, der bei der Bereitstellung auf Cloudflare, Netlify oder Vercel keinen Eingriff erfordert. Sobald Sie eine Plattform für die Nutzung des Anwendungscodes konfiguriert haben, erstellt und stellt der Standardadapter Ihr Projekt für Sie bereit.

Möglicherweise haben Sie Seiten, die rein statischen Inhalt haben, selbst inmitten einer ansonsten dynamischen Einzelseitenanwendung (Svelte-Gründer Rich Harris nennt diese Art von Anwendung „Übergangsanwendung“). Beispielsweise könnte eine „Info“-Seite nur statische Inhalte bereitstellen, die für alle gleich sind. Das Vorrendern einer solchen Seite würde die größtmögliche Geschwindigkeit bringen, ohne dass eine Hydratation erforderlich wäre. Hier können Sie die Export-Prerender-Option in +page.js auf false setzen.

Wenn Sie tatsächlich über eine gesamte Site verfügen, die vorab gerendert werden kann, ist es möglich, die gesamte Site mithilfe einer statischen Build-Ausgabe als statische Anwendung auszugeben. Weitere Informationen zum Vorrendern finden Sie in der SvelteKit-Dokumentation.

Wenn Sie mit SvelteKit 1.0 beginnen möchten, können Sie zunächst eine Anwendung auf der Befehlszeilenschnittstelle erstellen, indem Sie den folgenden Befehl verwenden: npm create svelte@latest sveltekit-demo. Dadurch wird die in Listing 1 gezeigte kurze interaktive Eingabeaufforderung gestartet.

Beachten Sie in der ersten Frage, dass Sie zwischen einem Skelettprojekt und einem Bibliotheksgerüstprojekt wählen können. SvelteKit unterstützt neben typischen Webanwendungen auch Bibliotheken. Während es sich bei einer Webanwendung um eine Reihe von Bibliotheken handelt, deren Endprodukt eine nutzbare Benutzeroberfläche ist, handelt es sich bei einer Bibliothek um eine Reihe von Bibliotheken, die von anderen Projekten genutzt werden und deren Benutzeroberfläche normalerweise die Dokumentation für die Bibliothek ist. Weitere Informationen zum Unterschied zwischen dem Packen einer Bibliothek oder einer UI-Distribution finden Sie in der SvelteKit-Dokumentation.

Als nächstes werden Sie gefragt, ob Sie JSDoc oder TypeScript zum Definieren der Anwendung verwenden möchten. Sie haben die JSDoc-Typdefinition bereits in Aktion gesehen. Hier können Sie dem Generator mitteilen, welche Syntax Sie verwenden möchten.

Wenn Sie die Option „Ratespiel“ auswählen, gibt der App-Ersteller eine Anwendung aus, die viele der hier besprochenen Funktionen nutzt. Diese werden in einem Verzeichnis mit dem von Ihnen angegebenen Namen abgelegt – zum Beispiel sveltekit-demo.

Sie werden feststellen, dass die Anwendung mit dem Vite-Bundler erstellt wurde und die meisten Befehle für die Anwendung Vite-Befehle sind. Beispielsweise können Sie nach der Installation der Abhängigkeiten mit npm install den Entwicklungsserver mit npm run dev ausführen. (Wenn Sie sich nicht auf localhost befinden, verwenden Sie den Schalter --host, um die Anwendung dem Netzwerk zugänglich zu machen.) Anschließend können Sie die Demoanwendung öffnen und auf den Link „Sverdle“ klicken, um das Spiel in Aktion zu sehen, wie im folgenden Screenshot gezeigt .

Abbildung 1. Die Demoanwendung Sverdle.

Obwohl SvelteKit noch viel mehr zu bieten hat und viele Optionen zu erkunden sind, haben Sie die Grundlagen kennengelernt. SvelteKit ist eine umfassende Antwort auf die Nachfrage nach einem Anwendungsframework für die Verwendung von Svelte. Als Framework ähnelt es anderen wie Next. Es erfüllt nicht nur seinen Zweck, es ist auch eine gut durchdachte Antwort auf die anhaltende Diskussion über die Entwicklung intelligenterer Software für das Web. Die in SvelteKit gefundenen Ideen werden sicherlich die zukünftige Richtung dieses Gesprächs beeinflussen.

Lesen Sie als nächstes Folgendes:

Matthew Tyson ist Gründer der Dark Horse Group, Inc. Er glaubt an Technologie, bei der der Mensch im Mittelpunkt steht. Wenn Matt nicht gerade Gitarre spielt, erkundet er das Hinterland und das philosophische Hinterland. Seit 2007 schreibt er für JavaWorld und InfoWorld.

Copyright © 2023 IDG Communications, Inc.