InheritedWidget — ما هو، نقل البيانات في الشجرة وكيف يعمل

ما هو InheritedWidget في Flutter؟

InheritedWidget هو عنصر واجهة يجعل بياناته متاحة لجميع العناصر المنحدرة في Widget Tree. على عكس العنصر العادي الذي ينقل البيانات فقط عبر المنشئات إلى العناصر الفرعية، يسمح InheritedWidget لأي عنصر في الشجرة الفرعية بالوصول إلى البيانات دون سلسلة من المعاملات. هذا يحل مشكلة «prop drilling» — تمرير البيانات عبر العديد من العناصر الوسيطة التي لا تستخدم هذه البيانات بنفسها.

InheritedWidget المضمنة

يتضمن Flutter العديد من InheritedWidget المضمنة: Theme (نظام الألوان والأنماط)، MediaQuery (حجم الشاشة، الاتجاه، كثافة البكسل)، Localizations (النصوص المترجمة)، Directionality (اتجاه النص)، DefaultTextStyle (نمط النص الافتراضي). هذه العناصر تُعيّن بواسطة العناصر الجذرية مثل MaterialApp وتكون متاحة في جميع أنحاء التطبيق.

دورة حياة InheritedWidget

InheritedWidget لا يملك حالة خاصة به — بل يخزن البيانات التي تمر عبر المنشئ. عندما يُعاد بناء والد InheritedWidget ببيانات جديدة، يُستدعى method updateShouldNotify لمقارنة البيانات القديمة والجديدة. إذا أعادت الطريقة true، يتم وضع علامة على جميع العناصر التابعة لإعادة البناء. هذه آلية تحديث تفاعلية بسيطة لكنها فعالة.

كيف يعمل نقل البيانات عبر InheritedWidget

آلية نقل البيانات عبر InheritedWidget تعتمد على Element Tree. عندما يستدعي عنصر dependOnInheritedWidgetOfExactType، يسجل العنصر المقابل تبعية على InheritedElement. عندما يتغير InheritedWidget، يقوم InheritedElement بإخطار جميع العناصر التابعة، والتي تُعاد بناؤها في الإطار التالي.

تسجيل التبعية

طريقة dependOnInheritedWidgetOfExactType لا تجد InheritedWidget في الشجرة فحسب — بل تشترك في الإخطارات للعنصر الحالي. إذا استخدمت findAncestorWidgetOfExactType بدلاً من dependOn، فسيحصل العنصر على البيانات لكنه لن يُعاد بناؤه عندما تتغير. هذا فرق مهم: dependOn هو اشتراك، findAncestor هو بحث لمرة واحدة.

اجتياز شجرة InheritedWidget

عندما يطلب عنصر InheritedWidget، يصعد Flutter عبر Element Tree من العنصر الحالي إلى الجذر، متحققاً من كل InheritedElement للعثور على تطابق في النوع. يُعاد أول InheritedElement مطابق. هذا يعني أن InheritedWidget الأقرب في الشجرة له الأولوية — يمكنك تجاوز البيانات في مستوى معين بوضع InheritedWidget أقرب إلى المنحدرين.

class ThemeData {
  final Color primaryColor;
  final TextTheme textTheme;

  const ThemeData({required this.primaryColor, required this.textTheme});
}

class MyTheme extends InheritedWidget {
  final ThemeData data;

  const MyTheme({required this.data, required Widget child}) : super(child: child);

  static MyTheme of(BuildContext context) {
    final widget = context.dependOnInheritedWidgetOfExactType<MyTheme>();
    assert(widget != null, "MyTheme not found in tree");
    return widget!;
  }

  @override
  bool updateShouldNotify(MyTheme oldWidget) => oldWidget.data != data;
}

في هذا المثال، MyTheme يستخدم طريقة ثابتة of لتوفير البيانات للمنحدرين. طريقة dependOnInheritedWidgetOfExactType تسجل تبعية، وupdateShouldNotify تقارن البيانات القديمة والجديدة لتحديد ما إذا كانت العناصر التابعة تحتاج إلى إعادة بناء.

إنشاء InheritedWidget مخصص

إنشاء InheritedWidget مخصص يتكون من خطوتين: تعريف فئة تمد InheritedWidget، وتنفيذ طريقة ثابتة of للوصول من المنحدرين. تُمرر البيانات عبر المنشئ، وتحدد طريقة updateShouldNotify متى يجب إعادة بناء العناصر التابعة.

الخطوة 1: تعريف فئة InheritedWidget

يجب أن تمد الفئة InheritedWidget وتقبل البيانات عبر منشئ بمعامل child إلزامي. يمكن أن تكون البيانات من أي نوع: أولية، كائنات، دوال. القاعدة الرئيسية هي أن البيانات يجب أن تكون غير قابلة للتغيير بحيث يمكن مقارنة القيم القديمة والجديدة بشكل موثوق.

الخطوة 2: طريقة ثابتة of

الطريقة الثابتة of تأخذ BuildContext وتعيد بيانات InheritedWidget. داخلياً، تستدعي dependOnInheritedWidgetOfExactType، التي تجد أقرب InheritedWidget من النوع المحدد في الشجرة. إذا لم يتم العثور على InheritedWidget، تطرح الطريقة استثناءً أو تعيد قيمة افتراضية حسب التنفيذ.

الخطوة 3: الاستخدام في العناصر

للوصول إلى البيانات، يستدعي العنصر MyWidget.of(context) داخل طريقة البناء. يشترك Flutter تلقائياً في تحديثات العنصر. إذا تغيرت البيانات، يُعاد بناء العنصر في الإطار التالي. هذا يسمح بكتابة كود نظيف وتصريحي بدون معاملات غير ضرورية.

class UserPreferences extends InheritedWidget {
  final String languageCode;
  final bool darkMode;

  const UserPreferences({
    required this.languageCode,
    required this.darkMode,
    required Widget child,
  }) : super(child: child);

  static UserPreferences of(BuildContext context) {
    return context.dependOnInheritedWidgetOfExactType<UserPreferences>()!;
  }

  @override
  bool updateShouldNotify(UserPreferences oldWidget) =>
    oldWidget.languageCode != languageCode || oldWidget.darkMode != darkMode;
}

في هذا المثال، UserPreferences يخزن إعدادات المستخدم. طريقة updateShouldNotify تقارن كل حقل على حدة، مما يمنع عمليات إعادة البناء غير الضرورية عندما يتغير معامل واحد فقط. استخدم نهجاً مشابهاً لـ InheritedWidget الخاصة بك ذات الحقول المتعددة.

طريقة updateShouldNotify ومنع عمليات إعادة البناء غير الضرورية

updateShouldNotify هي الطريقة الرئيسية لـ InheritedWidget التي تحدد ما إذا كانت العناصر التابعة تحتاج إلى الإخطار بتغييرات البيانات. إذا أعادت الطريقة false، لا تُعاد بناء العناصر التابعة، حتى إذا تلقى InheritedWidget نفسه نسخة جديدة بنفس البيانات. هذا مهم جداً للأداء.

التنفيذ الصحيح لـ updateShouldNotify

قارن فقط تلك الحقول التي تغيرت فعلاً وتؤثر على العرض. إذا كان InheritedWidget يحتوي على 10 حقول لكن واحداً فقط يؤثر على الواجهة، تحقق من ذلك الحقل فقط. للمجموعات، استخدم المقارنة العميقة أو هياكل البيانات غير القابلة للتغيير. لا تستخدم == مع List أو Map، حيث تتم المقارنة حسب المرجع.

• الأنواع الأولية — استخدم المقارنات المباشرة: oldWidget.value != value.
• الكائنات غير القابلة للتغيير — استخدم == المُعاد تعريفه: oldWidget.data != data (إذا كانت data تعيد تعريف ==).
• المجموعات — استخدم listEquals، mapEquals من package:flutter/foundation.dart.

أخطاء في تنفيذ updateShouldNotify

الخطأ الأكثر شيوعاً هو إعادة true بدون مقارنة. هذا يتسبب في إعادة بناء جميع العناصر التابعة عند كل تحديث للوالد، حتى إذا لم تتغير البيانات. الخطأ الثاني هو إعادة false عندما تغيرت البيانات، مما يؤدي إلى واجهة قديمة. الثالث هو المقارنة المعقدة التي تُنفذ كل إطار وتبطئ الأداء.

InheritedWidget مقابل الاستدعاءات: أيهما تختار؟

InheritedWidget والاستدعاءات (تمرير الدوال عبر المنشئات) يحلان مشاكل مختلفة. InheritedWidget مناسب للبيانات التي تحتاجها العديد من العناصر في مستويات مختلفة من الشجرة. الاستدعاءات ملائمة لنقل الأحداث باتجاه واحد من الوالد إلى عنصر فرعي معين أو العكس. يعتمد الاختيار على بنية التطبيق وتكرار التحديثات.

متى تستخدم InheritedWidget

استخدم InheritedWidget عندما تكون البيانات مطلوبة من قبل العديد من العناصر في مستويات تداخل مختلفة: سمة التطبيق، إعدادات المستخدم، معلومات الجهاز، بيانات الجلسة الحالية. InheritedWidget فعال بشكل خاص للبيانات «العالمية» التي نادراً ما تتغير لكنها مطلوبة في أجزاء مختلفة من الواجهة.

متى تستخدم الاستدعاءات

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

InheritedWidget ومكتبات إدارة الحالة

Provider وRiverpod هما مكتبتان شائعتان لإدارة الحالة في Flutter مبنيان فوق InheritedWidget. توسعان قدراته: تضيفان دعم ChangeNotifier، الإزالة التلقائية عند الفك، التهيئة البطيئة، وبناء جملة مبسط مع الأنواع العامة.

Provider المبني على InheritedWidget

Provider يستخدم InheritedWidget لتمرير كائن من أي نوع لأسفل الشجرة. ChangeNotifierProvider يتتبع التغييرات عبر ChangeNotifier ويستدعي updateShouldNotify عند استدعاء notifyListeners. هذا يحرر المطور من إنشاء InheritedWidget يدوياً وتنفيذ updateShouldNotify.

مقارنة مع InheritedWidget المباشر

InheritedWidget المباشر يعطي تحكماً أكبر ولا يتطلب تبعيات خارجية. Provider يوفر بنية تحتية جاهزة: Consumer، Selector، MultiProvider، ProxyProvider. يعتمد الاختيار على تعقيد التطبيق. للمشاريع البسيطة، InheritedWidget المباشر كافٍ؛ للمشاريع الكبيرة، Provider أو Riverpod يقللان من الكود المتكرر.

// InheritedWidget مباشر
class UserProvider extends InheritedWidget {
  final UserData userData;
  const UserProvider({required this.userData, required Widget child}) : super(child: child);
  static UserData of(BuildContext context) => context.dependOnInheritedWidgetOfExactType<UserProvider>()!.userData;
  @override
  bool updateShouldNotify(UserProvider old) => old.userData != userData;
}

// مكافئ Provider
return ChangeNotifierProvider<UserData>(
  create: (_) => UserData(),
  child: MyApp(),
);

كلا النهجين في المثال يحلان نفس المشكلة — تمرير UserData لأسفل الشجرة. Provider يقلل حجم الكود لكنه يخفي آلية InheritedWidget. InheritedWidget المباشر يعطي تحكماً كاملاً وفهماً لما يحدث، وهو مهم بشكل خاص عند تعلم Flutter وتصحيح مشاكل إعادة البناء المعقدة.