背景
最近接手公司的一个移动端项目,是通过 Rax 作为 dsl 开发的,在发布的时候构建多分代码,在 APP 端编译为能够运行在 weex 上的代码,在 H5(跑在浏览器或者 webview 里面,不管什么技术我们统称 H5) 端使用降级的 weex
这一套开发体系,看起来很完美,一次开发,三端运行。但是真实在开发的时候,就不是这么完美了。由于毕竟是跑在 weex 上的,而不是浏览器。所以在开发方式上也很难直接从 web 端的开发方式平移过去,为了实现跨端运行,所以在样式上只实现了 Css 的子集, DOM API 也是如此,开发的时候,在浏览器里面调试的时候,一切正常,但是等发布到 APP 端用 weex 跑的时候又是各种问题,开发体验很不流畅。
当然,有人会说那是因为你对 weex 的 api 不了解,也对,一直以来对与这种自己搞一套非标准体系来实现各种魔法功能的东西都不怎么感兴趣 但是如果了解它的成本大于了它带来的收益,那么对我们来说,就没有必要做这件事情。
weex 相对于 H5 ,最大的优点在于交互性能上要更好一点。
而随着手机性能的提升,以及 webview 的不断优化,H5 的页面也越来越流畅了,尤其是纯展示形页面上。而且相较于 H5 ,weex 天生不具备 seo 能力,同时存在分享传播困难的缺点,这样看来,使用 weex 的理由就更少了。而且我们在一个新业务上使用 H5 开发了一个页面,借助同构以及提前缓存的能力,已经把首屏打开速度做到了全球秒开,而且业务数据也达到预期,所以我们打算把现有的存量业务都迁移到 H5 上。
这就是我为什么要把基于 Rax 开发的模块代码转换为 React 代码,也就有了本篇文章。
本文针对的 rax 版本是 0.6.8 ,1.x 的版本改动很大,不再本文讨论范围内。
期望的目标
对于一个 rax 模块,我们期望通过编译后:
- 能够在 react 下运行
- 尽可能提取样式到 css 文件里,不使用内联
不同之处
Rax 在开发之处,就是为了能够使用 React 的语法来开发 weex ,所以一开始在语法上和 React 几乎一致。后续随着 rax 的不断迭代,渐渐和 react 有了一些不一样的地方,但是差距不大。
我们对比一下同一个模块在 rax 和 react 的实现代码:
rax module
1 | import { Component, createElement, findDOMNode } from "rax"; |
react module
1 | import { Component } from "react"; |
可以看到他们的区别如下: