當我們與 UI (使用者介面)互動時，會改變資料，進而有儲存資料的需求。

這時候要考慮一些事情：

1. 這些資料要短暫的儲存、還是要存放久一點？
   我們會先把狀態分類成 Ephemeral state (短暫狀態)、App state (應用狀態)。
   Ephemeral state 的例子有：PageView 的當下頁面、複雜動畫的進度、BottomNavigationBar 當下選定的 item 等等。

App state 的例子有：使用者偏好、登入資訊、社交軟體的通知、電商軟體的購物車、新聞軟體的文章已讀/未讀狀態等等。

2. 當 App 的規模層次愈來愈複雜，有很多 Widget，資料要如何在這些 Widget 間傳遞？
   第 2 點便是本文要討論之處。

先想像一個場景，當 Widget 數量一多，我們要傳遞資料時可以透過建構子，接續往 子 Widget 作資料傳遞。這樣看下來似乎有點蠢(我是指:沒效率)。

我想要在樹根 Widget 可以立刻拿到樹頂資料，那要如何做呢？
InheritedWidget 便是拿來解決這項痛點的工具。
你可以在 InheritedWidget 底下的任何 Widget 拿到對 InheritedWidget 的引用。

更清楚地說，這不是在 class 層級的繼承，而是在 Widget 層級的繼承。

InheritedWidget 如果在整個 App 生命週期沒有變化，是被允許的。
但是，如果某東西是 final，根本上來說只代表它無法被重新賦值(reassigned)。
並不意味著它不能在內部被更改！

舉例來說，相較於 value，你可以將一個 service 物件附著在 InheritedWidget。變成資料庫(database) 的封裝(wrapper)、網路 API 的代理，又或是 assets 的提供者(provider)。

實作上，我們可以利用 InheritedSomething.of(context).service 來讓 InheritedWidget 的子 Widget 能夠很方便地取得封裝對象(本例為 service)。或是利用 InheritedSomething.of(context).service.blow() 來方便取得 InheritedWidget 定義的方法。甚至是訂閱一個資料流(stream)。

小結，我們可以利用 InheritedWidget 來取得樹頂(父層)的 App state。