flutte状态管理 Provider 简单原理介绍

更新时间:2023-05-25 21:55

 今天简单说一下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,如果理解的不对,请你也假装对,哈哈哈,开玩笑,希望大家共同进步;