我们都希望以对我们来说很容易的方式构建应用程序,而不论目标平台如何。诸如React Native,Flutter,Capacitor和NativeCript之类的项目使我们能够使用JavaScript,Web Tech或Platform-agnostic UI等替代习语来构建本机(例如iOS和Android)应用程序。
这些项目中的每个项目都可以将平台API映射到其习语中(例如React Antial具有“本机模块”),但没有一个完全相互兼容。也就是说,反应本机模块不能在flutter应用程序中使用,反之亦然。这种情况导致了大量重复的努力,并隔离了社区。p>
打开本地抢救。
什么是开放的本地人?
Open Native是长期逾期的Rosetta石头,允许使用本机模块交叉生态系统。它处理所有必要的自动链接,类型编组和API结合,以便您选择项目的最高质量本机模块,无论其来自哪个生态系统。
对于我们的第一次集成,我们已启用NativeScript使用React本地模块完全记录了React Native。
。它是如何工作的?
打开本机仅实现给定生态系统的本机模块API和自动链接(例如React Antial),而不包括任何不必要的核心代码或CLI工具。然后,它以生态系统 - 不合静式的方式公开本地API,另一个框架(例如NativeScript)可以为。
提供最小的适配器。这是使用react-native-auth0的真实示例。
安装
在npm install --save @open-native/core react-native-auth0
Webpack配置
更改您的nativecript应用程序的webpack config(如果这看起来不熟悉,请参见webpack-chain)如下:
-
强制性:别名
react-native
to@open-native/core
。 -
根据需要(请参阅下文):通过
babel-loader
添加一个规则来处理react-native-auth0
。
webpack.chainWebpack((config) => {
config.resolve.alias.set('react-native', '@open-native/core');
config.module
.rule('rnmodules')
// For each React Native native module to be processed with Babel, add an
// 'include' rule here that matches the filepath to its npm package.
.include.add(/node_modules(.*[/\\])+react-native-auth0/)
.end()
.use('babel-loader')
.before('ts-loader')
.loader('babel-loader')
.options({
babelrc: false,
presets: ['module:metro-react-native-babel-preset'],
});
});
对于许多模块,可以省略步骤2 - 只有某些反应本地模块,考虑到地铁,实际上需要在实践中需要babel处理。只需首先尝试无规则构建,如果WebPack引发错误,请尝试使用规则。
与您在React Native中完全使用NativeScript中的模块:
import Auth0 from 'react-native-auth0';
const auth0 = new Auth0({ domain: 'domain', clientId: 'client_id' });
auth0.webAuth
.authorize({ scope: 'openid profile email' })
.then((credentials) => console.log(credentials))
.catch((error) => console.error(error));
这是如何完成的?
我们实际上使用的反应本机模块API和自动链接过程实际上实现了React Native和React Native社区CLI Codebase的反应本机模块API和自动链接过程。这确保了出色的一致性,并为我们提供了广泛的功能覆盖范围。
我们仍在测试不同的本机模块并填补剩余的任何空白。从广义上讲,我们完全支持基于桥梁的非UI模块,并且对涡轮模块,Codegen和JSI的支持正在开发(并且运行良好!)。
UI模块构成了一些挑战,因为它们最终作为React组件分布,因此只能被基于React的应用程序所消耗。如果有兴趣,我们可能会将基本的本机UI模块用于非反应框架,以创建与。
的组件表现
用开放本机运行的本机模块的性能主要取决于主机运行时的性能。本机模块API的实现使用与原始实现完全相同的代码,但是我们在仔细考虑的情况下进行了一些优化,以提高性能。
与iOS上的反应本机相比,在我们与Nativecript的首次集成中,基于桥梁的天然模块几乎快7-8倍(请参见下面的基准)。由于NativeScript能够默认情况下直接调用本机API,而没有桥梁,因此区别很大。
我们还将所有基于桥梁的本机模块视为涡轮模块,懒惰 - 直到第一个API调用,因此启动时间不应受到Nativecript Apps 的影响。。
。至于大小,我们已经采取了我们需要的核心代码,这只是一个足以运行本机模块的本机代码的一小部分。
已经准备好生产了吗?
nStudio的Open Native IS IS 已经在生产中使用了 - 它使他们能够在其NativeScript应用程序中使用react-native-auth0在现成的NativeScript应用程序中填写一些关键的auth0功能,否则从头开始为两个平台编写。
下一步是什么?
允许在其他生态系统中使用React本地模块,从这里开始是一项相对较小的任务,因为我们已经完成了大多数基础工作(以生态系统的方式实现自动链接和桥梁模块API) 。其他生态系统主要需要为最后一步贡献适配器,即从非本地上下文中调用本机模块上的API。
还可以及时解决其他集成,例如允许在其他生态系统中使用飘浮的平台通道,电容器插件和NativeScript插件。如果您认为自己可能会有所帮助,请一定会取得联系,因为我们只能独自解决这么多!
目前,我们很高兴在允许社区共同解决相同问题的过程中推动了第一个多米诺骨牌。
OpenNative / open-native
Open Native将跨平台社区聚集在一起,以帮助他们协作和加强多样性。
Introducing Open Native: Native Modules, for all
We all want to build apps in a way that's approachable to us, regardless of the target platform. Projects like React Native, Flutter, Capacitor, and NativeScript enable us to build native (e.g. iOS and Android) apps using alternative idioms such as JavaScript, Web tech, or platform-agnostic UI.
Each of these projects has a way to map platform APIs into their idiom (e.g. React Native has "native modules"), but none are completely mutually compatible. That is to say, a React Native native module cannot be used in a Flutter app as-is, and vice versa. This situation has led to a great amount of duplicated effort, and an isolation of communities.
Open Native to the rescue.
什么是开放的本地?
开放天然是允许使用本机模块的跨生态系统的长期逾期rosetta石头。它处理所有必要的自动链接,键入编组…