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