因為Riverpod是由Provider的作者Rémi Rousselet重新打造的Provider威力加強版。好講完了，可以收工了。什麼？又不到300字？好吧，再來混一些字數...

在升級到Riverpod之前，我們先來聊聊關於Provider的一些八卦。Provider作為Flutter官方推薦的基本狀態管理輔助工具，絕對是整個pub.dev上最熱門的套件，沒有之一。

Provider到底是在做什麼呢？過去一年多，你可能會在它的Github上看到它是一個混合了依賴注入和狀態管理的套件：

A mixture between dependency injection (DI) and state management, built with
widgets for widgets.

但最近，它的自我描述終於回到了它真正的初衷，一個更好用的InheritedWidget：

A wrapper around InheritedWidget to make them easier to use and more reusable.

為什麼有這樣的改變？因為「混合依賴注入和狀態管理的套件」這句話造成了Flutter社群很大的困惑。
為什麼困惑？因為Provider在做的事情其實並不是狀態管理。

和InheritedWidget一樣，Provider最主要的功用就只是把我們提昇起來的狀態傳遞下去，我們要更新畫面還得靠ChangeNotifier。然而狀態管理通常是跟整個程式架構有關的，無論是BLoC, Redux, Mobx, MVx, Momentum...選擇了其中一個基本上就決定了我們APP的表現層架構，而且我們也不太可能同時混用兩個以上的狀態管理框架。但Provider卻很神奇的可以跟這其中任何一個並存。有些是使用Provider來provide該架構中的各種元件，有些是內部實作就使用到了Provider。我想這正是Provider並非狀態管理，而只是一個工具的最佳佐證。

喔對了，我有說過Provider在做的事情其實也不是依賴注入嗎？

我還真的有，上一篇我想已經講得相當清楚了，這裡也沒什麼好補充的。

那麼，Provider到底為什麼會被誤認為是依賴注入/狀態管理套件呢？我想這只是因為它所解決的問題，剛好是我們在widget tree裡進行依賴注入和狀態管理時，因為Flutter的激進複合性而產生的問題。以依賴注入而言，是深層widget如何拿到它的依賴。以狀態管理而言，是深層widget如何拿到它的狀態。Provider可以解決依賴注入和狀態管理的變數存取問題，但我們沒辦法只靠Provider就實現依賴注入和狀態管理。

就像板手可以用來修理汽車，也可以用來修理人，但我們並不會說板手是個混合汽車和人的工具一樣，Provider終究只是一個的工具，既不是狀態管理，也不是依賴注入。

講這些八卦的主要目的，還是希望再次強調：所有套件，甚至可以說每一行程式碼，都是為了解決某個問題而存在的。真正瞭解這些套件想解決的問題是什麼，我們才能在無數的選擇中，找出真正適合我們，能夠解決我們的問題的套件。

因此，我們接下來終於要進入正題，看看InheritedWidget實際上有什麼問題，Provider解決了哪些，沒有處理哪些，而Riverpod又解決了哪些問題。我們下次見！