跳到主要内容

San Francisco Meetup Recap

·9 分钟阅读
Héctor Ramos
Héctor Ramos
前 Facebook 开发者布道师

上周我有机会参加了在 Zynga 旧金山办公室举办的 React Native Meetup。大约有 200 人参加，这是一个与我附近的对 React Native 感兴趣的其他开发者会面的好地方。

我特别有兴趣了解更多关于 React 和 React Native 如何在 Zynga、Netflix 和 Airbnb 等公司中使用。当晚的议程如下：

  • React 中的快速原型设计
  • 为 React Native 设计 API
  • 弥合差距：在现有代码库中使用 React Native

但首先，活动以快速介绍和最近新闻的简要回顾开始。

如果 这些 meetup 之一在您附近举行，我强烈建议参加！

Zynga 的 React 快速原型设计​

第一轮新闻之后是 Zynga 的快速介绍，他们是今晚的主办方。Abhishek Chadha 谈到了他们如何使用 React 在移动设备上快速原型化新体验，演示了一个类似 Draw Something 的应用的快速原型。他们使用了类似于 React Native 的方法，通过桥接提供对原生 API 的访问。当 Abhishek 使用设备的相机拍摄观众的照片，然后在某人的头上画了一顶帽子时，这一点得到了演示。

Netflix 的 React Native API 设计​

接下来是今晚的第一个专题演讲。Clarence Leung，Netflix 的高级软件工程师，介绍了他的关于 React Native API 设计的演讲。他首先指出，人们可能从事的库主要有两种类型：组件（如标签栏和日期选择器）以及提供对原生服务（如相机胶卷或应用内支付）访问的库。在构建供 React Native 使用的库时，有两种方法可以采用：

  • 提供特定于平台的组件
  • 一个跨平台库，Android 和 iOS 具有相似的 API

每种方法都有其自身的考虑因素，这取决于您来确定哪种方法最适合您的需求。

方法 #1

作为特定于平台的组件的示例，Clarence 谈到了来自 React Native 核心的 DatePickerIOS 和 DatePickerAndroid。在 iOS 上，日期选择器作为 UI 的一部分呈现，可以轻松嵌入到现有视图中，而 Android 上的日期选择器以模态方式呈现。在这种情况下，提供单独的组件是有意义的。

方法 #2

另一方面，照片选择器在 Android 和 iOS 上的处理方式类似。有一些细微的差异——例如，Android 不像 iOS 那样将照片分组到“自拍”等文件夹中——但这些差异可以使用 if 语句和 Platform 组件轻松处理。

无论您选择哪种方法，最好尽量减少 API 表面并构建特定于应用的库。例如，iOS 的应用内购买框架支持一次性、消耗性购买以及可续订订阅。如果您的应用只需要支持消耗性购买，您可以放弃在跨平台库中对订阅的支持。

在 Clarence 的演讲结束后，有一个简短的问答环节。从中得出的一个有趣的片段是，在 Netflix 为这些库编写的 React Native 代码中，大约 80% 在 Android 和 iOS 之间共享。

弥合差距，在现有代码库中使用 React Native​

当晚的最后一次演讲来自 Airbnb 的 Leland Richardson。演讲的重点是在现有代码库中使用 React Native。我已经知道使用 React Native 从头开始编写新应用有多么容易，所以我非常有兴趣了解 Airbnb 在其现有原生应用中采用 React Native 的经验。

Leland 首先谈到了绿地应用与棕地应用。绿地意味着开始一个项目，无需考虑任何先前的工作。这与棕地项目形成对比，在棕地项目中，您需要考虑现有项目的需求、开发流程以及所有团队的各种需求。

当您在开发绿地应用时，React Native CLI 会为 Android 和 iOS 设置一个单独的仓库，一切都正常运行。Airbnb 在使用 React Native 时遇到的第一个挑战是 Android 和 iOS 应用各自都有自己的仓库。多仓库公司在采用 React Native 之前需要克服一些障碍。

为了解决这个问题，Airbnb 首先为 React Native 代码库设置了一个新的仓库。他们使用持续集成服务器将 Android 和 iOS 仓库镜像到这个新仓库中。在运行测试并构建 bundle 后，构建工件会被同步回 Android 和 iOS 仓库。这允许移动工程师在不更改其开发环境的情况下处理原生代码。移动工程师不需要安装 npm、运行 packager 或记住构建 JavaScript bundle。编写实际 React Native 代码的工程师不必担心在 Android 和 iOS 之间同步他们的代码，因为他们直接在 React Native 仓库上工作。

这确实带来了一些缺点，主要是他们无法发布原子更新。需要原生和 JavaScript 代码组合的更改将需要三个单独的 pull request，所有这些都必须仔细地合并。为了避免冲突，如果 master 在构建开始后发生更改，CI 将无法将更改合并回 Android 和 iOS 仓库。这会在高提交频率的日子（例如，当发布新版本时）导致长时间的延迟。

此后，Airbnb 已转向单仓库方法。幸运的是，这已经在考虑之中，一旦 Android 和 iOS 团队开始习惯使用 React Native，他们很乐意加速转向单仓库。

这已经解决了他们在使用拆分仓库方法时遇到的大多数问题。Leland 指出，这确实会对版本控制服务器造成更高的压力，这对于较小的公司来说可能是一个问题。

导航问题​

Leland 演讲的后半部分集中讨论了一个我非常关心的话题：React Native 中的导航问题。他谈到了 React Native 中大量的导航库，包括第一方和第三方。NavigationExperimental 被提到似乎很有希望，但最终并不适合他们的用例。

事实上，现有的导航库似乎都不太适合棕地应用。棕地应用要求导航状态完全由原生应用拥有。例如，如果用户的会话在呈现 React Native 视图时过期，原生应用应该能够接管并根据需要呈现登录屏幕。

Airbnb 还希望避免在过渡期间用 JavaScript 版本替换原生导航栏，因为效果可能会很突兀。最初，他们将自己限制在模态呈现的视图中，但这显然在更广泛地在其应用中采用 React Native 时提出了一个问题。

他们决定他们需要自己的库。该库名为 airbnb-navigation。该库尚未开源，因为它与 Airbnb 的代码库紧密相连，但他们希望在年底前发布它。

我不会详细介绍该库的 API，但以下是一些关键要点：

  • 必须提前预注册场景
  • 每个场景都显示在其自己的 RCTRootView 中。它们在每个平台上以原生方式呈现（例如，iOS 上使用 UINavigationController）。
  • 场景中的主 ScrollView 应包装在 ScrollScene 组件中。这样做可以让您利用原生行为，例如在 iOS 上点击状态栏以滚动到顶部。
  • 场景之间的过渡以原生方式处理，无需担心性能。
  • 自动支持 Android 返回按钮。
  • 他们可以通过 Navigator.Config UI-less 组件利用基于 View Controller 的导航栏样式。

还有一些注意事项需要牢记：

  • 导航栏不容易在 JavaScript 中自定义，因为它是一个原生组件。这是故意的，因为使用原生导航栏是这种类型库的硬性要求。
  • ScreenProps 每次通过桥接发送时都必须序列化/反序列化，因此如果在此处发送太多数据，则必须小心。
  • 导航状态由原生应用拥有（也是该库的硬性要求），因此像 Redux 这样的东西无法操作导航状态。

Leland 的演讲之后也进行了问答环节。总的来说，Airbnb 对 React Native 感到满意。他们有兴趣使用 Code Push 来修复任何问题，而无需通过 App Store，他们的工程师喜欢 Live Reload，因为他们不必在每次小改动后都等待原生应用重建。

闭幕词​

活动以一些额外的 React Native 新闻结束：

Meetup 提供了一个与社区中其他开发者会面和学习的好机会。我期待着将来参加更多的 React Native meetup。如果您参加了其中一个，请留意我，并告诉我我们如何才能让 React Native 为您更好地工作！