بعد أن تعلمت شيئاً من أسس بناء التطبيقات والمواقع لعلّك تسائلت كيف تجري عمليات تخزين وعرض البيانات في التطبيقات الكبرى مع المحافظة على الأداء في أدنى مستوياته ! ..

لستُ هنا لأتحدث بشكلٍ مفصّلٍ عن إدارة الحالات state mangment , ولكن لأعطي لمحةً عنه لما سيلي هذا المقال من شرحٍ لأهم مكتبةٍ في فلَتر وهي “ريفربود Riverpod”.

بدايةً دعنا نجرّد نصوصنا البرمجية إلى أبسط شكلٍ ممكنٍ في تطبيقاتنا , سنجدها تنقسمُ إلى ثلاث أقسامٍ رئيسة وهي :

• الواجهة : وهي العناصر التي تظهر للمستخدم

• المتغيرات : وهي المعلومات التي تخزّن فيها القيم

• الدوال : وهي التي تستدعى لتقوم بأمرٍ ما مثل تغيير قيمةٍ معينة , أو جلب بيانات معينة

نلاحظ أن هذه الأقسام الرئيسة شبيهةٌ بحديثنا في مقالنا السابق “التوزيع بأولوية الميزات” والأمر فعلاً شبيهٌ بها , وكلها مفاهيمٌ يربط بعضها بعضاً حتى تكوّن الصورة النهائية.

إذن ما هي إدارة الحالات ؟

إدارة الحالات هي طريقة إدارة المتغيرات في وقت تشغيل التطبيق.

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

من هذه المكتبات :

• Riverpod

• Bloc

• GetX

• Redux

• Provider

لكل مكتبةٍ من هذه المكتبات طريقةُ عملٍ خاصةٍ بها , ولو أخذنا أول اثنتين نجدُ أن لهما طريقتي عملٍ مختلفةٍ كلاهما عن الآخر.

فلو نظرنا إلى Riverpod نجدها تعمل بتعميم Global المزودات Providerعلى المستهلكات Consumer , بعكس بلوك BLoC والتي تعمل بتزويد الصفحات ذاتها بالمزودات بدلاً من تعميمها.

لا يسعنا ذكر الكثيرِ هنا , ولكن لتتضح طريقة عمل بلوك تخيّل أن هناكَ مكعباً فيهِ كلّ شيءٍ من دوال , ثم ان هذا المكعب يتصل بالواجهة فيرسل لها ما تطلبه من متغيرات ويستقبل تحديثاتها فتقوم بتحديث المتغيرات واخذها وارسالها الى الواجهة مرةً أخرى.

ولعل هذه الصورة تزيدُ إيضاحاً للفكرة: