المفاهيم الأساسية في SWR: قديم-مع-إعادة-التحقق

يرمز SWR إلى Stale-While-Revalidate، وهي استراتيجية للتخزين المؤقت في HTTP حدّدها RFC 5861. تتمثل الاستراتيجية في تقديم البيانات القديمة (المخزنة مؤقتًا) للمستخدم فورًا، ثم إعادة التحقق منها في الخلفية، وتحديث واجهة المستخدم عند وصول البيانات الحديثة.

يعطي هذا الأسلوب الأولوية للأداء المُدرَك؛ إذ يرى المستخدمون البيانات فورًا بدلًا من انتظار رحلة ذهاب وإياب عبر الشبكة.

في أنماط التحميل التقليدية، يرى المستخدمون مؤشر تحميل عند كل انتقال. أما مع SWR، فيرون آخر بيانات معروفة فورًا، وتُحدَّث واجهة المستخدم بصمت في الخلفية إذا تغيّرت البيانات.

يجعل ذلك التطبيقات تبدو أسرع بكثير، ويقلل الاضطراب الذهني الناتج عن حالات التحميل.

يعيد SWR التحقق من البيانات تلقائيًا عند: استعادة نافذة المتصفح تركيزها (عندما ينتقل المستخدم بين علامات التبويب ثم يعود)، أو استعادة اتصال الشبكة بعد انقطاعه، أو استدعاء mutate() صراحةً، أو انطلاق مؤقت refreshInterval القابل للتهيئة.

تحافظ هذه المشغلات التلقائية على حداثة البيانات دون أن يضطر المطوّر إلى إدارة منطق إعادة الجلب يدويًا.

يمكن أن يكون مفتاح SWR في إحدى حالات متعددة: loading (لا توجد بيانات مخزنة مؤقتًا، ويجري أول جلب)، أو revalidating (توجد بيانات مخزنة مؤقتًا، ويجري تحديث في الخلفية)، أو error (فشل الطلب)، أو success (تتوفر بيانات حديثة).

يساعدكم فهم هذه الحالات على بناء هياكل تحميل وواجهات أخطاء دقيقة.

يحتفظ SWR بذاكرة مؤقتة عامة داخل الذاكرة، تُفهرس باستخدام مفتاح الطلب (وهو عادةً سلسلة URL). ويحصل أي مكوّن يطلب المفتاح نفسه على القيمة المخزنة مؤقتًا نفسها، ويشارك في دورة إعادة التحقق نفسها.

ويعني إلغاء الازدواجية التلقائي هذا أن 10 مكونات يمكنها استدعاء useSWR بالمفتاح نفسه، مع إجراء طلب شبكة واحد فقط.

يفصل SWR منطق إدارة الذاكرة المؤقتة عن جلب البيانات الفعلي. وتقدمون دالة fetcher، وهي دالة غير متزامنة تقبل المفتاح وتعيد البيانات.

يمكن تبديل fetcher؛ فاستخدموا fetch أو axios أو graphql-request أو أي مصدر بيانات غير متزامن. ويتولى SWR التخزين المؤقت وإعادة التحقق بغض النظر عن طريقة عمل fetcher.

غلّفوا تطبيقكم داخل SWRConfig مع خاصية value التي تحتوي على دالة fetcher: value={{ fetcher: (url) => fetch(url).then(r => r.json()) }}. ويستخدم كل استدعاء لـ useSWR لا يحدد وسيط fetcher الإعداد الافتراضي العام هذا.

يؤدي ذلك إلى توحيد إعدادات API (مثل عنوان URL الأساسي وترويسات المصادقة) في مكان واحد، دون تكرارها في كل استدعاء لـ hook.

يستخدم النمط التقليدي useEffect + useState لإدارة حالات التحميل والبيانات والخطأ يدويًا. ويستبدل SWR كل ذلك باستدعاء hook واحد يتولى التخزين المؤقت وإلغاء الازدواجية والتحديث في الخلفية وإعادة محاولة الأخطاء تلقائيًا.

ويكون تقليل الشيفرة كبيرًا؛ إذ يتقلص مكوّن جلب البيانات المعتاد من أكثر من 20 سطرًا إلى 3 أسطر.

يحدد المفتاح الطلب تحديدًا فريدًا. استخدموا سلسلة URL في الحالات البسيطة. أما الطلبات التي تتضمن معاملات، فاستخدموا مفتاحًا على شكل مصفوفة: [url, params]، حيث يكون params كائنًا أو سلسلة مستقرة. ويؤدي null إلى تعطيل الطلب.

يضمن التصميم الجيد للمفتاح أن تشارك الطلبات المرتبطة إدخالات الذاكرة المؤقتة، وألا تتصادم الطلبات غير المرتبطة.

يتعامل SWR بذكاء مع إعادة التحقق؛ إذ يمنع dedupingInterval (وقيمته الافتراضية ثانيتان) إجراء عمليات إعادة تحقق متعددة في الوقت نفسه إذا تم تحميل العديد من المكونات دفعة واحدة. ولا يُرسل سوى طلب واحد لكل مفتاح خلال فترة إلغاء الازدواجية.

يمنع ذلك مشكلات تدفق الطلبات الهائل الشائعة في أشجار المكونات الكبيرة، حيث تجلب مكونات كثيرة البيانات نفسها.

طوّرت Vercel، الشركة التي تقف وراء Next.js، مكتبة SWR، ولذلك يكون التكامل سلسًا. ويمكن لـ getServerSideProps أو getStaticProps جلب البيانات مسبقًا، ثم يهيّئ SWR نفسه على العميل انطلاقًا من تلك القيمة التي جُلبت مسبقًا.

يوفر ذلك HTML أوليًا مُقدّمًا من الخادم، مع إعادة تحقق تلقائية من جهة العميل عند التحميل، فيجمع بين أفضل ما في SSR وSWR.

أي مما يلي لا يؤدي إلى إعادة التحقق في SWR افتراضيًا؟

يطبّق SWR استراتيجية Stale-While-Revalidate: يقدّم البيانات المخزنة مؤقتًا فورًا، ويعيد التحقق منها في الخلفية، ويحدّث واجهة المستخدم عند وصول البيانات الحديثة. ويُفعّل إعادة التحقق عند استعادة التركيز، وإعادة الاتصال، واستدعاء mutate، والاستطلاع. كما تلغي الذاكرة المؤقتة العامة الازدواجية بين الطلبات عبر المكونات، ويمكن تبديل دالة fetcher بالكامل.

يبسّط هذا النموذج شيفرة جلب البيانات بدرجة كبيرة، مع توفير أداء مُدرَك أسرع.