旧金山聚会回顾
上周我有机会参加了在 Zynga 旧金山办公室举办的 React Native 聚会。约有 200 人参加,这是一个与我附近对 React Native 感兴趣的其他开发者会面的好地方。
我特别有兴趣更多地了解 React 和 React Native 在 Zynga、Netflix 和 Airbnb 等公司的使用情况。当晚的议程如下
- React 中的快速原型设计
- 为 React Native 设计 API
- 弥合差距:在现有代码库中使用 React Native
但首先,活动以快速介绍和近期新闻的简短回顾开始
- 您知道 React Native 现在是 GitHub 上最受欢迎的 Java 仓库 吗?
- rnpm 现在是 React Native 核心的一部分!您现在可以使用
react-native link
代替rnpm link
来安装带有原生依赖的库。 - React Native 聚会社区正在快速增长!全球各地各种 React Native 聚会小组现在有超过 4,800 名开发者。
如果 这些聚会之一 在您附近举行,我强烈建议您参加!
Zynga 的 React 快速原型设计
第一轮新闻之后是 Zynga 的快速介绍,他们是今晚的主办方。Abhishek Chadha 谈到了他们如何使用 React 在移动设备上快速原型设计新体验,演示了一个类似“你画我猜”应用的快速原型。他们使用了类似于 React Native 的方法,通过桥梁提供对原生 API 的访问。当 Abhishek 使用设备的摄像头拍摄观众的照片,然后在某人的头上画了一顶帽子时,这一点得到了演示。
Netflix 的 React Native API 设计
接下来是今晚的第一个专题演讲。Netflix 的高级软件工程师 Clarence Leung 发表了他关于 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 仓库镜像到这个新仓库中。在运行测试并构建捆绑包后,构建工件会同步回 Android 和 iOS 仓库。这允许移动工程师在不改变其开发环境的情况下处理原生代码。移动工程师无需安装 npm、运行打包器或记住构建 JavaScript 捆绑包。编写实际 React Native 代码的工程师不必担心跨 Android 和 iOS 同步他们的代码,因为他们直接在 React Native 仓库上工作。
这确实带来了一些缺点,主要是他们无法发布原子更新。需要原生和 JavaScript 代码组合的更改将需要三个单独的拉取请求,所有这些请求都必须仔细地落地。为了避免冲突,如果自构建开始以来 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 组件利用基于 View Controller 的导航栏样式。
还有一些注意事项需要牢记
- 导航栏在 JavaScript 中不易自定义,因为它是一个原生组件。这是故意的,因为使用原生导航栏是这种类型库的硬性要求。
- ScreenProps 必须在每次通过桥梁发送时进行序列化/反序列化,因此如果在此处发送太多数据,则必须小心。
- 导航状态由原生应用拥有(也是该库的硬性要求),因此像 Redux 这样的东西无法操作导航状态。
Leland 的演讲之后也进行了问答环节。总的来说,Airbnb 对 React Native 感到满意。他们有兴趣使用 Code Push 来修复任何问题,而无需通过 App Store,他们的工程师喜欢 Live Reload,因为他们不必在每次小改动后都等待原生应用重建。
结束语
活动以一些额外的 React Native 新闻结束
- Deco 宣布了他们的 React Native Showcase,并邀请所有人将其应用添加到列表中。
- 最近的 文档改版 获得了好评!
- Deco IDE 的创建者之一 Devin Abbott 将教授入门级 React Native 课程。
聚会提供了一个很好的机会,可以与社区中的其他开发者会面并向他们学习。我期待将来参加更多的 React Native 聚会。如果您参加了这些聚会,请留意我,并告诉我我们如何才能使 React Native 为您更好地工作!