对于我的flutter项目,我使用以下多个供应商:
@override
Widget build(BuildContext context) {
return MultiProvider(
providers: [
ChangeNotifierProvider<FirstProvider>(
create: (context) => FirstProvider(),
),
ChangeNotifierProvider<SecondProvider>(
create: (context) => SecondProvider(),
),
ChangeNotifierProvider<ThirdProvider>(
create: (context) => ThirdProvider(),
),
ChangeNotifierProvider<FourthProvider>(
create: (context) => FourthProvider(),
),
],
child: const MainApp(),
);
}
因为有时我需要从不同的提供程序获取数据或调用另一个提供程序的函数,所以我这样使用它:
//First Provider
class FirstProvider with ChangeNotifier {
void callFunctionFromSecondProvider({
required BuildContext context,
}) {
//Access the SecondProvider
final secondProvider= Provider.of<SecondProvider>(
context,
listen: false,
);
secondProvider.myFunction();
}
}
//Second Provider
class SecondProvider with ChangeNotifier {
bool _currentValue = true;
void myFunction(){
//Do something
}
}
FirstProvider
的callFunctionFromSecondProvider()
是从小工具调用的,它将成功调用myFunction()
,大多数情况下。
根据函数的复杂性,我有时会遇到无法访问SecondProvider
的情况,大概是因为当小部件状态改变时,context
变成了null
。
我在网上阅读了一些关于provider
的文档,他们建议将changenotifierproxyprovider
作为我所理解的1 to 1
提供商关系。
然而,在我的例子中,一个提供者需要被多个提供者访问,反之亦然。
问题:
在多个提供程序可以访问一个提供程序的情况下,是否有更合适的方法来处理我的情况?
编辑:
访问提供程序还应该能够访问不同的变量值,而无需创建新的示例。
2条答案
按热度按时间lmvvr0a81#
不将
context
传递给callFunctionFromSecondProvider
函数,而是添加第二个provider作为参数。因此,该函数如下所示。vi4fp9gy2#
好吧,我会的
因此,看起来像是同一作者的Riverpod是要走的路,因为它解决了很多缺陷,如提供者依赖于小部件树,在我的情况下,潜在的问题来自哪里。
目前,我仍然需要使用提供者,为了快速而又简单的解决方案,我不仅提供了我试图访问提供者的当前小部件的上下文,而且还直接传递了小部件的父上下文,以便在关闭模态(例如)的情况下,仍然可以使用父上下文执行任何后续的提供者调用。
希望这对你有帮助。