صباح الخير ..
انا بقالي فتره كبيره بعيد عن كتابة المحتوى الخاص ب Flutter لكني هشارككم النهارده تجربتي مع استخدام Provider في مشروع متوسط الحجم وهقدملك كتير من المعلومات اللي هتحتاج تعرفها فاقرا البوست للاخر للأهمية..
لو انت لسه مبتدئ ف غالبا الكلام هيكون صعب عليك شويه.
كان قراري الشخصي باستخدام ال Provider ليه عدة اسباب منها:
ارتياحي لل architecture اللي بيقوم عليه ال Provider واللي بيشبه الطريقة اللي Flutter بتستخدمها علشان تعمل Update لل widget state.
ال Code Flexibility اللي بيقدمها ال Provider واللي بتتيحلك استخدامه في اكتر من مكان داخل المشروع "بشرط تنظيم الكود".
مكانش عندي تخوفات من قدرة ال Provider انه يشيل مشروع بحجم متوسط.
أماكن استخدام ال Provider داخل المشروع:
إستخدام ال Provider كان في مكانين:
أول مكان في ال View layer فيه مجموعة Providers منفصلين تماماً عن ال View model layer الغرض منها بس هندلة التغييرات اللي بتحصل ف ال widgets اللي مابتحتاجش اي نوع من انواع الداتا اللي موجوده في ال model ولا كمان بتحتاج تدخل من ال handlers لعدم وجود heavy logic to organize يعني ببساطة هو بس موجود علشان يتحكم في ال widgets اللي كل تغييراتها قائمة على ال UI بعيد تماما عن ال data وال business logic وتعقيداتها. ودي حجمها صغير مقارنة بالاستخدام التاني.
تاني مكان وهو الاستخدام الحيوي لل Providers في view model layer .. مجوعة كبيرة من ال Providers اللي بيحتوي على ال business logic واللي بيدير بشكل كبير أغلب ال behaviors جوه الأبليكيشن واللي كلامي هيكون عنهم.
المميزات:
طبيعة ال provider انه singleton مكننا من استغلال النقطه دي لصالحنا في كتير من المواضع اللي بتستخدم نفس ال value في اكتر من مكان زي مثلاً احتياجنا ل token holder ثابت طول ال user journey ولحد ما يقفل الابليكيشن.
سهولة التعامل مع التغييرات وصغر حجم الكود اللي بتكتبه علشان تقدر تعمل set وانك مش بتحتاج مجهود كبير علشان تقدر تعمل retrieve & update واللي بتحصل بشكل instant و efficient.
مرونة الكود اللي تقدر تكتبه جوه ال Provider class واللي تقدر تكتب فيه كل ال Business logic بتاعك بشرط انك تراعي ال SRP علشان الكود بتاعك من السهل جدا انه يبقى messy code.
العيوب:
في كتير من الأوقات هتحتاج تستخدم ال Provider داخل ال initState ولكن مش هتعرف لانه بيحتاج context وده مش بيكون متوفر في ال init فبيكون قدامك حل من اتنين ..
1- انك تستخدمه داخل ال didChangeDependencies وده مش دايماً أفضل حل بسبب ال Unexpected behavior اللي ممكن تقابله لو انت مش فاهم طبيعة ال didChangeDependencies.
2- انك تستخدمه داخل ال init من خلال Future.delayed أو WidgetsBinding وده الحل الأفضل من وجهة نظري.
ال Provider ليست controller قائمة بذاتها بمعنى ان قدرة ال Provider لو انت عايز تستخدمه as orchestrator ضعيفه جداً وبيحتاج Orchestrator layer فوقيها لأسباب كتيره منها:
- ال Provider مايقدرش يكلم other provider بشكل مباشر فهتحتاج orchestrator تباصيله ال Providers اللي هيستخدمها كنوع من أنواع ال method dependency injection.
- الكود بتاعك هيبقى messy code لو مفيش layer تجبر الكود انه يبقى one direction flow والوضع هيزداد سوء كل ما زاد عدد ال features وتداخلها لدرجة انه ممكن يعقد عملية تعديل أو مسح أي كود مكتوب.
ضرورة انتباهك للوقت اللي تستخدم فيها listen: false نظرا لكون ال default قيمته true.
باختصار:
ال Provider ممتاز جداً .. سهل وسريع وبسيط.
لو مش فاهم طبيعة ال Provider هتلاقي نفسك بتسئ استخدامه في كتير من الأوقات بسبب ال Flexibility.
ال Provider بيحتاج layer فوقيه تنظم كل ال events علشان تقدر تستفيد منه الاستفاده القصوى من غير ما تكتب كود متداخل وغير مرتب.
ده كان نظرة عامة وخلاصة تجربة ان شاء الله تفيدك وشرفني برأيك لو شايف حاجه غلط.
#flutter #provider
#منقول
انا بقالي فتره كبيره بعيد عن كتابة المحتوى الخاص ب Flutter لكني هشارككم النهارده تجربتي مع استخدام Provider في مشروع متوسط الحجم وهقدملك كتير من المعلومات اللي هتحتاج تعرفها فاقرا البوست للاخر للأهمية..
لو انت لسه مبتدئ ف غالبا الكلام هيكون صعب عليك شويه.
كان قراري الشخصي باستخدام ال Provider ليه عدة اسباب منها:
ارتياحي لل architecture اللي بيقوم عليه ال Provider واللي بيشبه الطريقة اللي Flutter بتستخدمها علشان تعمل Update لل widget state.
ال Code Flexibility اللي بيقدمها ال Provider واللي بتتيحلك استخدامه في اكتر من مكان داخل المشروع "بشرط تنظيم الكود".
مكانش عندي تخوفات من قدرة ال Provider انه يشيل مشروع بحجم متوسط.
أماكن استخدام ال Provider داخل المشروع:
إستخدام ال Provider كان في مكانين:
أول مكان في ال View layer فيه مجموعة Providers منفصلين تماماً عن ال View model layer الغرض منها بس هندلة التغييرات اللي بتحصل ف ال widgets اللي مابتحتاجش اي نوع من انواع الداتا اللي موجوده في ال model ولا كمان بتحتاج تدخل من ال handlers لعدم وجود heavy logic to organize يعني ببساطة هو بس موجود علشان يتحكم في ال widgets اللي كل تغييراتها قائمة على ال UI بعيد تماما عن ال data وال business logic وتعقيداتها. ودي حجمها صغير مقارنة بالاستخدام التاني.
تاني مكان وهو الاستخدام الحيوي لل Providers في view model layer .. مجوعة كبيرة من ال Providers اللي بيحتوي على ال business logic واللي بيدير بشكل كبير أغلب ال behaviors جوه الأبليكيشن واللي كلامي هيكون عنهم.
المميزات:
طبيعة ال provider انه singleton مكننا من استغلال النقطه دي لصالحنا في كتير من المواضع اللي بتستخدم نفس ال value في اكتر من مكان زي مثلاً احتياجنا ل token holder ثابت طول ال user journey ولحد ما يقفل الابليكيشن.
سهولة التعامل مع التغييرات وصغر حجم الكود اللي بتكتبه علشان تقدر تعمل set وانك مش بتحتاج مجهود كبير علشان تقدر تعمل retrieve & update واللي بتحصل بشكل instant و efficient.
مرونة الكود اللي تقدر تكتبه جوه ال Provider class واللي تقدر تكتب فيه كل ال Business logic بتاعك بشرط انك تراعي ال SRP علشان الكود بتاعك من السهل جدا انه يبقى messy code.
العيوب:
في كتير من الأوقات هتحتاج تستخدم ال Provider داخل ال initState ولكن مش هتعرف لانه بيحتاج context وده مش بيكون متوفر في ال init فبيكون قدامك حل من اتنين ..
1- انك تستخدمه داخل ال didChangeDependencies وده مش دايماً أفضل حل بسبب ال Unexpected behavior اللي ممكن تقابله لو انت مش فاهم طبيعة ال didChangeDependencies.
2- انك تستخدمه داخل ال init من خلال Future.delayed أو WidgetsBinding وده الحل الأفضل من وجهة نظري.
ال Provider ليست controller قائمة بذاتها بمعنى ان قدرة ال Provider لو انت عايز تستخدمه as orchestrator ضعيفه جداً وبيحتاج Orchestrator layer فوقيها لأسباب كتيره منها:
- ال Provider مايقدرش يكلم other provider بشكل مباشر فهتحتاج orchestrator تباصيله ال Providers اللي هيستخدمها كنوع من أنواع ال method dependency injection.
- الكود بتاعك هيبقى messy code لو مفيش layer تجبر الكود انه يبقى one direction flow والوضع هيزداد سوء كل ما زاد عدد ال features وتداخلها لدرجة انه ممكن يعقد عملية تعديل أو مسح أي كود مكتوب.
ضرورة انتباهك للوقت اللي تستخدم فيها listen: false نظرا لكون ال default قيمته true.
باختصار:
ال Provider ممتاز جداً .. سهل وسريع وبسيط.
لو مش فاهم طبيعة ال Provider هتلاقي نفسك بتسئ استخدامه في كتير من الأوقات بسبب ال Flexibility.
ال Provider بيحتاج layer فوقيه تنظم كل ال events علشان تقدر تستفيد منه الاستفاده القصوى من غير ما تكتب كود متداخل وغير مرتب.
ده كان نظرة عامة وخلاصة تجربة ان شاء الله تفيدك وشرفني برأيك لو شايف حاجه غلط.
#flutter #provider
#منقول
❤19👍8🥰2