Riverpod وعمر الـ provider: بيانات تعيش أطول من شاشتها

بيانات العميل القديم تظهر 300ms عند التنقل لعميل جديد — provider بدون autoDispose يبقى حياً في الذاكرة.

#Flutter #Riverpod #State Management

// في هذا المقال

السياق

تطبيق إدارة عملاء بـ Flutter + Riverpod. شاشة التفاصيل تقرأ customerProvider. عند pop ثم push لعميل آخر، بيانات العميل القديم تظهر 300ms قبل تحميل الجديد. المستخدمون يظنون التطبيق خلّط البيانات.

الإجراء

راجعت تعريف customerProvider — لا autoDispose. يبقى في الذاكرة حتى بعد إغلاق الشاشة طالما ProviderScope حي. اختبرت ثلاثة حلول: (1) .autoDispose — يحذف الحالة عند آخر مستمع، (2) ref.invalidate(customerProvider) في initState — يعيد الجلب عند الدخول، (3) customerProvider.family(customerId) — provider مستقل لكل معرّف. استخدمت Riverpod DevTools لتتبع متى تُبنى وتُحذف الحالة.

النتيجة

.autoDispose حل الوميض فوراً — الـ provider يُعاد بناؤه عند كل دخول للشاشة. family أنسب عند فتح شاشتين لعميلين في نفس الوقت (Tab UI). invalidate في initState حل عرضي يفتح race condition: إذا جاء رد الـ API بعد pop الشاشة، يُكتب في provider مهجور.

الدرس

في Riverpod، إغلاق الشاشة لا يعني حذف الحالة — .autoDispose ليس تحسيناً للذاكرة، بل حماية من بيانات متسرّبة بين شاشات مختلفة.

هل تشبه فكرتك هذا المشروع؟ باب التعاون من هنا ‹