שילוב Flutter עם בעלות מפורשת על container.

ProviderScope יכול להחזיק container או לקבל אחד מבחוץ. ממשקי Consumer שומרים על גישת WidgetRef תואמת לקוד בסגנון Riverpod.

בעלות על ProviderScope

בעלות על container משנה את אחריות ה-dispose.

container פנימי

ProviderScope(child: ...) מבצע dispose אוטומטי

container חיצוני

ProviderScope(container: c, ...) מחייב שהקורא יקרא ל-c.dispose()

scope לא מנוהל

UncontrolledProviderScope לעולם לא מבצע dispose ל-container

מלכודת נפוצה

בבדיקות וידג'ט, זכרו לבצע dispose ל-ProviderContainer שהוזרק מבחוץ כדי למנוע דליפות של טיימרים ממתינים.

וריאציות של Consumer

כל האפשרויות חושפות WidgetRef; בחרו לפי סגנון הווידג'ט וצרכי ה-state המקומי.

שורש האפליקציה

מתי להשתמש בכל אחד

Consumer: בלוק בנייה מקומי לאזורים ריאקטיביים קטנים.
ConsumerWidget: ווידג'ט חסר-מצב עם build(context, ref).
ConsumerStatefulWidget: ווידג'ט stateful עם ref בתוך ConsumerState.

דוגמה: ConsumerStatefulWidget

השתמשו ב-ConsumerState כשאתם צריכים גם WidgetRef וגם מצב UI מקומי וניתן לשינוי.

class HomePage extends ConsumerStatefulWidget {
  const HomePage({super.key});

  @override
  ConsumerState<HomePage> createState() => _HomePageState();
}

class _HomePageState extends ConsumerState<HomePage> {
  bool expanded = false;

  @override
  Widget build(BuildContext context) {
    final user = ref.watch(currentUser);
    return Column(
      children: [
        Text('$user'),
        Switch(
          value: expanded,
          onChanged: (v) => setState(() => expanded = v),
        ),
      ],
    );
  }
}
המנגנון הפנימי של Consumer מתזמן בנייה מחדש ל-post-frame, וכך מפחית בעיות של setState במהלך build.
השתמשו ב-WidgetRef.watch רק עבור ערכים שצריכים להפעיל בנייה מחדש.
השאירו תופעות לוואי מחוץ ל-build; השתמשו ב-callbacks ובמתודות invoke/refresh.

השלבים הבאים

בדיקות

אמתו את מחזור החיים של container, את ה-overrides ואת העדכונים האסינכרוניים בבדיקות יחידה ובדיקות וידג'ט.

פתחו בדיקות

הפניה ל-API

ראו את החתימות של ProviderScope, WidgetRef ומתודות container.

פתחו את הפניה ל-API