Rax App 研发框架背后的思考

前言

Rax 答疑群常常会有相似这样的问题：”个人 rax 版本是 1.1.4，想要使用小程序原生组件应该怎么作？“，从这个问题不难看出，站在使用者的视角来看，Rax 发展到今天已经再也不只有类 React DSL 驱动多端渲染这一单点特性，而是更加多元化的跨端解决方案，是更加立体的：DSL + 研发框架 + 辅助工具 + 平台。前端

通常来讲，咱们回复的第一句是：“你用的什么工程？能够看下 build.json 么？” 因此不难看出，目前 Rax 所提供的多端解决方案是和工程、研发框架密切相关的。react

笔者从毕业到如今也参与过一些 Rax 多端相关的事情，包括淘宝小程序、Rax 转小程序、Rax App 研发框架等等。写这篇文章的目的其一是今年前端委员会跨端专项的部分红果总结、其二是但愿可让你们进一步了解 Rax 跨端框架在实现多端一致性的过程当中经历了什么事情以及背后的思考与选择。webpack

Rax App 研发框架

站在开发者视角，直接和他们打交道的就是 Rax App 研发框架。那么，Rax App 研发框架是什么呢？1. Rax App 提供了构建多端产物的能力，这也是开发者最本质的诉求；2. Rax App 提供了开箱即用的构建配置能力；3. Rax App 提供了项目开发的最佳实践；4. Rax App 会适配不一样容器，尽量提供多端一致的表现。git

更为重要的是，和市面上不少多端方案不一样的是，Rax App 并不会特别倾向于某一个容器的能力打造，咱们的目标是可以让支持的全部容器性能表现和使用体验上都达到业界第一。github

渐进式 React DSL 背后的思考

Rax App 自己是离不开 Rax DSL 的，站在当下的视角来看，Driver 的设计依然是先进的。哪怕是后来的 react-reconciler 其实均可以看到 Rax Driver 的影子。多端渲染的本质是渲染器的能力、绘制视图的 API，因此经过 Driver 能够很好的经过 VDOM 将业务逻辑自己和容器绘制能力解耦。web

JSX 自己带来的是 React 丰富的社区生态以及业务使用的易用性、符合直觉的开发方式。进一步的为了简化部分场景业务使用的复杂度，Rax 提供了 JSX+ 的写法，能够经过 x-if 这样指令轻松完成条件渲染。但目前这样的写法对 TypeScript 支持还不太好，在即将发布的 TS 4.2 将会解决这个问题。json

将来，Rax DSL 在和 React DSL 尽可能保持用法一致亦或是子集的状况下，会有更多符合无线业务场景的判断与选择。小程序

工程与多端解决方案

能力简介

Rax App 目前支持构建 Web/小程序/Kraken/Weex 产物，在 Web 上提供了包括 PHA、SSR 等多样的性能提高方案，小程序上提供了编译时、运行时双引擎方案，同时 Native 侧支持 Kraken、Weex。缓存

小程序

小程序的能力，是前端委员会跨端专项中比较重要的一部分，在过去的 S1，Rax 自己着力提高了运行时方案的性能，而且提供了开箱即用的双引擎混用方案。babel

方案实现本文再也不赘述，能够看如下文章：

笔者更多要介绍的是，在实现这些方案过程当中，咱们的思考是什么？以及遇到了什么问题，怎么解决的。

UI 资源引用

在 Rax 小程序的方案中，咱们支持了运行时项目中使用原生小程序组件、Rax 编译时组件、原生小程序页面、小程序插件等能力，在编译时项目中支持使用原生小程序组件、插件、页面。

丰富的组合能力背后咱们须要考虑的是，IDE 响应速度、用户体感使用速度、使用一致性等等。经过避免 json 配置文件重复写入大幅提高了 IDE 热更新响应速度。经过拷贝 package.json，自动安装依赖避免了因为支付宝构建限制致使的冗余安装流程。经过 AST 分析，自动寻找原生 DSL 写法帮助开发者能够直接经过 import Buttom from '../miniapp-native/Button/index' 写法引用组件。

双引擎混用与分包加载

在双引擎混合和分包加载的背后，除了工程构建以外，咱们奉行『约定大于配置』的准则。好比在 miniapp-compiled 下放置经过 JSX 写的编译时组件；分包模式下 src/pages 下面的一级目录都是独立分包，同时还能构建出几乎一样表现的 Web 产物。

除了以上所说的以外，Rax 小程序工程上还作了不少不少的事情，咱们真的很重视，业务方提出每一条关于使用体验、构建能力上的诉求，在这个庞大的体系之下，咱们更但愿能和开发 Web 同样开发小程序，寻求当下咱们能想到的最优解。在业务纷杂的今天没有十全十美的方案，只有在不断权衡、取舍咱们推荐的最佳实践。

Web

无线 Web 页面，也是截止目前 Rax 深耕最久的领域，咱们提供了比React 更快的 SSR 方案，和 WebView 结合的 PHA 方案：经过框架能力提供相似多页 TabBar、横滑、缓存、Prefetch、同层渲染组件等能力，以及比较基础的快照、保活能力。

配置简化

搞前端最讨厌的事情之一就是配 webpack，得益于 build scripts 拉通了集团的前端工程构建体系。因此，Rax App 能够轻松进行相似以下配置：

alias

{
  "alias": {
    "@components": "src/componentns"
  }
}
复制代码

minify

{
  "minify": false
}
复制代码

babelPlugins

{
	"babelPlugins": ["babel-plugin-import"]
}
复制代码

更多的使用能够看这篇文档。笔者所想表达的是，经常使用的构建配置 Rax App 几乎都有考虑到，你能够不用在乎背后的实现，就轻松达到业务想实现的构建效果。

运行时体验一致性

笔者在这一节将以生命周期为例进行展开。

若是你们接触 React 多的话，可能对 componentWillMount、componentDidMount 这些组件的实例的生命周期比较熟悉。完整的生命周期，更多的指的是什么？更多指的是一个应用的生命周期。

完整的生命周期能够作哪些事情？

埋点：好比说在页面切换过来的时候，我须要上报一个曝光埋点。
监控：好比说一些页面报错怎么收集，假设咱们有本身的监控系统，怎么去看咱们线上业务存在哪些问题。
响应式的交互：好比从 a 页面切到 b 页面，假如 b 页面去作了相似登录的操做，再返回到 a 页面的时候，咱们须要有个 a 页面的生命周期来实现例如权限的一些视图变化，或是状态的切换等等。咱们团队如今是提供了一套面向多终端框架的解决方案，但愿可让用户在开发中后台、PC、无线等多端应用时的开发体验是一致的，这样能够减小开发团队成员的上手成本。
清理定时器：避免一些内存泄漏或者不必的事件回调。
获取启动参数：好比说在小程序里面，须要在应用启动阶段，如 onLaunch 阶段去获取一些启动参数等等。

因此基于上面这些需求，以及业务上的真实痛点，咱们作了多端体验一致的生命周期，主要分为两部分：

App 的生命周期：包括应用的启动 onLaunch 事件，应用的报错 onError 事件，应用的 onShow 事件，应用的 onHide 事件。将来咱们可能会加入针对 TabBar 点击的事件，如在点击 TabBar 时，须要作一些曝光埋点的能力，会针对 TabBar 的操做暴露出相关的生命周期。
页面的生命周期：usePageShow 、usePageHide 等 Hooks，onShow，onHide 等事件。

这里有同窗会问说为何 usePageShow 、usePageHide 这里称为 Hooks，而 onShow，onHide 称为事件。这是由于在社区解决方案里面我常看到的 useXXX，不少其实就是 API 的调用，并非真正的 Hooks，也就是说这种 API 的调用方式跟 Hooks 自己并无关系。咱们这里的 usePageShow 是真正的 Hooks，它跟 onShow 不一样之处在于，usePageShow 的触发时机是在组件渲染完成以后，而 onShow 是在组件示例初始化的时候，也就是页面刚进来的时候，就会触发这个 onShow 事件。

不管是在 Weex，仍是在 Kraken ，仍是在小程序，或是在 Web 等等业务形态上，咱们的方案表现都是彻底一致的，包括触发时机和触发顺序，这样可以让你的业务逻辑在开发时保持彻底一致。usePageShow 是在组件渲染完成以后，onShow 是在组件实例化的时候，也就是页面刚进入时。

总结：Rax 跨端框架的展望

Rax 的愿景，基于前端生态打通多端体系。在跨端体系的建设过程当中，研发框架须要既要扮演构建器的角色，还要扮演拉平体验一致性的角色。将来，咱们会经过 Rax App 研发框架提供更多的最佳实践，例如监控、埋点、数据请求等等，同时也会保持尽量保持克制、稳定性，框架自身测试覆盖率、保证最后生成的 bundle 只包含用户须要的代码、探索新的方案提高构建速度等等。

最后笔者想说的是，Rax 的成长、发展离不开全部业务方的支持，感谢大家选择 Rax，同时感谢可能平时答疑被咱们不当心冷落或者没顾及到考虑的同窗，有大家真好，有大家 Rax 会更好。