跳到主要内容

旧金山见面会回顾

·阅读时长 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 在移动端快速原型化新体验，并演示了一个类似“你画我猜”应用的快速原型。他们使用与 React Native 类似的方法，通过桥接提供对原生 API 的访问。这一点在 Abhishek 使用设备的摄像头拍摄观众照片，然后在一个人的头上画了一顶帽子时得到了证明。

为 Netflix 的 React Native 设计 API​

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

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

每种方法都有其自身的考量，由您决定哪种最适合您的需求。

方法一

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

方法二

另一方面，照片选择器在 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 仓库镜像到这个新仓库中。在运行测试并构建捆绑包后，构建工件会同步回 Android 和 iOS 仓库。这使得移动工程师无需更改开发环境即可处理原生代码。移动工程师无需安装 npm、运行打包器或记住构建 JavaScript 捆绑包。编写实际 React Native 代码的工程师无需担心在 Android 和 iOS 之间同步代码，因为他们直接在 React Native 仓库上工作。

这确实带来了一些缺点，主要是他们无法进行原子更新。需要原生和 JavaScript 代码组合的更改将需要三个独立的拉取请求，所有这些都必须仔细落地。为了避免冲突，如果自构建开始以来主分支已更改，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 组件利用基于视图控制器的导航栏样式。

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

  • 导航栏不易在 JavaScript 中自定义，因为它是原生组件。这是故意的，因为使用原生导航栏是此类库的硬性要求。
  • ScreenProps 在通过桥接发送时必须序列化/反序列化，因此在此处发送过多数据时必须小心。
  • 导航状态由原生应用拥有（也是库的硬性要求），因此 Redux 等工具无法操作导航状态。

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

结束语​

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

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