خيارات التخزين المؤقّت (Caching Options)

الدرس 31 من 34 · دورة TanStack Router الكاملة · 6 دقيقة و36 ثانية

الفيديو الأصلي باللغة الإنجليزية. إذا تعذّر تشغيله هنا، شاهده على موقع المؤلف. التفريغ النصي العربي الكامل أدناه.

مستودع الكود لهذا الدرس

الفرع: caching-2

[00:00] ولكن الآن، وبعد أن أصبح لَدَينا هذا المثال، فلنرَ الآن أيَّ خياراتٍ نستطيع تغييرها في سلوك التخزين المؤقّت الافتراضي هذا الذي نحصل عليه مع TanStack Router. فسنجرّب هذه الخيارات في هذا المسار، غير أنّ أيَّ خيارٍ سنعمله هنا

[00:15] يمكن أن يُحدَّد عالميًّا كذلك عندما نعرّف الموجّه (router) لدينا في ملف main.tsx.

[00:22] فلنفتح علامة التبويب للشبكة (Network) هنا.

[00:23] سنحتاج إلى هذا كثيرًا. وأولًا، فلنجرب شيئًا أظنّ أنّنا ذكرناه في القسم السابق، وهو التحميل المسبق (preloading) والتخزين المؤقّت. فكما نعرف الآن، عندما نمرّر المؤشّر فوق مسار

[00:38] فستُجلب بيانات هذا المسار كما ترى، لكن عندما نمرّر المؤشّر من جديد فلن يحدث ذلك مرةً أخرى حتى يمرّ بعض الوقت، وافتراضيًا هذا الوقت 30 ثانية، ويمكننا تغييره بإضافةٍ هنا

[00:55] خيارٍ وهو preloadStaleTime.

[00:58] إذًا preloadStaleTime، فلنضبطه — مثلًا — على 5 ثوانٍ كي نجرّبه، ولنحرّك هذه المهلة أيضًا — ربّما — إلى بعد طلبنا حتّى نرى طلبنا في علامة التبويب للشبكة فورًا من دون

[01:14] أن ننتظر. فالآن فلنجرب مرةً أخرى: فلنجدّدها — ربّما. فلنمسح كلَّ شيء، ولنمرّر المؤشّر فوق مسار random word لدينا. فسنحصل على أشيائنا هنا. وإذا انتظرنا 5 ثوانٍ مرةً أخرى، فسينبغي أن نحصل على

[01:31] طلبنا مرةً أخرى هنا. وإذا انتظرنا 5 ثوانٍ أخرى فسينبغي أن نحصل عليه من جديد. أظنّ — في الواقع، عذرًا، عذرًا على هذا؛ فالمهلة الّتي كنّا نحصل عليها عند تمرير المؤشّر هي من الخيار الذي — أظنّ — ضبطناه هنا، وهو

[01:46] defaultPreloadDelay. إذًا فلنزِل هذا.

[01:50] فالآن إذا مرّرنا المؤشّر فسنحصل عليه.

[01:54] فإذا مرّرنا المؤشّر قبل مرور 5 ثوانٍ فلن ينبغي أن نحصل عليه، وبعد 5 ثوانٍ فسنحصل عليه، وهكذا دواليك؛ أفهمتَ الفكرة، فهذا شيءٌ يمكنك أن تتحكّم فيه. وهناك خيارٌ آخر يمكننا التحكّم فيه وهو staleTime. فإذًا هذه

[02:10] preloadStaleTime، وهو يخصّ بياناتنا المحمّلة مسبقًا (pre-loaded)، لكنّنا نملك أيضًا staleTime، وهو يعني عددَ الميلّي ثوانٍ التي تُعَدّ فيها طازجةً بِياناتُ المسار عند محاولة التحميل. فلنذهب مثلًا إلى مسار random word

[02:23] الذي لَدَينا هنا، ولدينا كلمة هنا بالإنجليزية. إذا انتقلنا إلى الإسبانية فسنحصل على شيءٍ ما. وعندما نرجع إلى الإنجليزية فسينبغي أن نحصل على الكلمة السابقة التي سبق خزنها، ثم ستُولَّد

[02:37] كلمة جديدة في الخلفية، صحيح؟ إذًا افتراضيًا سيكُون قيمة staleTime صفرًا، أي أنّ بيانات المسار تُعَدّ دائمًا غيرَ صالحة (stale)، وسيُعاد دائمًا تحميلها في الخلفية. فإذا زرنا هذا المسار أو

[02:53] انتقلنا إلى أيّ لغة، فسنحصل أوّلًا على كلمةٍ مخزَّنة (cached)، ثم سنحصل في الخلفية على كلمة جديدة، لأنّ بيانات الذاكرة المؤقّتة ستُعَدُّ دائمًا غيرَ صالحة.

[03:03] صحيح؟ وكي أوضّح هذا — لأني أشعر أنّني أربكتكم — فلنذهب إلى مسار about، ثم انتقلَ إلى random word. وكما ترى، نحصل على كلمةٍ عشوائية، صحيح؟ فلنرجعَ إلى about ثم إلى random word فسنحصل على

[03:17] الكلمة نفسها، ثم ستُحمَّل في الخلفية، لأنّ الكلمة المخزَّنة حاليًا ستُعَدُّ غيرَ صالحة. غير أنّه — وهذا لأنّ staleTime افتراضيًا صفر — فلنقل إنّنا نحتاج الكلمة المخزَّنة

[03:30] هذه كي لا تُعَدّ غيرَ صالحة، فلا نشغّل طلبًا آخر في الخلفية لمدّةٍ معيّنةٍ من الوقت.

[03:37] يمكننا التحكّم في ذلك عبر staleTime.

[03:39] فلنضبطه — ربّما — على 30 ثانية مثلًا. فالآن، في هذه الحالة، فلنجربها مرةً أخرى: فلنذهب إلى about، ثم إلى random word.

[03:51] سنحصل على كلمة مخزَّنة، وكما ترى — فلنجربها مرةً أخرى هنا — فسنحصل على هذه الكلمة المخزَّنة، ولن يُجدَّد شيءٌ في الخلفية بما أنّ staleTime لدينا أكبر. الآن، عندما

[04:03] تمرّ 30 ثانية، فستُعلَم هذه الكلمة الآن بأنّها غيرَ صالحة (stale)، وستُجدَّد في الخلفية عندما تُقدَّم من الذاكرة المؤقّتة. فأرجو أن يكون هذا قد صار واضحًا. وخيارٌ آخر نمتلكه هو gcTime أي وقتُ التجميع (garbage collection time)، و

[04:19] يمكن ضبطه كذلك على عددٍ من الميلّي ثوانٍ، وهو يعني مقدار الوقت الذي يُفترض أن تبقى فيه بِياناتُ المسار في الذاكرة المؤقّتة قبل أن تُجمع مهملَةً (garbage). وافتراضيًا هو 30 دقيقة، أي أنّه إن لم يُشغَل على أيِّ ما يكون من بيانات مسارٍ مخزَّنة

[04:32] خلال 30 دقيقة، فستُزال تمامًا من الذاكرة المؤقّتة. ويمكنك التحكّم في هذا كذلك؛ وهو افتراضيًا 30 ثانية.

[04:42] شيءٌ آخر أودّ ذكره هو استدعاء router.invalidate. فتذكّر في زرّ تسجيل الدخول (login) هذا — على سبيل المثال — الذي — أظنّ — كان في مسارنا الجذر — عند تسجيلنا للدخول. فهذا قادم من السياق (context) الذي

[04:57] نمرّره — أظنّ — أيضًا في main.tsx هنا. تذكّر أنّنا نستدعي router.invalidate؛ فاستدعاء router.invalidate سيجبرُ كلَّ مسارٍ فعّالٍ على إعادة تشغيل دوالّ التحميل لديه فورًا، و

[05:11] سيعلَم كلَّ مسارٍ مخزَّنٍ مؤقّتًا أنّه غير صالح (stale). فإذا نقرنا الآن على login فكما ترى حصلنا على كلمة جديدة هنا؛ لأنّ استدعاء router.invalidate سيجبرُ أيَّ دالة تحميلٍ فعّالة على إعادة التشغيل، وأيَّ ذاكرةٍ مؤقّتةٍ على أن تُعلَم بأنّها غيرَ صالحة. أما

[05:28] الشيء الأخير الذي أودّ ذكره بخصوص خيارات التخزين المؤقّت هذه: في المسار لديك، يمكنك أيضًا امتلاك دالة shouldReload هذه التي يمكنك تمريرها هنا كي تتحكّم في متى بالضبط يُعاد تشغيل دالة التحميل (loader function) لديك. فهذا يوفّر

[05:44] تحكّمًا إضافيًّا يتجاوز مجرّد تحديد staleTime: ففي هذه الدالة نرجع true أو false بحسب شيءٍ ما، وإذا رجعتَ true فسيُعاد تشغيل دالة التحميل، وستستقبِل هنا

[05:57] الأشياء نفسها التي تستقبِلها في دالة beforeLoad التي رأيناها من قبل.

[06:02] فهنا ستستقبِل سياقك (context)، وستستقبِل معامِلاتك، وستستقبِل تبعياتك (dependencies) وهكذا دواليك. وستستقبِل كذلك معلوماتٍ عن مسارك. وهي تقريبًا كلُّ ما

[06:14] ستُحتاج إليه كي — ربّما بناءً على شيءٍ هنا — أن تقرّر متى بالضبط يُعاد تشغيل دالة التحميل لديك.

[06:23] لكن هذا بالأساس ما أردت أن أذكره حول خيارات التخزين المؤقّت هذه. وبالطبع، إن أحببتَ أن تقرأ المزيد عن التخزين المؤقّت، فستجد في التوثيق (documentation) أقسامًا تتعلّق بالتخزين المؤقّت كي تُلقي

[06:35] نظرة. فلنرَ الآن كيف