Question

我正在学习名为state management approache的{{1}}。我举了一个例子，它工作正常。

在我的示例中，我有一个条目列表和一个用于添加新条目的按钮“ +”。

两个视图都有自己的路线，如下所示：

Provider & Scope Model

 static Widget _buildRoute({
    @required BuildContext context,
    @required String routeName,
    Object arguments,
  }) {
    switch (routeName) {
      case Login:
        return LoginScreen();
      case OccurrenceentriesRoute:
         return  OccurrenceEntries();
      case OccurrenceFormRoute:
        Occurrence occurrence = arguments as Occurrence;
        return OccurrenceForm(occurrence: occurrence);
      default:
        throw 'Route $routeName is not defined';
    }
  }
}

在阅读有关Provider方法的混乱文档之后，我认为将class MyApp extends StatelessWidget { const MyApp({Key key}) : super(key: key); @override Widget build(BuildContext context) { return ChangeNotifierProvider( create: (_) => OccurrenceProvider()..loadOccurrences(), child: MaterialApp( title: 'Mapify', theme: ThemeData( primarySwatch: Colors.blue, ), onGenerateRoute: (RouteSettings settings) { return MaterialPageRoute( builder: (BuildContext context) => Routes.makeRoute( context: context, routeName: settings.name, arguments: settings.arguments, ), maintainState: true, fullscreenDialog: false, ); }, ), ); } }尽可能地放在小部件树中是一个更好的主意，如文档所述：

您不想将ChangeNotifierProvider放置在高于必要的位置（因为您不想污染范围）

我的第一个尝试是在我的buildRoute中使用ChangeNotifierProvider，仅在每条路由中添加我需要的提供者。我这样做了，但是在一个路由上发出的通知不会影响其他路由...所以，我真的很困惑，我应该在除ChangeNotifierProviders顶部之外的其他地方放置此ChangeNotifierProviders？

Answer 1

同意您真的不应该将变更通知者放在顶部，因为那样会重建整个应用程序

使用Multiprovider并将其包装到窗口小部件树的顶部

    like... MaterialApp(
     child:MultiProvider(
         providers:[],
         child:yourWidget()
      ));

then you can access it by final var _sampleProvider = Provider.of<SomeModel>(context);

如果这种解释尚不清楚，我建议您阅读更多内容。

放置ChangeNotifierProvider的最佳位置在哪里？

1 个答案: