My پست قبلی یک مرور کلی از SvelteKit بود که در آن دیدیم که چه ابزار عالی برای توسعه وب است. این پست کارهایی را که ما در آنجا انجام دادیم منعکس می کند و به موضوع مورد علاقه هر توسعه دهنده می پردازد: ذخیره. بنابراین، اگر قبلاً این مطلب را نخوانده اید، حتماً آخرین پست من را بخوانید. کد این پست در GitHub موجود است، و همچنین نسخه ی نمایشی زنده.
این پست همه چیز در مورد مدیریت داده است. ما برخی از قابلیت‌های جستجوی ابتدایی را اضافه می‌کنیم که رشته جستجوی صفحه را تغییر می‌دهد (با استفاده از ویژگی‌های SvelteKit داخلی)، و بارگیری صفحه را دوباره فعال می‌کند. اما، به جای جستجوی مجدد پایگاه داده (تخیلی) خود، مقداری حافظه پنهان اضافه می کنیم تا جستجوهای قبلی (یا با استفاده از دکمه برگشت) داده های بازیابی شده قبلی را به سرعت از حافظه پنهان نشان دهد. ما به نحوه کنترل مدت زمان معتبر ماندن داده های حافظه پنهان و مهمتر از آن، نحوه باطل کردن دستی تمام مقادیر ذخیره شده در حافظه پنهان خواهیم پرداخت. به‌عنوان نماد روی کیک، به این خواهیم پرداخت که چگونه می‌توانیم به‌صورت دستی داده‌ها را در صفحه فعلی، سمت کلاینت، پس از یک جهش به‌روزرسانی کنیم، در حالی که هنوز حافظه پنهان را پاک می‌کنیم.
این پست طولانی تر و دشوارتر از بسیاری از مطالبی است که من معمولاً می نویسم زیرا ما موضوعات سخت تری را پوشش می دهیم. این پست اساساً به شما نشان می دهد که چگونه می توانید ویژگی های مشترک ابزارهای داده محبوب مانند را پیاده سازی کنید واکنش پرس و جو; اما به جای کشیدن یک کتابخانه خارجی، ما فقط از پلتفرم وب و ویژگی های SvelteKit استفاده خواهیم کرد.
متأسفانه، ویژگی‌های پلتفرم وب کمی سطح پایین‌تر است، بنابراین ما کمی بیشتر از آنچه ممکن است به آن عادت داشته باشید، کار خواهیم کرد. نکته مثبت این است که ما به هیچ کتابخانه خارجی نیاز نخواهیم داشت، که کمک می‌کند اندازه بسته‌ها خوب و کوچک باشد. لطفاً از رویکردهایی که به شما نشان خواهم داد استفاده نکنید، مگر اینکه دلیل خوبی برای آن داشته باشید. ذخیره سازی به راحتی اشتباه می شود، و همانطور که خواهید دید، کمی پیچیدگی وجود دارد که منجر به کد برنامه شما می شود. امیدواریم ذخیره اطلاعات شما سریع باشد، و رابط کاربری شما خوب است و به SvelteKit اجازه می دهد فقط همیشه داده های مورد نیاز خود را برای هر صفحه خاص درخواست کند. اگر هست، آن را به حال خود رها کنید. از سادگی لذت ببرید اما این پست ترفندهایی را به شما نشان می دهد که زمانی که دیگر چنین نیست.
صحبت از واکنش پرس و جو، آن است تازه آزاد شد برای Svelte! بنابراین اگر متوجه شدید که به تکنیک‌های کش دستی متکی هستید زیاد، حتماً آن پروژه را بررسی کنید و ببینید ممکن است کمک کند یا خیر.
راه اندازی
قبل از شروع، اجازه دهید چند تغییر کوچک در آن ایجاد کنیم کدی که قبلا داشتیم. این بهانه ای برای دیدن سایر ویژگی های SvelteKit به ما می دهد و مهمتر از آن، ما را برای موفقیت آماده می کند.
ابتدا، اجازه دهید بارگذاری داده های خود را از لودر خود به داخل منتقل کنیم +page.server.js به یک مسیر API. ما یک را ایجاد خواهیم کرد +server.js فایل در routes/api/todosو سپس a اضافه کنید 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="/fa/list"> <label>Search</label> <input autofocus name="search" /> </form>
</div>بله، فرم ها می توانند مستقیماً به لودرهای صفحه معمولی ما هدف قرار دهند. اکنون می توانیم یک عبارت جستجو را در کادر جستجو اضافه کنیم، ضربه بزنید وارد، و یک عبارت "جستجو" به رشته جستجوی URL اضافه می شود، که بارگذار ما را مجددا اجرا می کند و موارد کارهای ما را جستجو می کند.
بیایید تاخیر در خود را نیز افزایش دهیم 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 هدر بر روی پاسخ، و می‌داند که از این داده‌های کش برای آن فراخوانی نقطه پایانی در پنجره کش (که در مثالی ۶۰ ثانیه تنظیم کردیم) استفاده کند.
پس از بارگیری اولیه، وقتی شروع به جستجو در صفحه می کنید، باید درخواست های شبکه را از مرورگر خود به صفحه مشاهده کنید /api/todos فهرست همانطور که چیزهایی را که قبلاً جستجو کرده اید (در 60 ثانیه گذشته) جستجو می کنید، پاسخ ها باید بلافاصله از آنجایی که در حافظه پنهان هستند بارگیری شوند.
نکته جالب این رویکرد این است که، از آنجایی که این کار از طریق کش بومی مرورگر ذخیره می‌شود، این تماس‌ها می‌توانند (بسته به نحوه مدیریت مخرب حافظه پنهان) حتی اگر صفحه را دوباره بارگیری کنید (برخلاف بارگذاری اولیه سمت سرور، که همیشه نقطه پایانی را تازه می‌خواند، حتی اگر آن را در 60 ثانیه گذشته انجام داده باشد.
بدیهی است که داده ها می توانند در هر زمان تغییر کنند، بنابراین ما به راهی برای پاکسازی این کش به صورت دستی نیاز داریم که در ادامه به بررسی آن خواهیم پرداخت.
عدم اعتبار کش
در حال حاضر، داده ها به مدت 60 ثانیه در حافظه پنهان ذخیره می شوند. مهم نیست که چه اتفاقی می افتد، پس از یک دقیقه، داده های تازه از دیتا استور ما برداشته می شود. ممکن است بخواهید دوره زمانی کوتاه‌تر یا طولانی‌تری داشته باشید، اما اگر برخی از داده‌ها را تغییر دهید و بخواهید بلافاصله حافظه پنهان خود را پاک کنید تا درخواست بعدی شما به‌روز شود، چه اتفاقی می‌افتد؟ ما این مشکل را با افزودن یک مقدار پرس و جو به URL که به آدرس جدید خود ارسال می کنیم، حل خواهیم کرد /todos نقطه پایانی
بیایید این مقدار busting cache را در یک کوکی ذخیره کنیم. این مقدار را می توان در سرور تنظیم کرد، اما همچنان در مشتری خوانده می شود. بیایید به چند نمونه کد نگاه کنیم.
ما می توانیم یک ایجاد کنیم +layout.server.js فایل در ریشه ما routes پوشه این در هنگام راه اندازی برنامه اجرا می شود و مکان مناسبی برای تنظیم مقدار اولیه کوکی است.
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 نشان‌دهنده اجرای مجدد آن است، و بنابراین ما فقط در صورت وجود کوکی را تنظیم می‌کنیم false; در غیر این صورت، ما آنچه را که از قبل وجود دارد ارسال می کنیم.
La httpOnly: false پرچم نیز قابل توجه است. این به کد مشتری ما اجازه می‌دهد تا این مقادیر کوکی را بخواند document.cookie. این معمولاً یک نگرانی امنیتی است، اما در مورد ما این اعداد بی معنی هستند که به ما امکان می‌دهند حافظه پنهان یا bust کنیم.
خواندن مقادیر حافظه پنهان
لودر جهانی ما چیزی است که ما را صدا می کند /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') یک بررسی در آن دارد تا ببیند آیا ما روی کلاینت هستیم (با بررسی نوع سند)، و اگر هستیم چیزی را برمی‌گرداند، در این مرحله می‌دانیم که در سرور هستیم. سپس از مقدار طرح ما استفاده می کند.
خراب کردن کش
اما چگونه آیا ما واقعاً آن مقدار busting حافظه پنهان را زمانی که نیاز داریم به روز می کنیم؟ از آنجایی که در یک کوکی ذخیره می‌شود، می‌توانیم آن را از هر عملکرد سرور به این شکل صدا کنیم:
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 bust خود را پاک می‌کنیم.
اجازه دهید به این ضربه بزنید. صفحه خود را دوباره بارگیری کنید، سپس یکی از موارد کاری را ویرایش کنید. بعد از یک لحظه باید مقدار جدول را به روز کنید. اگر به تب Network در DevToold نگاه کنید، واکشی به آن را خواهید دید /todos نقطه پایانی، که داده های جدید شما را برمی گرداند. ساده است و به طور پیش فرض کار می کند.
به روزرسانی های فوری
اگر بخواهیم از آن واکشی که پس از به‌روزرسانی مورد ما رخ می‌دهد اجتناب کنیم و در عوض، مورد اصلاح‌شده را مستقیماً روی صفحه به‌روزرسانی کنیم؟
این فقط مربوط به عملکرد نیست. اگر "پست" را جستجو کنید و سپس کلمه "پست" را از هر یک از موارد کارهای موجود در لیست حذف کنید، پس از ویرایش از لیست ناپدید می شوند زیرا دیگر در نتایج جستجوی آن صفحه نیستند. شما می توانید UX را با چند انیمیشن خوش سلیقه برای کارهای خروجی بهتر کنید، اما فرض کنید می خواستیم نه عملکرد بارگذاری آن صفحه را مجدداً اجرا کنید اما همچنان کش را پاک کنید و کارهای اصلاح شده را به روز کنید تا کاربر بتواند ویرایش را ببیند. SvelteKit این امکان را فراهم می کند - بیایید ببینیم چگونه!
ابتدا اجازه دهید یک تغییر کوچک در لودر خود ایجاد کنیم. به جای برگرداندن موارد کاری که باید انجام دهیم، a را برگردانیم فروشگاه قابل نوشتن شامل کارهای ما است.
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 آرایه چون فروشگاه است. همینه که هست. پس از ویرایش یک مورد، تغییرات ما بلافاصله نشان داده می شود و حافظه پنهان ما پاک می شود (مانند قبل، زیرا مقدار کوکی جدیدی را در خود تنظیم کرده ایم. editTodo عمل فرم). بنابراین، اگر جستجو کنیم و سپس به این صفحه برگردیم، داده‌های تازه‌ای را از لودر خود دریافت می‌کنیم، که به درستی موارد به‌روزرسانی شده‌ای را که به‌روزرسانی شده‌اند حذف می‌کند.
کد برای به روز رسانی فوری در GitHub موجود است.
حفاری های عمیق تر
ما می‌توانیم کوکی‌ها را در هر عملکرد بارگذاری سرور (یا عملکرد سرور) تنظیم کنیم، نه فقط در طرح‌بندی ریشه. بنابراین، اگر برخی از داده‌ها فقط در زیر یک طرح‌بندی، یا حتی یک صفحه استفاده می‌شوند، می‌توانید آن مقدار کوکی را در آنجا تنظیم کنید. علاوه بر این، اگر شما هستید نه با انجام ترفندی که من به‌روزرسانی دستی داده‌های روی صفحه نمایش را نشان دادم، و در عوض می‌خواهم بارگذار شما پس از یک جهش مجدداً اجرا شود، در آن صورت همیشه می‌توانید یک مقدار کوکی جدید را درست در آن تابع بارگذاری بدون هیچ بررسیی تنظیم کنید. isDataRequest. در ابتدا تنظیم می‌شود، و سپس هر زمان که یک عملکرد سرور را اجرا می‌کنید، طرح‌بندی صفحه به‌طور خودکار باطل می‌شود و بارگذار شما را دوباره فراخوانی می‌کند، و قبل از فراخوانی بارکننده جهانی، رشته حافظه پنهان را دوباره تنظیم می‌کند.
نوشتن تابع بارگذاری مجدد
بیایید با ساخت آخرین ویژگی به پایان برسانیم: دکمه بارگذاری مجدد. اجازه دهید به کاربران دکمه ای بدهیم که کش را پاک می کند و سپس پرس و جو فعلی را دوباره بارگیری می کند.
ما یک عمل فرم ساده خاک را اضافه می کنیم:
async reloadTodos({ cookies }) { cookies.set('todos-cache', +new Date(), { path: '/', httpOnly: false });
},در یک پروژه واقعی احتمالاً یک کد را کپی/پیست نمی‌کنید تا کوکی یکسان را در مکان‌های مختلف تنظیم کنید، اما برای این پست ما برای سادگی و خوانایی بهینه‌سازی می‌کنیم.
حالا بیایید یک فرم برای ارسال به آن ایجاد کنیم:
<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 تابع. این تابع زمانی اجرا می شود که عملکرد سرور ما به پایان برسد (که فقط یک کوکی جدید تنظیم می کند).
بدون این 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 آن را ردیابی می‌کند و هر بارکننده‌ای که به آن URL وابسته است را باطل می‌کند. برای این منظور، اگر نمی‌پرسید آیا می‌توانیم از تماس با ما صرفنظر کنیم depends و ما را باطل کند /api/todos به طور کلی، شما می توانید، اما شما باید آن را ارائه دهید دقیق URL، از جمله search اصطلاح (و مقدار کش ما). بنابراین، می‌توانید URL را برای جستجوی فعلی کنار هم قرار دهید، یا با نام مسیر مطابقت دهید، مانند این:
invalidate(url => url.pathname == "/api/todos");من شخصاً راه حلی را پیدا می کنم که از آن استفاده می کند depends واضح تر و ساده تر اما ببینید اسناد البته برای اطلاعات بیشتر و خودتان تصمیم بگیرید.
اگر می‌خواهید دکمه بارگذاری مجدد را در عمل ببینید، کد آن در داخل است این شعبه از مخزن.
افکار پراکنده
این یک پست طولانی بود، اما امیدوارم زیاد نباشد. ما در هنگام استفاده از SvelteKit به روش‌های مختلف می‌توانیم داده‌ها را ذخیره کنیم. بخش اعظم این کار فقط مربوط به استفاده از نرم افزارهای ابتدایی پلتفرم وب برای افزودن حافظه پنهان و مقادیر کوکی صحیح است که دانش آنها در توسعه وب به طور کلی، فراتر از SvelteKit، به شما کمک خواهد کرد.
علاوه بر این، این چیزی است که شما کاملا همیشه نیاز ندارند. مسلماً، شما فقط زمانی باید به این نوع ویژگی های پیشرفته دست پیدا کنید در واقع به آنها نیاز دارند. اگر دیتا استور شما داده‌ها را به سرعت و کارآمد ارائه می‌کند، و با هیچ نوع مشکل مقیاس‌پذیری روبه‌رو نیستید، هیچ معنایی ندارد که با انجام کارهایی که در اینجا در مورد آن صحبت کردیم، کد برنامه خود را با پیچیدگی‌های بیهوده پر کنید.
مثل همیشه کدهای واضح، تمیز و ساده بنویسید و در صورت لزوم بهینه سازی کنید. هدف از این پست ارائه ابزارهای بهینه سازی برای زمانی که واقعاً به آنها نیاز دارید ارائه می کند. امیدوارم ازش لذت برده باشی!
- محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
- پلاتوبلاک چین. Web3 Metaverse Intelligence. دانش تقویت شده دسترسی به اینجا.
- منبع: https://css-tricks.com/caching-data-in-sveltekit/