2019 Flutter 心願單

知識小集發表於1970-01-01
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 的我來說並不陌生，它只是不那麼直接和有點冗長。我們來看一個我能找到的最簡單的例子。

2019 Flutter 心願單

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

2019 Flutter 心願單

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

目前，如果我必須在使用以下兩者之間做出選擇

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

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

3. 函式式 Widget

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

2019 Flutter 心願單

我更喜歡後者，因為它簡單。它易於閱讀且沒有那麼多視覺干擾（我承認這是一個客觀的意見，但大多數函數語言程式設計愛好者都會同意這一點）。

我知道，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 是我的想法。

2019 Flutter 心願單

我們在終端中執行 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
2019 Flutter 心願單

來源：https://juejin.im/post/5c495241e51d45599635bcf4

相關文章