标签：proxy 准备 地方 html http elb builder targe 模型
今天简单说一下flutter中的状态管理，我们这次使用provider；
ps：先说一个概念，Model，模型，这里面定义了我们准备全局使用的数据，或者方法；
举个栗子：我们有一个User类，用来储存用户的信息，比如登录之后，我们会拿到用户的一些个人数据，那么这些数据就可以作为属性写在Model里，同时我们在User内部，还会提供一个upUser方法，用来更新用户信息，那么这个方法也可以写在Model中，OK，以上就是我们准备的User Model;
下面是正题，go，go，go
一、Provider的三个好兄弟：
老大 -- MultiProvider
老二 -- Providers
老三 -- Provider.of<T>(context) / Widget Consumer
二、三兄弟的组合拳：
其实很好理解，我们不去说精髓，先把拳法说一下，靠着拳法去揣摩精髓，会简单很多；
1、老大 MultiProvider
Widget build(BuildContext context) { return MultiProvider( providers: [], ///先不考虑这一句 child: MaterialApp( title: ‘Provider Demo‘, initialRoute: ‘/‘, ), ); }
上面这段代码想必大家很熟悉，一个根widget（先不考虑这一句 providers: [] ），老大的任务就是包裹根节点，将我们准备好的Model和View建立联系；可以想象成一只巨大章鱼包裹了一棵大树，他可以将触手随意的伸向某一节树枝；
2、老二 Providers登场：
其实也很好理解，既然老大可以将我们准备好的各个Model输送到各个节点，那前提是不是老大得知道都有哪些Model需要被送走呢，老二出现了，他就负责预先定义好，需要被共享的Model；
那老二该如何定义呢，我们上面“先不考虑”的那一句就该出现了，providers，老二是个数组，providers中的s也很明显是个复数，他和老大一起使用，老二就是货源，老大就是供货商，那么老三就是消费者了；
当然老二这个数组里面不会这么简单，providers：[provider，provider，providers]，它肯定不会是这个样子，因为我们使用Model的需求不同，老二这个数组里装的儿子有好几种，下面我们就说一下，老二几个常用的儿子：
大儿子：provider 不需要被监听，有的常量或者方法，根本不需要“牵一发而动全身”，也就是说他们不会被要求随着变动而变动，这样的需求就用大儿子定义；
二儿子： ChangeNotifierProvider 对这个儿子父亲要求的就比较多了，它会随着某些数据改变而被通知更新，也就是说，比如这个Model被用在多个page，那么当其中一处被改变时，他就应该告诉其他的地方，改更新了，这样的需求就是用二儿子定义；
三儿子： ChangeNotifierProxyProvider 对这个儿子要求就更高了，所以它的名字都比老二长一截，他不仅要像老二一样，通知更新，还要协调Model与Model之间的更新，比如一个ModelA依赖另一个ModelB，ModelB更新，他就要让依赖它的ModelA也随之更新，这就是老三的活；
具体写法呢，也很简单，官网走起；
3、老三这个人有点怪
我们上面说了老三是消费者，也就是说，他就是负责从各个节点取出数据来使用的；
为什么说他怪，因为他有两种形态，一种是需要绑定在widget中展示用的，另一种则不是，只是需要作为数据去使用；
变身一
var foo = Provider.of<T>(context);
T是你需要的Model，只需如此，你的foo就取出来了；
变身二
Consumer<T>( builder: (context,foo, child) => Text(‘$foo.text‘) )
widget展示，foo如上，也是从Model中取出的数据，随意使用；
OK，三兄弟基本介绍完毕，我也是今天刚刚看到的Provider，如果理解的不对，请你也假装对，哈哈哈，开玩笑，希望大家共同进步；
标签：proxy 准备 地方 html http elb builder targe 模型
原文地址：https://www.cnblogs.com/webcabana/p/12149972.html
