الإبطال الانتقائي وإعادة الجلب المشروط

بمجرد أن يُطبّق تطبيق React التخزين المؤقت، يتحسّن الأداء، لكنّ الضغط المعماري يتغيّر. لم تعد البيانات تُجلب بشكل فوري، بل يُعاد استخدامها. يمكن عرض الشاشات فورًا من ذاكرة التخزين المؤقت، ويصبح التنقل سريعًا. ثمّ يحدث التغيير الأول، ويظهر سؤال بسيط ظاهريًا: ما الذي يجب إعادة جلبه الآن؟

في العديد من قواعد البيانات، يصبح الحل واضحًا ومباشرًا. فبعد أي عملية كتابة، تُفقد صلاحية كل البيانات المرتبطة بها. تُعاد تحميل القوائم، وتُعاد تحميل صفحات التفاصيل، وتُعاد تحميل الاستعلامات التي تتم في الخلفية. وتعود واجهة المستخدم إلى حالة التحميل، حتى عند تغيير حقل واحد فقط. ومع نمو التطبيق، تصبح هذه التداعيات أكثر وضوحًا: تقفز قوائم التمرير، وتبدو التفاعلات وكأنها متوقفة مؤقتًا، ويرتفع نشاط الشبكة بشكل حاد بعد كل إجراء يقوم به المستخدم.

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

المشكلة الأعمق ليست في تقادم البيانات، بل في اعتبار هذا التقادم مُعديًا. يُفترض أن تغييرًا صغيرًا ومحدودًا يُبطل أجزاءً كاملة من حالة خادم . عندئذٍ، تتوقف ذاكرة التخزين المؤقت عن ضمان صحة البيانات وتبدأ بالعمل كحاجز مؤقت بين عمليات إعادة جلب البيانات المتكررة.

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

يقارن الرسم البياني أعلاه بين مسارين. في الأول، يؤدي تغيير البيانات إلى إبطال مجموعة واسعة من الاستعلامات، مما يُفعّل عمليات إعادة جلب متعددة وظهور حالات تحميل مرئية في واجهة المستخدم. أما في الثاني، فيتم إبطال إدخالات ذاكرة التخزين المؤقت المتأثرة فقط. وتبقى الاستعلامات غير المتأثرة ثابتة، ولا تتم إعادة الجلب إلا عند الحاجة الفعلية للبيانات.

فصل الرتابة عن إعادة الجلب

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

يُقلل التحقق الانتقائي من نطاق تأثير هذا الغموض. فمن خلال استهداف الاستعلامات التي قد تكون بياناتها الأساسية خادم قد تغيرت فقط، يتم الحفاظ على لقطات مستقرة لبقية واجهة المستخدم. ويمكن للمكونات التي تعتمد على بيانات غير متأثرة أن تستمر في العرض دون انقطاع، حتى في الوقت الذي تعود فيه أجزاء أخرى من النظام إلى وضعها الصحيح.

تُحدد إعادة الجلب المشروطة متى يجب تصحيح البيانات غير الصالحة. لا يحتاج الاستعلام الذي تم وضع علامة "قديم" على أنه قديم إلى إعادة الجلب فورًا، بل يمكنه الانتظار حتى يصبح مرئيًا أو نشطًا أو ذا صلة مرة أخرى. يدعم هذا التقارب في الخلفية دون فرض حالات التحميل أو مقاطعة التفاعلات. تبقى واجهة المستخدم هادئة أثناء استعادة صحة البيانات عند الحاجة.

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

لنقم الآن بناء تطبيق صغير حيث يؤدي تغيير البيانات إلى تغيير جزء واحد من حالة خادم ، ويتم إبطال الاستعلامات التي أصبحت غير مؤكدة فقط. يجب أن تظل واجهة المستخدم غير المرتبطة ثابتة، دون إعادة جلب البيانات أو إعادة الدخول في حالات التحميل.

مثال: إبطال مستهدف مع إعادة جلب مشروطة

يوضح هذا المثال ما يلي: