بناء مخزن مخصص باستخدام useSyncExternalStore

يحتاج المخزن المخصص إلى ثلاثة أشياء: بعض الحالة، وطريقة subscribe لتسجيل المستمعين، وطريقة getSnapshot لقراءة الحالة الحالية. هذا هو العقد الكامل الذي تتوقعه useSyncExternalStore.

إن إبقاء المخزن بهذا القدر من البساطة يجعله مستقلًا عن إطار العمل، ولذلك يمكن استخدام المخزن نفسه داخل React أو خارجها.

يستقبل مصنع createStore قيمة أولية، ويعيد كائنًا يتضمن getSnapshot وsubscribe وطريقة update. ويحتفظ داخليًا بالحالة الحالية ومجموعة من استدعاءات المستمعين.

يتيح لك نمط المصنع هذا إنشاء عدة مخازن مستقلة باستخدام دالة واحدة قابلة لإعادة الاستخدام.

عندما تغيّر update الحالة، فإنها تعيّن القيمة الجديدة ثم تستدعي كل مستمع مسجّل. وهذه المستمعون هم الاستدعاءات التي وفرتها React من خلال subscribe.

ويُبلغ استدعاؤهم React بأن المخزن قد تغيّر، مما يحفزها على إعادة قراءة getSnapshot وإعادة تصيير أي مكوّنات تقرأ من المخزن.

يقرأ المكوّن من المخزن باستدعاء useSyncExternalStore مع طريقتَي subscribe وgetSnapshot الخاصتين بالمخزن. وتعيد الوصلة القيمة الحالية، كما تعيد تصيير المكوّن عند تغيّرها.

يمكنك تغليف ذلك في وصلة مخصصة مثل useStore، بحيث تستدعي المكوّنات دالة واحدة بدلًا من إعداد وسائط الوصلة بنفسها في كل مرة.

بما أن المخزن كائن على مستوى الوحدة، فإن أي مكوّن يستورده يشارك الحالة نفسها، من دون الحاجة إلى Context Provider. فلا توجد شجرة يجب تغليفها، ولا تمرير للخصائص عبر عدة مستويات.

وهذه إحدى أهم مزايا المخازن الخارجية: حالة عامة مشتركة بنموذج استيراد واستخدام مسطّح، بدلًا من تسلسل هرمي من Provider.

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

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

تعتمد Zustand، وهي مكتبة شائعة وخفيفة لإدارة الحالة، على هذا النمط تحديدًا، وتستخدم useSyncExternalStore داخليًا منذ الإصدار 4. وتتكون واجهتها البرمجية الصغيرة أساسًا من createStore مصقول مع طبقة محدِّد.

يوضح فهم هذا الارتباط طبيعة هذه المكتبات: فهي أغلفة رقيقة ومريحة حول البدائية نفسها التي يمكنك بناؤها بنفسك.

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

يتطلب هذا استقرار نتيجة selector، لذا استخدم memoization للقيم المشتقة لتجنّب الحلقة اللانهائية الناتجة عن إنشاء مرجع جديد، مع إبقاء التحديثات محصورة في الشريحة ذات الصلة.

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

حتى تسجيل بسيط في console داخل update، يكون مفعّلًا فقط خلف development flag، يساعدكم على فهم تدفق الحالة أثناء بناء المتجر.

بما أن المتجر عبارة عن JavaScript عادي، يمكنكم اختبار منطقه مباشرةً: استدعوا update وتحققوا من أن getSnapshot يعيد القيمة الجديدة، من دون تصيير أي شيء.

يمكنكم أيضًا اختباره داخل React من خلال تصيير مكوّن يقرأ منه والتحقق من حدوث إعادة التصيير بعد update، وبذلك تغطّون المتجر وتكامله معًا.

تذكّروا عقد طريقة subscribe في المتجر المخصص.

يحتاج المتجر المخصص إلى state وsubscribe وgetSnapshot. تمنحكم دالة المصنع createStore، إلى جانب update الذي يُشعِر المستمعين، حالة عامة مشتركة من دون Provider، لأن استيرادات الوحدات تشترك في نسخة واحدة.

استخدموا متاجر شرائح متعددة وselectors للحد من عمليات إعادة التصيير، مع تذكّر ضرورة ثبات المراجع. يعتمد Zustand v4+ على هذا النمط تحديدًا، كما يسهل اختبار المتجر المكتوب بـ JavaScript العادي داخل React وخارجه.