【译】React Native不是未来

142 阅读5分钟

原文链接:React Native is not the future — Decrypted | Standard Notes

Standard Notes 的代码库在过去的几年里经历了多次演变。当我们首次在 2016 年底推出时,我们有三个代码库:Web 应用程序(Electron 桌面应用程序),一个原生 Swift iOS 应用程序,和一个原生 Kotlin Android 应用程序。这使得我们的应用程序难以维护。在三个平台上协调错误修复已经足够困难了,构建新功能?那是不可能的。我们不得不称我们的应用为“小而美”,因为我们实际上无法使其变得更好。(半开玩笑地说,但这可能是真的。)

从三个代码库到两个代码库

在 2017 年,我们将移动应用转向 React Native,将代码库总数减少到两个。这让我们感觉像是天堂,暂时的。现在,每当我们想要引入一个新功能,比如加密的图片和文件,我们只需要写两次——很棒,对吧?并非如此。当然,最大限度地利用库,确保你不会两次编写关键业务逻辑。然而,在某个时候,我们达到了这种方法的极限,不得不用 C 语言编写低级流加密函数,因为我们的 Web 加密库在移动设备上无法重用。

即使假设您已经最大限度地减少了业务逻辑的重复程度,对于一个小团队来说,在两个代码库中协调新的 UI 功能仍然需要付出双倍的精力。我们的移动端和 Web 端存在不同的问题,并且有不同的工作时间线。一个在移动设备上存在但在 Web 上不存在的错误需要两天才能修复,这意味着 Web 和移动设备始终处于不同的工作线。让 Web 和移动团队在新功能上保持同步是一个持续的挑战。在 Web 上构建通常比移动设备上更快,因此移动设备总是落后。结果是,Web 和移动设备都没有看到任何值得注意的新功能的发展势头。

在 React Native 上构建应用程序而不使用大量第三方库几乎是不现实的。React Native 的包是一种特殊的怪物,因为包的作者需要为两个平台编写代码:一次为 iOS,一次为 Android(当然还有 JavaScript 包装器)。这导致了库被遗弃的数量急剧增加,以及稳定性问题。此外,将你的包与最新版本的 React Native(众所周知,跟上最新版本非常困难)保持同步是一个噩梦。

在某个时候,我们已经看够了。两个代码库——对我们来说太多了。我们开始梦想只写一次代码。想象一下我们能够多快地发布。想象一下将质量和重点集中到一个地方。想象一下不再把移动设备当作一个后续的想法。想象一下梦想一个功能,而不会因为“啊,对了!我们也必须适配移动端”,然后因为翻倍的工作量不切实际而放弃这个功能。单个代码库已经足够了。

一个代码库

当我们从两个代码库过渡到一个时,我们不禁问自己为什么没有早点这么做。如今,Standard Notes 只有一个代码库。我们的移动应用程序只是具有访问手机原生功能的 Web 应用程序,运行效果比我们想象的要好得多。它与我们的桌面应用程序具有 1:1 的功能对等,这在我们过去的设置中是不可能实现的。它可以访问原生移动密钥链、生物识别、本地存储、相机等更多功能。

移除React Native中的React

我们的迁移过程实际上相当简单,主要包括 Web 领域和移动原生领域之间的桥。我们的新移动应用仍然使用 React Native,但只有一个组件:一个渲染 webview 的函数。webview 通过 postMessage 桥接实现了 Web 领域和原生领域之间的消息传递。当 Web 领域想要访问设备密钥链时,它会向原生领域发送一条消息,原生领域会以原始值响应。

原生领域和 Web 领域都不需要考虑“消息”。它们只是函数调用。Web 领域并不知道其函数调用在幕后被转换为 postMessage 调用。Web 同样使用 await 来等待响应,就像它对待任何其他异步函数一样。虽然这不是一篇技术文章,但从高层次来看,我们的架构包括每个平台只需为 Application 实例提供一个 DeviceInterface 类,有了这个接口,应用程序可以在任何平台上运行,甚至可以在命令行上运行。设备接口提供了对设备 API 的访问,如数据库、密钥链或相机。

一个实用的构建移动应用的方法

请不要误解:React Native还是有很多值得喜欢的地方。它的社区和包生态系统充满活力,可能比许多竞品的生态系统更为活跃。但是,如果你也发现对于你的小团队来说,两个代码库实在太多了,那么有一种解决方法。你不必从头开始将你的 Web 应用程序 UI 重写为 React Native。相反,你可以通过 RN 作为桥梁,从你的 Web 应用程序访问原生系统功能。在我们的例子中,我们的新移动应用比过去那个一直在跟进度的半原生应用要好很多倍。你可以亲自体验一下

如果你今天打算这么干,你可以采取与我们类似的方法,或者查看像 Capacitor 这样的库,它们做了非常类似的事情,但缺点是没有像 React Native 那样丰富的第三方包生态系统。

感谢阅读。