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