序文

今日偶然の発見は、Googleの父の倉庫でフラッタ-提供と呼ばれる状態管理枠組みの中で登場し、最初は非常に新鮮2月8日に、提出されました。クール - 感の後の単語を使用するのは簡単です！だから、今日はこの新しい状態規制の枠組みを共有したいと思います。

プロバイダScopedModelはの代用に設計された、と私たちは、より柔軟なデータ型とデータ処理にすることができますされています。しかし、最初に私たちはそれか、当たり前の状態管理について話しましょう。

なぜ状態管理

我々はアプリケーションの構築を開始すると、それは非常に簡単です。私たちは、直接その上に自分のビューにマッピングされたいくつかの状態を持っています。この単純なアプリケーションでは、状態管理を必要としなくてもよいです。

しかし、増加した機能で、あなたのアプリケーションは、数十または状態の数百を持っています。この時間は、あなたのアプリケーションは、このようにする必要があります。

うわー、これは何地獄です。それはあまりにも複雑になっているようですので、我々は非常に難しく、私たちの状態の明確なテストを維持するために！あなたはこの記事のようなポイントを入力したときに、外部ディスプレイにもポイントの数を必要とする場合と、この2つの状態を同期させる必要上、この時間をたたえ、例えば、外部のサムネイル表示への出口と同じ状態を共有するために複数のページがあるでしょう。

この時点で、我々は早急にこれらの関係を整理するために私たちを助けるためのフレームワークを必要とし、州の規制の枠組みがされて入ってきました。

提供は何ですか

そしてScoped_model等も提供InheritWidget、トップMaterialApp上の共有状態プットを助けます。ベース部材は、状態に応じて、ステータスProvierを取得し、コンポーネントのChangeNotifierを混合することによってリフレッシュを通知します。

また、我々は仕方ストリームにデータを処理できるように、Provide.streamを提供していますが、いくつかの問題が残っている提供し、お勧めできません。

やってみましょう！

ここでは、使用方法の詳細は提供し、例えばシンプルなアプリです。どの状態と複数の状態の間で共有を管理する方法を必要とします。

これらの2つのページが同時に2つの異なる状態カウンターとスイッチャーに依存しています。別のページの状態も変化し、ステータスページで変更後。

プロジェクトは完全なコードはGitHubの上に置かれていています

最初のステップ：追加の依存関係

追加でpubspec.yamlで提供頼ります。

实际添加请参考：https://pub.dartlang.org/packages/provide#-installing-tab-
由于版本冲突添加失败请参考: https://juejin.im/post/5b8958d351882542b03e6d57

第二步：创建Model

这里实际上它承担了State的职责，但是为了和官方的State区分所以叫做model。

import 'package:flutter/material.dart';

class Counter with ChangeNotifier{
  int value = 0;
  
  increment(){
    value++;
    notifyListeners();
  }
}

这里我们可以看到，数据和操作数据的方法都在model中，我们可以很清晰的把业务分离出来。

对比Scoped_model可以发现，Provide模式中model不再需要继承Model类，只需要实现Listenable，我们这里混入ChangeNotifier，可以不用管理听众。

通过 notifyListeners 我们可以通知听众刷新。

第三步：将状态放入顶层

void main() {
  var counter = Counter();
  var providers = Providers();

//将counter对象添加进providers
  providers.provide(Provider<Counter>.value(counter));

  runApp(
    ProviderNode(
        child: MyApp(), 
        providers: providers),
    );
}

ProviderNode封装了InheritWidget，并且提供了一个providers容器用于放置状态。

ProviderScope 为Provider提供单独的类型空间，它允许多个相同类型的提供者。默认使用ProviderScope('_default'),存放的时候你可以通过ProviderScope("name")来指定key。

添加一组Provider的时候建议使用provideFrom或者provide方法，而不是provideAll，因为它可以检查编译时的类型错误。

Provider<Counter>.value将counter包装成了_ValueProvider。并在它的内部提供了StreamController从而实现对数据进行流式操作。

第四步：获取状态

同样的Provide也提供了两种获取State的方法。我们先来介绍第一种，通过Provide<T>小部件获取。

Provide<Counter>(
              builder: (context, child, counter) {
                return Text(
                  '${counter.value}',
                  style: Theme.of(context).textTheme.display1,
                );
              },
            ),

每次通知数据刷新时，builder将会重新构建这个小部件。

builder方法接收三个参数，这里主要介绍第二个和第三个。

第二个参数child：假如这个小部件足够复杂，内部有一些小部件是不会改变的，那么我们可以将这部分小部件写在Provide的child属性中，让builder不再重复创建这些小部件，以提升性能。
第三个参数counter：这个参数代表了我们获取的顶层providers中的状态<T>。

scope：通过指定ProviderScope获取该键所对应的状态。在需要使用多个相同类型状态的时候使用。

第二种获取方式：Provide.value<T>(context)

final currentCounter = Provide.value<Counter>(context);

这种方式实际上调用了context.inheritFromWidgetOfExactType找到顶层的_InheritedProviders来获取到顶层providers中的状态。

如何组织多个状态

和scoped_model不同的是，provide模式中你可以轻松组织多个状态。只需要将状态provide进provider中就可以了。

void main() {
  var counter = Counter();
  var switcher = Switcher();

  var providers = Providers();

  providers
    ..provide(Provider<Counter>.value(counter))
    ..provide(Provider<Switcher>.value(switcher));

  runApp(
    ProviderNode(
        child: MyApp(), 
        providers: providers)
    );
}

获取数据流

在将counter添加进providers的过程中进行了一次包装。我们刚才通过分析源码知道了这个操作能够让我们处理流式数据。

通过 Provide.stream<T>(context) 就能获取数据流。需要注意的是，这里每次获取的数据流都

StreamBuilder<Counter>(
          initialData: currentCounter,
          stream: Provide.stream<Counter>(context)
              .where((counter) => counter.value % 2 == 0),
          builder: (context, snapshot) =>
              Text('Last even value: ${snapshot.data.value}')),

不过在我的使用当中出现了streamTransformer失效的情况。在firstScreen和secondScreen同样应用这一段相同的代码，second screen的where方法能够生效，过滤掉奇数数据，而first screen中则是收到了完整的数据。

需要注意的是，这里每次获取的数据流都会重新创建一条新的流。

  /// Creates a provider that listens to a stream and caches the last
  /// received value of the stream.
  /// This provider notifies for rebuild after every release.
  factory Provider.stream(Stream<T> stream, {T initialValue}) =>
      _StreamProvider<T>(stream, initialValue: initialValue);

关于这个做法还有一些争议，具体可以查看这个issue：
https://github.com/google/flutter-provide/issues/3

不过这个功能还可以结合rxdart使用，可以通过stream轻松构建Observer，让我们更加灵活的组织数据。

根据多个状态重建小部件

当我们一个视图可能依赖于多个状态进行重建的时候，可以使用ProvideMulti小部件。

写在最后

自从上次写完状态管理拓展篇Rxdart之后断更了三个月。总结篇迟迟没有出来，在这里先说一声抱歉。对于我来讲状态管理这个本身就是一个新鲜玩意，所以在没有经过大型应用实战检验的总结都是空谈。这也是为什么我迟迟没有开始写总结篇的原因。不过在这我可以说一些自己的感受，供大家参考。

在这几个月中，我用的比较多的是BLoC，它组织数据确实非常灵活，可以很轻松的实现懒加载之类的操作。而且stateful widget写的是越来越少了。缺点就是入门的门槛比较高，理解StreamTransformer和为什么需要pipe花了我不少时间。使用bloc思维方式需要比较大的改变，我看到了许多人在项目中使用bloc，但是用得很奇怪，还在以之前的思维模式思考。而且bloc只是对数据进行组织，共享状态平时还是使用的InheritWidget，确实要做很多额外的功夫。

其次我比较喜欢的就是scoped_model，理由就是简单好用。学习成本很低，而且没有写什么模版代码。

我最不想使用的状态管理方式就是redux了，一个是入门难度比较高，而且对于异步数据处理我也觉得是相当麻烦的。但是闲鱼团队倒是喜欢redux，之后还会开源闲鱼的状态管理框架fish_redux。所以说，可能还是我编写的应用还不够复杂，才会有这种感受。redux在复杂应用上能够更加清楚的划分职责，并且单向数据流以及state是immutable的特点这些都是redux的好处。

最后我再谈谈Provide。Provide整体上给我的体验非常接近Scoped，简单易上手，并且更加强大。model不用再继承，只用实现Listenable让它不再具有侵入性。于此同时又增加了stream的特性，和bloc的做法又有几分相似。如果你使用过Scoped_model你会很快就上手。

不过可以说的是，Provide是一个非常优秀的状态管理方式，值得你去使用。但是目前该package还存在一些问题，例如Provide.stream，在未来可能会进行较大的变动，需要慎重使用。

本次代码已上传Github: https://github.com/OpenFlutter/Flutter-Notebook/tree/master/mecury_project/example/flutter_provide

如果您对Provide还有任何疑问或者文章的建议，欢迎在下方评论区以及我的邮箱[email protected]与我联系，我会及时回复！

フラッター|状態管理スペシャル--Provide

序文