2019 Flutter 心願單

| 做者：Ryan Edge

| 原文連接：medium.com/flutter-com…

| 公衆號連接：mp.weixin.qq.com/s/5ghu1YkFw…

我以前去了 DartConf 2018，最初並無對 Flutter 的有過多的期待，只是想去了解一下。但在離開時，我很是指望看到它在移動平臺以外能蓬勃發展並更加成熟。看看 React Native 在過去幾年裏的發展，我堅信 Flutter 能夠達到一樣的成果，並堅信 Dart 成爲最好的客戶端語言的夢想將會實現。

今年，個人熱情更是大大提高。我清楚地瞭解了 Flutter 計劃如何從移動平臺遷移到桌面和 Web 端，而個人指望也是如此。這裏列一下我但願 2019 年 Flutter 生態系統和框架的在哪些方面有所改進。

1. RFC (Request For Comments) 流程

從技術角度或開發人員的角度來看，這可能不是最重要的特性。可是我以 RFC 開篇，是由於我認爲它爲設計和採用此列表中的一些其餘項目提供了明確的途徑。

若是你不熟悉 RFC 的流程，那麼能夠參考一下 React 的博客（見參考 1），那上面有一篇很好的文章，描述了這個流程以及爲何 React 會採用它。如下是基本步驟：

• 建立一個 RFC 文檔，詳細說明提案；
• 將 PR 提交到 RFC 倉庫；
• 將反饋歸入提案；
• 通過討論，核心團隊可能會也可能不會接受 RFC；
• 若是 RFC 被接受，則會合並 PR；
• 合併後，任何貢獻者均可以提交 PR 實現以供審覈。

React 使用該流程的特定功能突出顯示了其主要用例：

• 建立新的 API 服務區域的提案；
• 刪除已發佈功能的提案；
• 不是 BUG 修復的語義或語法更改

在某些狀況下，例如主要的 API 更改或受益於深刻審覈的新約定，簡單的 GitHub issue 並非最佳的協做方式。除此以外，對比一下將 GitHub issues 頁面的正常模板與 Ember 的很是簡單的 RFC 站點，能夠看到每一個 RFC 都有一個很是深刻的總結，動機以及帶有示例的詳細設計。

目前有幾個值得注目的開源項目正在使用 RFC 流程，並取得了巨大成功：

• Rust
• Ember
• Yarn
• React & React Native
• npm

值得注意的是每一個流程之間的差別很小。若是您熟悉一個流程，那麼其它的基本上都不是問題。它們以公開和可見的方式引入一致性。雖然這些項目中的每個都有本身的方法來管理 issue，但 RFC 的流程很容易識別，由於它更關注目標。

有趣的是，在 Influencing the Flutter SDK (The Boring Flutter Development Show, Ep. 13(參考2) 視頻播出以前，我一直在思考這個問題。值得注意的是，此提案旨在擴展開源項目已經遵循的流程，而不是替換它們。 GitHub issues 仍然有助於標識 BUG 和工做項，如同視頻中描述的。此列表中的如下全部三個項目都是 RFC 的理想候選者。

2. 更簡單的繼承 Widget/Context 模式

我必須閱讀至關多的文章和示例來全面瞭解 InheritedWidget 在 Flutter 中的工做原理。這個概念自己對使用過 React 的我來講並不陌生，它只是不那麼直接和有點冗長。咱們來看一個我能找到的最簡單的例子。

我相信在其它地方可能會有更簡單的例子，但我讀過的大部分文章都與咱們上面的差很少，因此讓咱們繼續吧。如今讓咱們將它與 React 中的相似實現進行比較。

這兩個示例基本上作的是一樣的事情 - 定義一些共享的狀態並將其傳遞給 Provider 但我更喜歡 React 版本，由於它抽離了複雜性。

目前，若是我必須在使用如下二者之間作出選擇

• InheritedWidget；
• Brian Egan 的 Scoped Model 庫或 Remi Rousselet 的 Provider 庫；

那麼我會選擇後者。這是由於這些庫抽象出了開發人員可能不關心的大部分複雜性。對於在應用程序中的多個位置共享某個狀態的簡單用例，我認爲若是官方有一個更簡單，更簡潔的 API，對這些庫的需求就會顯着減小。

3. 函數式 Widget

這多是這個列表中最自私的條目，這是出於我對函數式編程的傾向以及在絕對必要以前避免使用 OOP 的考慮。函數式編程的好處有的不少論據，但這裏我不會介紹。在使用了 Vue 和 React 後，我確信可使用普通函數來更優雅地表示 UI。讓咱們看一下 widget 的一個子類，並將其與函數變體進行比較。

我更喜歡後者，由於它簡單。它易於閱讀且沒有那麼多視覺干擾（我認可這是一個客觀的意見，但大多數函數式編程愛好者都會贊成這一點）。

我知道，Flutter 中的類很重要，由於它們能夠進行優化。我認爲 Flutter＆Dart 團隊能夠輕鬆給出解決方案，就像他們爲依賴注入和 JSON 序列化提供生成器解決方案同樣。

實際上，Remi Rousselet 的 functional_widget 爲這個概念提供了很好的 POC。

4. Hooks

比起函數式 Widget 來，我可能更喜歡 Flutter 中的 Hooks，這樣能夠採用 React 中的一些流行的新舊特性。

Hook 是 React 中用於處理狀態邏輯的新的原語。Hook 容許您重用有狀態邏輯而不改變組件層次結構，這樣能夠避免「wrapper hell」。 Flutter 中存在的與 Hook 最接近的是靜態方法 Theme.of，它容許您從上下文中檢索應用程序主題。如下 widget 是個人想法。

咱們在終端中運行 flutter create 建立的示例與上面的示例有很大不一樣。一個是 HomePage 是一個 Function widget，而且能夠更新計數器的狀態，而無需區分 Stateless/Stateful widgets。我只是調用沒有參數的 count 函數來獲取值，當我但願更新計數時，我用新計數爲參數調用它。Hooks 提供的最大好處是代碼託管。我再也不須要在單個或多個 Widget 和函數之間頻繁切換以理解實現，由於它位於個人 Function widget 中。

在經歷過一個很是大而複雜的 React 項目後，我看到了可使用 Hooks 的應用程序以及它們如何簡化應用程序中一些最複雜的問題。我但願在 Flutter 中也會有它們的身影。

這個概念的一些好的 POC 很是活躍，如 Remi Rousselet 的 flutter_hooks 和 Alfredo Salzillo 的 flhooks

社區挑戰：更多貢獻

JavaScript 生態系統因其社區以及語言的演變而蓬勃發展。Flutter 社區將繼續增加，它依賴於做爲開源軟件貢獻者和消費者的咱們。

我對社區和我本身的挑戰是，咱們以任何方式構建彼此，不管是經過開發、捐款，仍是僅僅是簡單的鼓勵。

結論

Flutter 也有一個很是積極的指望清單，我認爲其中一些能夠幫助他們進一步發展。 至少我堅信 RFC 流程將激發協做，而 Function widget 和 Hooks 將極大地改善開發人員體驗。我但願在 2019 年結束時，我將在明年提出一個全新的願望清單。

參考連接

1. Introducing the React RFC Process
2. Influencing the Flutter SDK (The Boring Flutter Development Show, Ep. 13)
3. Scoped Model
4. Provider
5. functional_widget
6. flutter_hooks
7. flhooks