Flutter | 狀態管理特別篇——Provide

摘要： 今天偶然發現在谷歌爸爸的倉庫下出現了一個叫做flutter-provide的狀態管理框架，2月8日才第一次提交，非常新鮮。在簡單上手之後感覺就是一個字——爽！所以今天就跟大家分享一下這個新的狀態管理框架。 Provider被設計為ScopedModel的替代品，並且允許我們更加靈活地處理資...

今天偶然發現在谷歌爸爸的倉庫下出現了一個叫做flutter-provide的狀態管理框架，2月8日才第一次提交，非常新鮮。在簡單上手之後感覺就是一個字——爽！所以今天就跟大家分享一下這個新的狀態管理框架。

Provider被設計為ScopedModel的替代品，並且允許我們更加靈活地處理資料型別和資料。但是首先呢還是先說說老生常談的狀態管理。

為什麼需要狀態管理

在我們一開始構建應用的時候，也許很簡單。我們有一些狀態，直接把他們對映成檢視就可以了。這種簡單應用可能並不需要狀態管理。

但是隨著功能的增加，你的應用程式將會有幾十個甚至上百個狀態。這個時候你的應用應該會是這樣。

Wow，這是什麼鬼。我們很難再清楚的測試維護我們的狀態，因為它看上去實在是太複雜了！而且還會有多個頁面共享同一個狀態，例如當你進入一個文章點贊，退出到外部縮略展示的時候，外部也需要顯示點贊數，這時候就需要同步這兩個狀態。

這時候，我們便迫切的需要一個架構來幫助我們理清這些關係，狀態管理框架應運而生。

什麼是Provide

和Scoped_model一樣，Provide也是藉助了InheritWidget，將共享狀態放到頂層MaterialApp之上。底層部件通過Provier獲取該狀態，並通過混合ChangeNotifier通知依賴於該狀態的元件重新整理。

Provide還提供了Provide.stream，讓我們能夠以處理流的方式處理資料，不過目前還有一些問題，不推薦使用。

Lets do it！

我們這裡還是以一個簡單app為例，詳細介紹Provide的用法。其中涉及共享狀態以及多個狀態之間如何管理。

這兩個頁面都同時依賴於counter 和 switcher兩個不同的狀態。並且一個頁面改變狀態之後另外一個頁面狀態也隨之改變。

該專案完整程式碼已放在 Github

第一步：新增依賴

在pubspec.yaml中新增Provide的依賴。

• 實際新增請參考： pub.dartlang.org/packages/pr…
• 由於版本衝突新增失敗請參考: juejin.im/post/5b8958…

第二步：建立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容器用於放置狀態。

providers內部通過 Map<Type, Provider<dynamic>>來儲存provider，在存放的時候你可以通過傳入ProviderScope("name")來指定key。

Provider<Counter>.value將counter包裝成了_ValueProvider。並在它的內部提供了StreamController從而實現對資料進行流式操作。

第四步：獲取狀態

同樣的Provide也提供了兩種獲取State的方法。我們先來介紹第一種，通過Provide小部件獲取。

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

每次通知資料重新整理時，builder將會重新構建這個小部件。

builder方法接收三個引數，這裡主要介紹第二個和第三個。

• 第二個引數child：假如這個小部件足夠複雜，內部有一些小部件是不會改變的，那麼我們可以將這部分小部件寫在Provide的child屬性中，讓builder不再重複建立這些小部件，以提升效能。
• 第三個引數counter：這個引數代表了我們獲取的頂層providers中的狀態。

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中則是收到了完整的資料。 具體還未找到原因，不過可以肯定的是，這個流是一個廣播流。如果是我理解有問題還請大神指出，感謝:pray:。

Provide這個功能還可以結合rxdart使用，讓我們更加靈活的組織資料，用起來非常爽。

根據多個狀態重建小部件

當我們一個檢視可能依賴於多個狀態進行重建的時候，可以使用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是一個非常優秀的狀態管理方式，值得你去使用。

本次程式碼已上傳Github: github.com/OpenFlutter…

如果您對Provide還有任何疑問或者文章的建議，歡迎在下方評論區以及我的郵箱1652219550a@gmail.com與我聯絡，我會及時回覆！