My הפוסט הקודם הייתה סקירה רחבה של SvelteKit שבה ראינו איזה כלי נהדר זה לפיתוח אתרים. הפוסט הזה יסתלק מה שעשינו שם ויצלול לנושא האהוב על כל מפתח: מטמון. אז, הקפד לקרוא את הפוסט האחרון שלי אם עדיין לא עשית זאת. הקוד לפוסט הזה זמין ב- GitHub, בנוסף ל הדגמה חיה.
פוסט זה עוסק כולו בטיפול בנתונים. נוסיף פונקציונליות חיפוש בסיסית שתשנה את מחרוזת השאילתות של הדף (באמצעות תכונות מובנות של SvelteKit), ותפעיל מחדש את טוען העמוד. אבל, במקום רק לבצע שאילתה מחדש במסד הנתונים (הדמיוני) שלנו, נוסיף קצת מטמון כך שחיפוש חוזר בחיפושים קודמים (או שימוש בלחצן 'הקודם') יציג נתונים שאוחזרו בעבר, במהירות, מהמטמון. נבחן כיצד לשלוט על משך הזמן שהנתונים המאוחסנים נשארים תקפים, וחשוב מכך, כיצד לבטל באופן ידני את כל הערכים המאוחסנים במטמון. כדובדבן שבקצפת, נראה כיצד נוכל לעדכן באופן ידני את הנתונים במסך הנוכחי, בצד הלקוח, לאחר מוטציה, תוך כדי טיהור המטמון.
זה יהיה פוסט ארוך וקשה יותר מרוב מה שאני כותב בדרך כלל מכיוון שאנו מכסים נושאים קשים יותר. פוסט זה יראה לך בעצם כיצד ליישם תכונות נפוצות של כלי עזר פופולריים לנתונים כמו תגובה-שאילתה; אבל במקום להכניס ספרייה חיצונית, נשתמש רק בפלטפורמת האינטרנט ובתכונות SvelteKit.
לרוע המזל, התכונות של פלטפורמת האינטרנט הן ברמה מעט נמוכה יותר, כך שאנו נעשה קצת יותר עבודה ממה שהיית רגיל אליה. היתרון הוא שלא נזדקק לשום ספרייה חיצונית, מה שיעזור לשמור על גדלי חבילות יפים וקטנים. בבקשה אל תשתמש בגישות שאני הולך להראות לך אלא אם יש לך סיבה טובה לכך. קל לטעות בשמירת מטמון, וכפי שתראה, יש מעט מורכבות שתגרום לקוד היישום שלך. אני מקווה שמאגר הנתונים שלך מהיר, וממשק המשתמש שלך בסדר, מה שמאפשר ל-SvelteKit פשוט תמיד לבקש את הנתונים שהוא צריך עבור כל דף נתון. אם כן, עזוב את זה בשקט. תהנה מהפשטות. אבל הפוסט הזה יראה לך כמה טריקים מתי זה יפסיק להיות המקרה.
אם כבר מדברים על תגובה-שאילתה, זה רק שוחרר עבור Svelte! אז אם אתה מוצא את עצמך נשען על טכניקות מטמון ידניות הרבה, הקפד לבדוק את הפרויקט הזה ולראות אם הוא עשוי לעזור.
מגדיר
לפני שנתחיל, בואו נעשה כמה שינויים קטנים ב הקוד שהיה לנו קודם. זה ייתן לנו תירוץ לראות כמה תכונות אחרות של SvelteKit, וחשוב מכך, יגרום לנו להצלחה.
ראשית, בואו נעביר את טעינת הנתונים שלנו מהמטען שלנו +page.server.js כדי מסלול API. אנחנו ניצור א +server.js קובץ ב routes/api/todosולאחר מכן הוסף א GET פוּנקצִיָה. המשמעות היא שעכשיו נוכל להביא (באמצעות פועל ברירת המחדל GET) ל- /api/todos נָתִיב. נוסיף את אותו קוד טעינת נתונים כמו קודם.
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);
}לאחר מכן, ניקח את טוען הדפים שהיה לנו, ופשוט נשנה את שם הקובץ ממנו +page.server.js ל +page.js (אוֹ .ts אם פיגמת את הפרויקט שלך לשימוש ב-TypeScript). זה משנה את הטוען שלנו להיות מטעין "אוניברסלי" ולא מטעין שרתים. המסמכים של SvelteKit להסביר את ההבדל, אבל טוען אוניברסלי פועל גם על השרת וגם על הלקוח. יתרון אחד עבורנו הוא שה fetch קריאה לתוך נקודת הקצה החדשה שלנו תפעל ישירות מהדפדפן שלנו (לאחר הטעינה הראשונית), באמצעות המקור של הדפדפן fetch פוּנקצִיָה. נוסיף מעט מטמון HTTP רגיל, אבל לעת עתה, כל מה שנעשה הוא לקרוא לנקודת הקצה.
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, };
}עכשיו בואו נוסיף טופס פשוט לנו /list דף:
<div class="search-form"> <form action="/iw/list"> <label>Search</label> <input autofocus name="search" /> </form>
</div>כן, טפסים יכולים למקד ישירות למטעני הדפים הרגילים שלנו. כעת נוכל להוסיף מונח חיפוש בתיבת החיפוש, לחץ זן, ומונח "חיפוש" יצורף למחרוזת השאילתה של כתובת האתר, אשר יפעיל מחדש את הטוען שלנו ויחפש בפריטי המטלות שלנו.
בואו גם נגביר את העיכוב אצלנו todoData.js קובץ ב /lib/data. זה יקל לראות מתי הנתונים נמצאים ואינם מאוחסנים במטמון בזמן שאנו עובדים על הפוסט הזה.
export const wait = async amount => new Promise(res => setTimeout(res, amount ?? 500));זכור, הקוד המלא לפוסט זה הוא הכל ב-GitHub, אם אתה צריך להתייחס אליו.
מטמון בסיסי
בואו נתחיל על ידי הוספת מטמון לקובץ שלנו /api/todos נקודת קצה. נחזור לשלנו +server.js קובץ והוסף את כותרת בקרת המטמון הראשונה שלנו.
setHeaders({ "cache-control": "max-age=60",
});... מה שישאיר את כל הפונקציה להיראות כך:
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);
}נסתכל על אי תוקף ידני בקרוב, אבל כל מה שהפונקציה הזו אומרת הוא לשמור את קריאות ה-API הללו ל-60 שניות. הגדר את זה למה שאתה רוצה, ובהתאם למקרה השימוש שלך, stale-while-revalidate אולי שווה גם לבדוק.
ובדיוק ככה, השאילתות שלנו נשמרות במטמון.
הערות תהיה בטוח ש לבטל את הסימון תיבת הסימון המשביתה שמירה במטמון בכלי הפיתוח.
זכור, אם הניווט הראשוני שלך באפליקציה הוא דף הרשימה, תוצאות החיפוש הללו יישמרו במטמון פנימי ל-SvelteKit, אז אל תצפה לראות שום דבר ב-DevTools כשאתה חוזר לחיפוש זה.
מה שמור, ואיפה
הטעינה הראשונה שלנו, המעובדת בשרת, של האפליקציה שלנו (בהנחה שנתחיל ב- /list עמוד) יובא בשרת. SvelteKit תבצע סדרה ותשלח את הנתונים האלה ללקוח שלנו. מה שכן, הוא יתבונן ב Cache-Control כותרת על התגובה, וידע להשתמש בנתונים המאוחסנים במטמון עבור אותה קריאת נקודת קצה בתוך חלון המטמון (שאותו הגדרנו ל-60 שניות בדוגמה ל-put).
לאחר הטעינה הראשונית הזו, כשאתה מתחיל לחפש בדף, אתה אמור לראות בקשות רשת מהדפדפן שלך ל- /api/todos רשימה. בזמן שאתה מחפש דברים שכבר חיפשת (בתוך 60 השניות האחרונות), התגובות צריכות להיטען מיד מכיוון שהן מאוחסנות במטמון.
מה שמגניב במיוחד בגישה הזו הוא שמכיוון שמדובר באחסון במטמון דרך ה-Caching המקורי של הדפדפן, השיחות האלה יכולות (בהתאם לאופן שבו אתה מנהל את שיבוץ המטמון שנבחן) להמשיך לשמור במטמון גם אם אתה טוען מחדש את הדף (בניגוד ל- עומס ראשוני בצד השרת, שתמיד קורא לנקודת הקצה טרייה, גם אם היא עשתה זאת ב-60 השניות האחרונות).
ברור שהנתונים יכולים להשתנות בכל עת, אז אנחנו צריכים דרך לטהר את המטמון הזה באופן ידני, עליה נסתכל בהמשך.
פסילת קובץ שמור
נכון לעכשיו, הנתונים יישמרו במטמון למשך 60 שניות. לא משנה מה, לאחר דקה, נתונים טריים יימשכו מחנות הנתונים שלנו. אולי תרצה פרק זמן קצר יותר או ארוך יותר, אבל מה קורה אם אתה משנה נתונים מסוימים ורוצה לנקות את המטמון שלך באופן מיידי כדי שהשאילתה הבאה שלך תהיה מעודכנת? נפתור זאת על ידי הוספת ערך ביטול שאילתות לכתובת האתר שאנו שולחים לחדש שלנו /todos נקודת סיום.
בוא נאחסן את ערך ביטול המטמון הזה בקובץ cookie. ניתן להגדיר ערך זה בשרת אך עדיין לקרוא בלקוח. בואו נסתכל על קוד לדוגמה.
אנחנו יכולים ליצור א +layout.server.js קובץ בשורש שלנו routes תיקייה. זה יפעל עם הפעלת האפליקציה, והוא מקום מושלם להגדיר ערך קובץ Cookie ראשוני.
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, };
}אולי שמת לב ל isDataRequest ערך. זכור, פריסות יופעלו מחדש בכל עת קריאות קוד לקוח invalidate(), או בכל פעם שאנו מפעילים פעולת שרת (בהנחה שלא נשבית את התנהגות ברירת המחדל). isDataRequest מציין את ההרצות החוזרות הללו, ולכן אנו מגדירים את קובץ ה-cookie רק אם כן false; אחרת, אנחנו שולחים את מה שכבר יש.
אל האני httpOnly: false הדגל הוא גם משמעותי. זה מאפשר לקוד הלקוח שלנו לקרוא את ערכי העוגיות הללו document.cookie. בדרך כלל זה יהיה חשש אבטחה, אבל במקרה שלנו אלו מספרים חסרי משמעות שמאפשרים לנו לשמור במטמון או לשבץ את המטמון.
קריאת ערכי מטמון
המעמיס האוניברסלי שלנו הוא מה שקורא לנו /todos נקודת קצה. זה פועל בשרת או בלקוח, ואנחנו צריכים לקרוא את ערך המטמון הזה שהגדרנו זה עתה, לא משנה היכן אנחנו נמצאים. זה קל יחסית אם אנחנו בשרת: אנחנו יכולים להתקשר await parent() כדי לקבל את הנתונים מפריסות אב. אבל בלקוח, נצטרך להשתמש בקוד גס כדי לנתח 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] ?? "";
};למרבה המזל, אנחנו צריכים את זה רק פעם אחת.
שולח את ערך המטמון
אבל עכשיו אנחנו צריכים לשלוח הערך הזה שלנו /todos נקודת סיום.
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') יש בו בדיקה כדי לראות אם אנחנו בלקוח (על ידי בדיקת סוג המסמך), ולא מחזיר כלום אם אנחנו, ובשלב זה אנחנו יודעים שאנחנו בשרת. לאחר מכן הוא משתמש בערך מהפריסה שלנו.
לשבור את המטמון
אבל אֵיך האם אנחנו באמת מעדכנים את ערך ביטול המטמון הזה כשצריך? מכיוון שהוא מאוחסן בעוגייה, אנו יכולים לקרוא לזה כך מכל פעולת שרת:
cookies.set("todos-cache", cacheValue, { path: "/", httpOnly: false });היישום
מכאן הכל בירידה; עשינו את העבודה הקשה. כיסינו את הפרימיטיבים השונים של פלטפורמת האינטרנט שאנו צריכים, כמו גם לאן הם הולכים. עכשיו בואו נהנה ונכתוב קוד אפליקציה כדי לקשר את הכל ביחד.
מסיבות שיתבררו עוד מעט, נתחיל בהוספת פונקציונליות עריכה ל- /list עמוד. נוסיף את שורת הטבלה השנייה לכל מטלה:
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>וכמובן, נצטרך להוסיף פעולת טופס עבורנו /list עמוד. פעולות יכולות להיכנס רק .server דפים, אז נוסיף א +page.server.js בשלנו /list תיקייה. (כן ה +page.server.js קובץ יכול להתקיים לצד א +page.js קוֹבֶץ.)
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 }); },
};אנחנו תופסים את נתוני הטופס, מאלצים עיכוב, מעדכנים את המשימה שלנו, ואז, והכי חשוב, מנקים את קובץ ה-cache של קובץ ה-cache.
בואו ננסה את זה. טען מחדש את הדף שלך ואז ערוך את אחד מפריטי המטלות. אתה אמור לראות את עדכון ערך הטבלה לאחר רגע. אם תסתכל בכרטיסייה רשת ב-DevToold, תראה אחזור ל- /todos נקודת קצה, שמחזירה את הנתונים החדשים שלך. פשוט, ועובד כברירת מחדל.
עדכונים מיידיים
מה אם נרצה להימנע מהאחזור הזה שמתרחש לאחר שאנו מעדכנים את פריט המטלות שלנו, ובמקום זאת, לעדכן את הפריט ששונה ישירות על המסך?
זה לא רק עניין של ביצועים. אם תחפש "פוסט" ולאחר מכן תסיר את המילה "פוסט" מכל אחד מפריטי המטלות ברשימה, הם ייעלמו מהרשימה לאחר העריכה מכיוון שהם אינם נמצאים עוד בתוצאות החיפוש של אותו דף. אתה יכול לשפר את ה-UX עם קצת אנימציה בטוב טעם עבור המטלה המרגשת, אבל נניח שרצינו לֹא הפעל מחדש את פונקציית הטעינה של הדף הזה אך עדיין נקה את המטמון ועדכן את המטלה ששונתה כדי שהמשתמש יוכל לראות את העריכה. SvelteKit מאפשר זאת - בואו נראה איך!
ראשית, בואו נעשה שינוי קטן אחד במטען שלנו. במקום להחזיר את חפצי המטלות שלנו, בואו נחזיר א חנות לכתיבה המכיל את המטלות שלנו.
return { todos: writable(todos),
};לפני כן, ניגשנו למשימות שלנו ב- data prop, שאיננו בבעלותנו ואינו יכולים לעדכן. אבל Svelte מאפשר לנו להחזיר את הנתונים שלנו בחנות משלהם (בהנחה שאנחנו משתמשים בטוען אוניברסלי, מה שכן). אנחנו רק צריכים לעשות עוד תיקון אחד לשלנו /list עמוד.
במקום זה:
{#each todos as t}...אנחנו צריכים לעשות את זה מאז todos היא עצמה כעת חנות.:
{#each $todos as t}כעת הנתונים שלנו נטענים כמו קודם. אך מאז todos היא חנות לכתיבה, אנחנו יכולים לעדכן אותה.
ראשית, בואו נספק פונקציה שלנו use:enhance תְכוּנָה:
<form use:enhance={executeSave} on:submit={runInvalidate} method="post" action="?/editTodo"
>זה יפעל לפני הגשה. בוא נכתוב את זה בהמשך:
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; } }) ); };
}פונקציה זו מספקת א data אובייקט עם נתוני הטופס שלנו. אָנוּ לַחֲזוֹר פונקציית אסינכרון שתפעל לאחר העריכה שלנו הסתיימה. המסמכים הסבירו את כל זה, אבל על ידי כך, אנו מכבים את הטיפול בטפסים המוגדר כברירת מחדל של SvelteKit שהיה מפעיל מחדש את הטוען שלנו. זה בדיוק מה שאנחנו רוצים! (נוכל בקלות להחזיר את התנהגות ברירת המחדל הזו, כפי שמסבירים המסמכים.)
עכשיו אנחנו מתקשרים update עלינו todos מערך מכיוון שמדובר בחנות. וזה זה. לאחר עריכת פריט מטלה, השינויים שלנו מופיעים מיד והמטמון שלנו נמחק (כמו קודם, מכיוון שהגדרנו ערך קובץ Cookie חדש ב- editTodo טופס פעולה). לכן, אם נחפש ולאחר מכן נווט חזרה לדף זה, נקבל נתונים עדכניים מהמטען שלנו, אשר לא יכלול בצורה נכונה את כל פריטי המטלות המעודכנים שעודכנו.
הקוד לעדכונים המיידיים זמין ב-GitHub.
לחפור עמוק יותר
אנו יכולים להגדיר עוגיות בכל פונקציית טעינת שרת (או פעולת שרת), לא רק בפריסת השורש. לכן, אם משתמשים בנתונים מסוימים רק מתחת לפריסה בודדת, או אפילו לדף בודד, תוכל להגדיר שם את ערך ה-cookie הזה. יתר על כן, אם אתה לֹא עושה את הטריק הרגע הראיתי עדכון ידני של נתונים על המסך, ובמקום זאת רוצה שהמטען שלך יפעל מחדש לאחר מוטציה, אז אתה תמיד יכול להגדיר ערך קובץ Cookie חדש ישירות בפונקציית הטעינה הזו ללא שום בדיקה נגד isDataRequest. זה יוגדר בהתחלה, ואז בכל פעם שתפעיל פעולת שרת, פריסת העמוד תבטל אוטומטית ותתקשר מחדש למטעין שלך, ותגדיר מחדש את מחרוזת הפסקת המטמון לפני הקריאה לטוען האוניברסלי שלך.
כתיבת פונקציית טעינה מחדש
בואו נסיים בבניית תכונה אחרונה: כפתור טעינה מחדש. בואו ניתן למשתמשים כפתור שינקה את המטמון ולאחר מכן נטען מחדש את השאילתה הנוכחית.
נוסיף פעולת טופס פשוט עפר:
async reloadTodos({ cookies }) { cookies.set('todos-cache', +new Date(), { path: '/', httpOnly: false });
},בפרויקט אמיתי סביר להניח שלא הייתם מעתיקים/מדביקים את אותו קוד כדי להגדיר את אותה קובץ Cookie באותו אופן במספר מקומות, אבל עבור הפוסט הזה נבצע אופטימיזציה לפשטות וקריאות.
עכשיו בואו ניצור טופס לפרסם בו:
<form method="POST" action="?/reloadTodos" use:enhance> <button>Reload todos</button>
</form>זה עובד!
אנחנו יכולים לקרוא לזה בוצע ולהמשיך הלאה, אבל בואו נשפר קצת את הפתרון הזה. באופן ספציפי, בואו נספק משוב על הדף כדי לספר למשתמש שהטעינה מחדש מתרחשת. כמו כן, כברירת מחדל, פעולות SvelteKit פוסלות הכל. כל פריסה, עמוד וכו' בהיררכיה של העמוד הנוכחי ייטען מחדש. ייתכן שיש נתונים שנטענו פעם אחת בפריסת השורש שאיננו צריכים לבטל או לטעון מחדש.
אז בואו נתמקד קצת בדברים ונטען מחדש את המטלות שלנו רק כשאנחנו קוראים לפונקציה הזו.
ראשית, נעביר פונקציה לשיפור:
<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; }); };
};אנחנו מגדירים חדש reloading משתנה ל true ב התחלה של פעולה זו. ואז, כדי לעקוף את התנהגות ברירת המחדל של ביטול הכל, אנו מחזירים an async פוּנקצִיָה. פונקציה זו תפעל כאשר פעולת השרת שלנו תסתיים (אשר רק מגדירה קובץ Cookie חדש).
בלי זה async הפונקציה הוחזרה, SvelteKit תבטל הכל. מכיוון שאנו מספקים את הפונקציה הזו, היא לא תבטל דבר, אז זה תלוי בנו להגיד לה מה לטעון מחדש. אנחנו עושים את זה עם invalidate פוּנקצִיָה. אנחנו קוראים לזה בערך של reload:todos. פונקציה זו מחזירה הבטחה, אשר נפתרת כאשר ביטול התוקף הושלם, באיזו נקודה אנו קובעים reloading חזרה false.
לבסוף, עלינו לסנכרן את המטען שלנו עם החדש הזה reload:todos ערך ביטול. אנחנו עושים את זה במטען שלנו עם depends פוּנקצִיָה:
export async function load({ fetch, url, setHeaders, depends }) { depends('reload:todos'); // rest is the sameוזה זה. depends ו invalidate הן פונקציות שימושיות להפליא. מה שמגניב זה invalidate לא לוקח רק ערכים שרירותיים שאנו מספקים כמו שעשינו. אנו יכולים גם לספק כתובת URL, ש-SvelteKit תעקוב אחריה, ולבטל את התוקף של כל הטעינים התלויים בכתובת האתר הזו. לשם כך, אם אתה תוהה אם נוכל לדלג על השיחה אל depends ולבטל שלנו /api/todos נקודת קצה לגמרי, אתה יכול, אבל אתה צריך לספק את מְדוּיָק כתובת האתר, כולל ה- search מונח (וערך המטמון שלנו). אז, אתה יכול להרכיב את כתובת האתר עבור החיפוש הנוכחי, או להתאים לשם הנתיב, כך:
invalidate(url => url.pathname == "/api/todos");באופן אישי, אני מוצא את הפתרון שמשתמש depends יותר ברור ופשוט. אבל תראה המסמכים למידע נוסף, כמובן, ולהחליט בעצמך.
אם תרצה לראות את כפתור הטעינה מחדש בפעולה, הקוד שלו נמצא הסניף הזה של הריפו.
מחשבות נפרדות
זה היה פוסט ארוך, אבל אני מקווה שלא מהמם. התעמקנו בדרכים שונות שבהן אנו יכולים לשמור נתונים במטמון בעת שימוש ב-SvelteKit. הרבה מזה היה רק עניין של שימוש בפרימיטיבים של פלטפורמת אינטרנט כדי להוסיף את המטמון הנכון, וערכי קובצי Cookie, שהידע עליהם ישרת אותך בפיתוח אתרים באופן כללי, מעבר ל-SvelteKit בלבד.
יתר על כן, זה משהו שאתה בהחלט לא צריך כל הזמן. ניתן לטעון, אתה צריך להגיע לסוג התכונות המתקדמות האלה רק כשאתה באמת צריך אותם. אם מאגר הנתונים שלך מגיש נתונים במהירות וביעילות, ואתה לא מתמודד עם שום סוג של בעיות קנה מידה, אין טעם לנפח את קוד היישום שלך במורכבות מיותרת לעשות את הדברים עליהם דיברנו כאן.
כמו תמיד, כתוב קוד ברור, נקי ופשוט, ובצע אופטימיזציה בעת הצורך. מטרת הפוסט הזה הייתה לספק לך את כלי האופטימיזציה האלה מתי שאתה באמת צריך אותם. מקווה שנהנית מזה!
- הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
- Platoblockchain. Web3 Metaverse Intelligence. ידע מוגבר. גישה כאן.
- מקור: https://css-tricks.com/caching-data-in-sveltekit/