My previous post war ein umfassender Überblick über SvelteKit, bei dem wir sahen, was für ein großartiges Tool es für die Webentwicklung ist. Dieser Beitrag wird abzweigen, was wir dort getan haben, und in das Lieblingsthema jedes Entwicklers eintauchen: Caching. Also, lesen Sie unbedingt meinen letzten Beitrag, falls Sie es noch nicht getan haben. Der Code für diesen Beitrag ist auf GitHub verfügbar, sowie eine Live-Demo.
In diesem Beitrag dreht sich alles um den Umgang mit Daten. Wir werden einige rudimentäre Suchfunktionen hinzufügen, die die Abfragezeichenfolge der Seite ändern (unter Verwendung integrierter SvelteKit-Funktionen) und den Ladevorgang der Seite erneut auslösen. Aber anstatt nur unsere (imaginäre) Datenbank erneut abzufragen, fügen wir etwas Caching hinzu, damit die erneute Suche nach früheren Suchen (oder die Verwendung der Zurück-Schaltfläche) zuvor abgerufene Daten schnell aus dem Cache anzeigt. Wir sehen uns an, wie man steuert, wie lange die zwischengespeicherten Daten gültig bleiben, und, was noch wichtiger ist, wie man alle zwischengespeicherten Werte manuell ungültig macht. Als i-Tüpfelchen sehen wir uns an, wie wir die Daten auf dem aktuellen Bildschirm clientseitig nach einer Mutation manuell aktualisieren können, während der Cache weiterhin geleert wird.
Dies wird ein längerer und schwierigerer Beitrag als das meiste, was ich normalerweise schreibe, da wir schwierigere Themen behandeln. Dieser Beitrag zeigt Ihnen im Wesentlichen, wie Sie allgemeine Funktionen beliebter Datendienstprogramme wie implementieren Reagieren-Abfrage; Aber anstatt eine externe Bibliothek einzubinden, verwenden wir nur die Webplattform und die SvelteKit-Funktionen.
Leider sind die Funktionen der Webplattform etwas niedriger, daher werden wir etwas mehr Arbeit leisten, als Sie es vielleicht gewohnt sind. Der Vorteil ist, dass wir keine externen Bibliotheken benötigen, was dazu beiträgt, die Paketgrößen schön klein zu halten. Bitte verwenden Sie die Ansätze, die ich Ihnen zeigen werde, nicht, es sei denn, Sie haben einen guten Grund dazu. Beim Caching kann man leicht Fehler machen, und wie Sie sehen werden, ist Ihr Anwendungscode etwas komplex. Hoffentlich ist Ihr Datenspeicher schnell und Ihre Benutzeroberfläche in Ordnung, sodass SvelteKit einfach immer die Daten anfordern kann, die es für eine bestimmte Seite benötigt. Wenn ja, lass es in Ruhe. Genießen Sie die Einfachheit. Aber dieser Beitrag wird Ihnen einige Tricks zeigen, wenn das nicht mehr der Fall ist.
Apropos Reaktionsabfrage, it wurde gerade veröffentlicht für Svelte! Wenn Sie sich also auf manuelle Caching-Techniken verlassen viel, überprüfen Sie unbedingt dieses Projekt und prüfen Sie, ob es hilfreich sein könnte.
Einrichten
Bevor wir beginnen, nehmen wir ein paar kleine Änderungen an vor der Code, den wir vorher hatten. Dies wird uns eine Entschuldigung geben, einige andere SvelteKit-Funktionen zu sehen, und, was noch wichtiger ist, uns auf den Erfolg vorbereiten.
Lassen Sie uns zuerst das Laden unserer Daten von unserem Loader verschieben +page.server.js ein API-Route. Wir erstellen eine +server.js Datei in routes/api/todos, und fügen Sie dann a . hinzu GET Funktion. Das bedeutet, dass wir jetzt (mit dem standardmäßigen GET-Verb) in die abrufen können /api/todos Weg. Wir fügen denselben Datenladecode wie zuvor hinzu.
import { json } from "@sveltejs/kit";
import { getTodos } from "$lib/data/todoData"; export async function GET({ url, setHeaders, request }) { const search = url.searchParams.get("search") || ""; const todos = await getTodos(search); return json(todos);
}Als nächstes nehmen wir den Seitenlader, den wir hatten, und benennen einfach die Datei um +page.server.js zu +page.js (oder .ts wenn Sie Ihr Projekt für die Verwendung von TypeScript gerüstet haben). Dadurch wird unser Loader zu einem „universellen“ Loader statt zu einem Server-Loader. Die SvelteKit-Dokumentation erkläre den Unterschied, aber sowohl auf dem Server als auch auf dem Client läuft ein universeller Loader. Ein Vorteil für uns ist, dass die fetch Aufruf an unseren neuen Endpunkt wird direkt von unserem Browser (nach dem anfänglichen Laden) ausgeführt, wobei die native des Browsers verwendet wird fetch Funktion. Wir werden in Kürze Standard-HTTP-Caching hinzufügen, aber im Moment rufen wir nur den Endpunkt auf.
export async function load({ fetch, url, setHeaders }) { const search = url.searchParams.get("search") || ""; const resp = await fetch(`/api/todos?search=${encodeURIComponent(search)}`); const todos = await resp.json(); return { todos, };
}Lassen Sie uns nun ein einfaches Formular zu unserem hinzufügen /list Seite:
<div class="search-form"> <form action="/de/list"> <label>Search</label> <input autofocus name="search" /> </form>
</div>Ja, Formulare können direkt auf unsere normalen Seitenlader zielen. Jetzt können wir einen Suchbegriff in das Suchfeld eingeben, klicken Enter, und ein „Suchbegriff“ wird an die Abfragezeichenfolge der URL angehängt, wodurch unser Ladeprogramm erneut ausgeführt und unsere To-do-Elemente durchsucht werden.
Lassen Sie uns auch die Verzögerung in unserem erhöhen todoData.js Datei in /lib/data. Dies macht es einfach zu erkennen, wann Daten zwischengespeichert werden und wann nicht, während wir diesen Beitrag durcharbeiten.
export const wait = async amount => new Promise(res => setTimeout(res, amount ?? 500));Denken Sie daran, der vollständige Code für diesen Beitrag ist alles auf GitHub, wenn Sie darauf verweisen müssen.
Grundlegendes Caching
Beginnen wir damit, etwas Caching zu unserem hinzuzufügen /api/todos Endpunkt. Wir gehen zurück zu unserem +server.js Datei und fügen Sie unseren ersten Cache-Control-Header hinzu.
setHeaders({ "cache-control": "max-age=60",
});…was die ganze Funktion so aussehen lässt:
export async function GET({ url, setHeaders, request }) { const search = url.searchParams.get("search") || ""; setHeaders({ "cache-control": "max-age=60", }); const todos = await getTodos(search); return json(todos);
}Wir werden uns in Kürze mit der manuellen Invalidierung befassen, aber diese Funktion besagt lediglich, dass diese API-Aufrufe 60 Sekunden lang zwischengespeichert werden. Stellen Sie dies auf das ein, was Sie möchten, und abhängig von Ihrem Anwendungsfall, stale-while-revalidate wäre vielleicht auch eine untersuchung wert.
Und einfach so werden unsere Abfragen zwischengespeichert.
Note Stell sicher, dass du Deaktivieren Sie das Kontrollkästchen das Kontrollkästchen, das das Caching in den Entwicklungstools deaktiviert.
Denken Sie daran, dass diese Suchergebnisse intern in SvelteKit zwischengespeichert werden, wenn Ihre anfängliche Navigation in der App die Listenseite ist. Erwarten Sie also nicht, etwas in DevTools zu sehen, wenn Sie zu dieser Suche zurückkehren.
Was wird wo gecacht
Unser allererster, vom Server gerenderter Ladevorgang unserer App (vorausgesetzt, wir beginnen bei der /list Seite) werden auf dem Server abgerufen. SvelteKit wird diese Daten serialisieren und an unseren Kunden senden. Darüber hinaus wird es die beobachten Cache-Control Kopfzeile auf die Antwort und weiß, dass diese zwischengespeicherten Daten für diesen Endpunktaufruf innerhalb des Cache-Fensters verwendet werden müssen (das wir im Put-Beispiel auf 60 Sekunden festgelegt haben).
Wenn Sie nach diesem anfänglichen Laden mit der Suche auf der Seite beginnen, sollten Sie Netzwerkanfragen von Ihrem Browser an die sehen /api/todos Liste. Wenn Sie nach Dingen suchen, nach denen Sie bereits gesucht haben (innerhalb der letzten 60 Sekunden), sollten die Antworten sofort geladen werden, da sie zwischengespeichert sind.
Besonders cool an diesem Ansatz ist, dass diese Aufrufe, da dies über das native Caching des Browsers erfolgt, (je nachdem, wie Sie das Cache-Busting verwalten, das wir uns ansehen werden) weiterhin zwischenspeichern könnten, selbst wenn Sie die Seite neu laden (im Gegensatz zum anfänglicher serverseitiger Ladevorgang, der den Endpunkt immer neu aufruft, selbst wenn er dies innerhalb der letzten 60 Sekunden getan hat).
Offensichtlich können sich Daten jederzeit ändern, daher brauchen wir eine Möglichkeit, diesen Cache manuell zu löschen, was wir uns als Nächstes ansehen werden.
Cache-Ungültigmachung
Momentan werden Daten für 60 Sekunden zwischengespeichert. Egal was passiert, nach einer Minute werden frische Daten aus unserem Datenspeicher gezogen. Sie möchten vielleicht einen kürzeren oder längeren Zeitraum, aber was passiert, wenn Sie einige Daten ändern und Ihren Cache sofort löschen möchten, damit Ihre nächste Abfrage aktuell ist? Wir werden dies lösen, indem wir der URL, die wir an unsere neue senden, einen Abfrage-Busting-Wert hinzufügen /todos Endpunkt.
Lassen Sie uns diesen Cache-Busting-Wert in einem Cookie speichern. Dieser Wert kann auf dem Server festgelegt, aber dennoch auf dem Client gelesen werden. Schauen wir uns einen Beispielcode an.
Wir können eine erstellen +layout.server.js Datei an der Wurzel unserer routes Mappe. Dies wird beim Start der Anwendung ausgeführt und ist ein perfekter Ort, um einen anfänglichen Cookie-Wert festzulegen.
export function load({ cookies, isDataRequest }) { const initialRequest = !isDataRequest; const cacheValue = initialRequest ? +new Date() : cookies.get("todos-cache"); if (initialRequest) { cookies.set("todos-cache", cacheValue, { path: "/", httpOnly: false }); } return { todosCacheBust: cacheValue, };
}Möglicherweise haben Sie das bemerkt isDataRequest Wert. Denken Sie daran, dass Layouts bei jedem Client-Code-Aufruf erneut ausgeführt werden invalidate(), oder jedes Mal, wenn wir eine Serveraktion ausführen (vorausgesetzt, wir deaktivieren das Standardverhalten nicht). isDataRequest zeigt diese Wiederholungen an, und wir setzen das Cookie nur, wenn dies der Fall ist false; ansonsten schicken wir mit, was schon da ist.
Das httpOnly: false Flagge ist auch wichtig. Dadurch kann unser Client-Code diese Cookie-Werte einlesen document.cookie. Dies wäre normalerweise ein Sicherheitsproblem, aber in unserem Fall sind dies bedeutungslose Zahlen, die es uns ermöglichen, zu cachen oder zu cachen.
Cache-Werte lesen
Unser Universallader ist unser /todos Endpunkt. Dies läuft auf dem Server oder dem Client, und wir müssen diesen Cache-Wert lesen, den wir gerade eingerichtet haben, egal wo wir uns befinden. Wenn wir auf dem Server sind, ist es relativ einfach: Wir können anrufen await parent() um die Daten von übergeordneten Layouts zu erhalten. Aber auf dem Client müssen wir groben Code zum Analysieren verwenden document.cookie:
export function getCookieLookup() { if (typeof document !== "object") { return {}; } return document.cookie.split("; ").reduce((lookup, v) => { const parts = v.split("="); lookup[parts[0]] = parts[1]; return lookup; }, {});
} const getCurrentCookieValue = name => { const cookies = getCookieLookup(); return cookies[name] ?? "";
};Zum Glück brauchen wir es nur einmal.
Senden des Cache-Werts
Aber jetzt müssen wir senden dieser Wert zu unserem /todos Endpunkt.
import { getCurrentCookieValue } from "$lib/util/cookieUtils"; export async function load({ fetch, parent, url, setHeaders }) { const parentData = await parent(); const cacheBust = getCurrentCookieValue("todos-cache") || parentData.todosCacheBust; const search = url.searchParams.get("search") || ""; const resp = await fetch(`/api/todos?search=${encodeURIComponent(search)}&cache=${cacheBust}`); const todos = await resp.json(); return { todos, };
}getCurrentCookieValue('todos-cache') hat eine Prüfung darin, um zu sehen, ob wir auf dem Client sind (durch Überprüfung des Dokumenttyps), und gibt nichts zurück, wenn wir es sind, an diesem Punkt wissen wir, dass wir auf dem Server sind. Dann verwendet es den Wert aus unserem Layout.
Busten des Caches
Jedoch müssen auch wie aktualisieren wir diesen Cache-Busting-Wert tatsächlich, wenn es nötig ist? Da es in einem Cookie gespeichert ist, können wir es von jeder Serveraktion aus so aufrufen:
cookies.set("todos-cache", cacheValue, { path: "/", httpOnly: false });Die Umsetzung
Es ist alles bergab von hier; wir haben die harte Arbeit geleistet. Wir haben die verschiedenen Webplattform-Grundelemente behandelt, die wir benötigen, und auch, wohin sie gehen. Lassen Sie uns jetzt etwas Spaß haben und Anwendungscode schreiben, um alles miteinander zu verbinden.
Aus Gründen, die gleich klar werden, fangen wir damit an, unserer eine Bearbeitungsfunktion hinzuzufügen /list Seite. Wir fügen diese zweite Tabellenzeile für jede Aufgabe hinzu:
import { enhance } from "$app/forms";<tr> <td colspan="4"> <form use:enhance method="post" action="?/editTodo"> <input name="id" value="{t.id}" type="hidden" /> <input name="title" value="{t.title}" /> <button>Save</button> </form> </td>
</tr>Und natürlich müssen wir eine Formularaktion für unsere hinzufügen /list Seite. Aktionen können nur hineingehen .server Seiten, also fügen wir eine hinzu +page.server.js in unserer /list Mappe. (Ja ein +page.server.js Datei kann neben einer koexistieren +page.js Datei.)
import { getTodo, updateTodo, wait } from "$lib/data/todoData"; export const actions = { async editTodo({ request, cookies }) { const formData = await request.formData(); const id = formData.get("id"); const newTitle = formData.get("title"); await wait(250); updateTodo(id, newTitle); cookies.set("todos-cache", +new Date(), { path: "/", httpOnly: false }); },
};Wir greifen auf die Formulardaten zu, erzwingen eine Verzögerung, aktualisieren unsere Aufgaben und löschen dann, was am wichtigsten ist, unser Cache-Bust-Cookie.
Probieren wir es aus. Laden Sie Ihre Seite neu und bearbeiten Sie dann einen der To-do-Einträge. Sie sollten die Tabellenwertaktualisierung nach einem Moment sehen. Wenn Sie in DevToold auf die Registerkarte Netzwerk schauen, sehen Sie einen Abruf an die /todos endpoint, der Ihre neuen Daten zurückgibt. Einfach und funktioniert standardmäßig.
Sofortige Updates
Was ist, wenn wir diesen Abruf vermeiden möchten, der nach dem Aktualisieren unseres To-Do-Elements auftritt, und stattdessen das geänderte Element direkt auf dem Bildschirm aktualisieren möchten?
Das ist nicht nur eine Frage der Leistung. Wenn Sie nach „Post“ suchen und dann das Wort „Post“ aus einem der To-do-Elemente in der Liste entfernen, verschwinden diese nach der Bearbeitung aus der Liste, da sie nicht mehr in den Suchergebnissen dieser Seite enthalten sind. Sie könnten die UX mit einigen geschmackvollen Animationen für die aufregenden Aufgaben verbessern, aber nehmen wir an, wir wollten es nicht Führen Sie die Ladefunktion dieser Seite erneut aus, leeren Sie aber dennoch den Cache und aktualisieren Sie die geänderte Aufgabe, damit der Benutzer die Änderung sehen kann. SvelteKit macht das möglich – mal sehen wie!
Nehmen wir zunächst eine kleine Änderung an unserem Loader vor. Anstatt unsere zu erledigenden Artikel zurückzugeben, geben wir a zurück beschreibbarer Speicher mit unseren To-dos.
return { todos: writable(todos),
};Vorher haben wir auf unsere To-dos auf der zugegriffen data prop, die wir nicht besitzen und nicht aktualisieren können. Aber Svelte lässt uns unsere Daten in ihrem eigenen Speicher zurückgeben (vorausgesetzt, wir verwenden einen universellen Lader, was wir sind). Wir müssen nur noch eine weitere Änderung an unserem vornehmen /list
An Stelle von:
{#each todos as t}…da müssen wir das machen todos ist jetzt selbst ein Geschäft.:
{#each $todos as t}Jetzt werden unsere Daten wie zuvor geladen. Aber seit todos ein beschreibbarer Speicher ist, können wir ihn aktualisieren.
Lassen Sie uns zunächst eine Funktion für unsere bereitstellen use:enhance Attribut:
<form use:enhance={executeSave} on:submit={runInvalidate} method="post" action="?/editTodo"
>Dies wird vor einem Submit ausgeführt. Schreiben wir das als nächstes:
function executeSave({ data }) { const id = data.get("id"); const title = data.get("title"); return async () => { todos.update(list => list.map(todo => { if (todo.id == id) { return Object.assign({}, todo, { title }); } else { return todo; } }) ); };
}Diese Funktion bietet a data Objekt mit unseren Formulardaten. Wir Rückkehr eine asynchrone Funktion, die ausgeführt wird nachdem unsere Bearbeitung ist fertig. Die Dokumente Erklären Sie das alles, aber dadurch schalten wir die Standard-Formularbehandlung von SvelteKit aus, die unseren Loader erneut ausgeführt hätte. Genau das wollen wir! (Wir könnten dieses Standardverhalten leicht wiederherstellen, wie die Dokumentation erklärt.)
Wir rufen jetzt an update auf unserem todos Array, da es ein Geschäft ist. Und das ist das. Nach dem Bearbeiten eines To-do-Elements werden unsere Änderungen sofort angezeigt und unser Cache wird geleert (wie zuvor, da wir einen neuen Cookie-Wert in unserer editTodo Formularaktion). Wenn wir also suchen und dann zurück zu dieser Seite navigieren, erhalten wir neue Daten von unserem Loader, die alle aktualisierten To-Do-Elemente korrekt ausschließen, die aktualisiert wurden.
Der Code für die sofortigen Updates ist auf GitHub verfügbar.
Tiefer Graben
Wir können Cookies in jeder Serverladefunktion (oder Serveraktion) setzen, nicht nur im Root-Layout. Wenn also einige Daten nur unter einem einzelnen Layout oder sogar einer einzelnen Seite verwendet werden, können Sie diesen Cookie-Wert dort festlegen. Außerdem, wenn Sie sind nicht Wenn Sie den Trick machen, den ich gerade gezeigt habe, aktualisieren Sie die Bildschirmdaten manuell und möchten stattdessen, dass Ihr Lader nach einer Mutation erneut ausgeführt wird. Dann können Sie jederzeit einen neuen Cookie-Wert direkt in dieser Ladefunktion ohne Überprüfung festlegen isDataRequest. Es wird anfangs eingestellt, und jedes Mal, wenn Sie eine Serveraktion ausführen, wird dieses Seitenlayout Ihren Loader automatisch ungültig machen und erneut aufrufen, wobei die Cache-Bust-Zeichenfolge zurückgesetzt wird, bevor Ihr universeller Loader aufgerufen wird.
Schreiben einer Reload-Funktion
Lassen Sie uns zum Abschluss ein letztes Feature erstellen: eine Schaltfläche zum erneuten Laden. Lassen Sie uns Benutzern eine Schaltfläche geben, die den Cache löscht und dann die aktuelle Abfrage neu lädt.
Wir fügen eine schmutzige einfache Formularaktion hinzu:
async reloadTodos({ cookies }) { cookies.set('todos-cache', +new Date(), { path: '/', httpOnly: false });
},In einem echten Projekt würden Sie wahrscheinlich nicht den gleichen Code kopieren/einfügen, um das gleiche Cookie an mehreren Stellen auf die gleiche Weise zu setzen, aber für diesen Beitrag optimieren wir die Einfachheit und Lesbarkeit.
Lassen Sie uns nun ein Formular erstellen, um es zu posten:
<form method="POST" action="?/reloadTodos" use:enhance> <button>Reload todos</button>
</form>Das funktioniert!
Wir könnten dies als erledigt bezeichnen und weitermachen, aber verbessern wir diese Lösung ein wenig. Lassen Sie uns insbesondere Feedback auf der Seite geben, um dem Benutzer mitzuteilen, dass das Neuladen stattfindet. Außerdem werden SvelteKit-Aktionen standardmäßig ungültig alles. Jedes Layout, jede Seite usw. in der Hierarchie der aktuellen Seite würde neu geladen. Möglicherweise gibt es einige Daten, die einmal im Stammlayout geladen wurden und die wir nicht ungültig machen oder erneut laden müssen.
Konzentrieren wir uns also ein wenig und laden unsere To-Dos nur neu, wenn wir diese Funktion aufrufen.
Lassen Sie uns zunächst eine Funktion zur Verbesserung übergeben:
<form method="POST" action="?/reloadTodos" use:enhance={reloadTodos}>import { enhance } from "$app/forms";
import { invalidate } from "$app/navigation"; let reloading = false;
const reloadTodos = () => { reloading = true; return async () => { invalidate("reload:todos").then(() => { reloading = false; }); };
};Wir stellen eine neue ein reloading variabel zu true im Anfang dieser Aktion. Und dann, um das Standardverhalten, alles ungültig zu machen, zu überschreiben, geben wir ein zurück async Funktion. Diese Funktion wird ausgeführt, wenn unsere Serveraktion beendet ist (was nur ein neues Cookie setzt).
Ohne das async Funktion zurückgegeben, würde SvelteKit alles ungültig machen. Da wir diese Funktion bereitstellen, wird sie nichts ungültig machen, also liegt es an uns, ihr zu sagen, was neu geladen werden soll. Das machen wir mit der invalidate Funktion. Wir nennen es mit einem Wert von reload:todos. Diese Funktion gibt ein Versprechen zurück, das aufgelöst wird, wenn die Invalidierung abgeschlossen ist, an welchem Punkt wir festlegen reloading zurück zur false.
Zuletzt müssen wir unseren Loader mit diesem neuen synchronisieren reload:todos Ungültigkeitswert. Das machen wir in unserem Lader mit dem depends Funktion:
export async function load({ fetch, url, setHeaders, depends }) { depends('reload:todos'); // rest is the sameUnd das ist das. depends und invalidate sind unglaublich nützliche Funktionen. Was cool ist, ist das invalidate nimmt nicht einfach willkürliche Werte, die wir bereitstellen, wie wir es getan haben. Wir können auch eine URL bereitstellen, die SvelteKit verfolgt, und alle Ladeprogramme ungültig machen, die von dieser URL abhängen. Zu diesem Zweck, wenn Sie sich fragen, ob wir den Anruf überspringen könnten depends und machen unsere ungültig /api/todos Endpunkt insgesamt können Sie, aber Sie müssen die bereitstellen genau URL, einschließlich der search Begriff (und unser Cache-Wert). Sie können also entweder die URL für die aktuelle Suche zusammenstellen oder den Pfadnamen wie folgt abgleichen:
invalidate(url => url.pathname == "/api/todos");Persönlich finde ich die Lösung, die verwendet depends deutlicher und einfacher. Aber siehe die docs für weitere Informationen natürlich und entscheiden Sie selbst.
Wenn Sie die Schaltfläche zum erneuten Laden in Aktion sehen möchten, finden Sie den Code dafür dieser Zweig des Repos.
Abschiedsgedanken
Das war ein langer Beitrag, aber hoffentlich nicht überwältigend. Wir haben uns mit verschiedenen Möglichkeiten beschäftigt, wie wir Daten bei der Verwendung von SvelteKit zwischenspeichern können. Vieles davon war nur eine Frage der Verwendung von Webplattform-Primitiven, um den richtigen Cache und Cookie-Werte hinzuzufügen, deren Kenntnis Ihnen bei der Webentwicklung im Allgemeinen über SvelteKit hinaus von Nutzen sein wird.
Darüber hinaus ist dies etwas, was Sie absolut brauche nicht ständig. Wahrscheinlich sollten Sie nur dann nach dieser Art von erweiterten Funktionen greifen, wenn Sie brauche sie eigentlich. Wenn Ihr Datenspeicher Daten schnell und effizient bereitstellt und Sie keinerlei Skalierungsprobleme haben, macht es keinen Sinn, Ihren Anwendungscode mit unnötiger Komplexität aufzublähen, indem Sie die Dinge tun, über die wir hier gesprochen haben.
Schreiben Sie wie immer klaren, sauberen und einfachen Code und optimieren Sie ihn bei Bedarf. Der Zweck dieses Beitrags war es, Ihnen diese Optimierungstools zur Verfügung zu stellen, wenn Sie sie wirklich brauchen. Ich hoffe, dass es Ihnen gefallen hat!
- SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
- Platoblockkette. Web3-Metaverse-Intelligenz. Wissen verstärkt. Hier zugreifen.
- Quelle: https://css-tricks.com/caching-data-in-sveltekit/
