概述

JDReact是CMO體系商城前臺(tái)產(chǎn)品研發(fā)部推出的多端融合開(kāi)發(fā)框架。經(jīng)過(guò)不斷的技術(shù)完善，目前已經(jīng)在手機(jī)京東客戶端累計(jì)接入 100+ 業(yè)務(wù)，穩(wěn)定支撐 千萬(wàn) 級(jí)DAU，并對(duì)外支持 15+ 個(gè)獨(dú)立APP，擁有完善的 API 和功能強(qiáng)大的開(kāi)發(fā) IDE 工具。

本文重點(diǎn)介紹了JDReact提供的小程序雙向轉(zhuǎn)換工具的原理及用法，通過(guò)此工具可以把已經(jīng)開(kāi)發(fā)的微信小程序低成本轉(zhuǎn)換成JDReact應(yīng)用，也支持把現(xiàn)有JDReact業(yè)務(wù)低成本轉(zhuǎn)換成微信小程序應(yīng)用，完全實(shí)現(xiàn)了JDReact和微信小程序生態(tài)的打通。

背景

此項(xiàng)目的最初靈感來(lái)源于我們團(tuán)隊(duì)今年5月份參加第六屆黑客馬拉松大賽并獲得冠軍的項(xiàng)目“微信小程序一鍵轉(zhuǎn)換工具” http://tech.jd.com/techical/questionDetail?id=771 (京東內(nèi)網(wǎng))

因?yàn)槲覀冊(cè)谶M(jìn)行項(xiàng)目開(kāi)發(fā)時(shí)，常常會(huì)遇到以下情況：

01

場(chǎng)景一：已經(jīng)開(kāi)發(fā)微信小程序，遷移到APP

項(xiàng)目之初，為了更好的利用微信的流量，更加方便的推廣，我們會(huì)先直接發(fā)布一個(gè)小程序，等到后來(lái)我們的用戶越來(lái)越多，應(yīng)用也變得越來(lái)越復(fù)雜。這個(gè)時(shí)候想要把這個(gè)應(yīng)用獨(dú)立出來(lái)，把客戶掌握在自己手里，進(jìn)一步定制應(yīng)用。此時(shí)，沒(méi)有其他辦法，我們只能叫上Android，IOS開(kāi)發(fā)人員，叫上之前的產(chǎn)品經(jīng)理，之前的測(cè)試把之前小程序的功能再重新在原生上實(shí)現(xiàn)一遍。

02

場(chǎng)景二：已經(jīng)開(kāi)發(fā)APP，遷移至小程序生態(tài)

也可能，我們現(xiàn)在已經(jīng)有了獨(dú)立App，現(xiàn)在由于種種原因（流量的需求，運(yùn)營(yíng)的需要），需要發(fā)布一個(gè)小程序的版本。怎么辦呢？同樣我們只能叫上小程序開(kāi)發(fā)人員，之前的產(chǎn)品經(jīng)理，之前的測(cè)試在復(fù)制一個(gè)小程序的版本。

03

場(chǎng)景三：新業(yè)務(wù)開(kāi)發(fā)，技術(shù)選型中

或者，我們現(xiàn)在即將開(kāi)始一個(gè)新的項(xiàng)目，這個(gè)項(xiàng)目既有獨(dú)立App也有小程序版本（或者可見(jiàn)的未來(lái)會(huì)有兩個(gè)版本）。 那么我們是不是需要保持原生團(tuán)隊(duì)， 小程序團(tuán)隊(duì)，從而進(jìn)行兩個(gè)版本的開(kāi)發(fā)呢？

如果我們可以把JDReact的應(yīng)用轉(zhuǎn)化為小程序，把小程序轉(zhuǎn)化為JDReact應(yīng)用，那么我們就可以低成本的把原來(lái)的JDReact項(xiàng)目/小程序項(xiàng)目移植到另一端了。而且新開(kāi)始的項(xiàng)目我們就可以根據(jù)人員配置只開(kāi)發(fā)一個(gè)JDReact的版本或者小程序的版本，等未來(lái)需要的時(shí)候，直接轉(zhuǎn)化為對(duì)應(yīng)的另一端。

由于只需要維護(hù)一端的版本，就可以大大的降低軟件工程師的工作，同時(shí)產(chǎn)品，測(cè)試的工作量也會(huì)相應(yīng)的減輕很多。另外， 我們希望轉(zhuǎn)化之后的代碼具有良好的可讀性， 方便再次開(kāi)發(fā)與修改。

效果演示

我們先用一個(gè)實(shí)際的例子來(lái)展示下轉(zhuǎn)化工具的效果， 我們利用JDReact轉(zhuǎn)換工具將  “值得買京東優(yōu)選”的微信小程序 轉(zhuǎn)化為對(duì)應(yīng)的 JDReact版本 并運(yùn)行在 手機(jī)京東客戶端中 ；

首先看一下微信小程序版“值得買京東優(yōu)選”

轉(zhuǎn)化引擎將會(huì)遍歷尋找小程序源代碼目錄中的wxml，進(jìn)行轉(zhuǎn)化期間會(huì)合并其對(duì)應(yīng)的wxss， json， js文件。

轉(zhuǎn)化完成之后，啟動(dòng)生成的JDReact原代碼目錄，運(yùn)行模擬器查看效果。

以下是運(yùn)行中手機(jī)京東客戶端中的JDReact版“值得買京東優(yōu)選”

原理介紹

不管是React應(yīng)用還是小程序應(yīng)用都可以表達(dá)為：ui = f(data)。并且他們提供很相似的數(shù)據(jù)更新方式，小程序是 setData(newData, cb) ， React是  setState(newState,cb) ，這兩個(gè)基本條件是我們轉(zhuǎn)化引擎的前提，基于此前提，轉(zhuǎn)化工作理論上是可行的。

f在React里面可以簡(jiǎn)單的理解為JSX，在小程序里面可以理解為wxml。wxml是小程序提供的“靜態(tài)”的書寫ui的方式靈活性比較低。JSX是react提供的方式，很靈活，里面可以嵌入任何表達(dá)式，本質(zhì)上就是JS。如果我們可以把JSX代碼翻譯為等效的wxml代碼，把wxml代碼翻譯為等效的JSX代碼，那么我們就有能力實(shí)現(xiàn)兩種應(yīng)用的轉(zhuǎn)化。

顯然，我們的引擎必須能夠“讀懂”代碼，為了實(shí)現(xiàn)這個(gè)目標(biāo)，首先我們將代碼轉(zhuǎn)化為AST格式，然后根據(jù)相應(yīng)規(guī)則不斷的修改AST結(jié)構(gòu)，最后生成新的代碼。通過(guò)babel-parse（把源代碼解析為AST），babel-traverse（遍歷操作AST），babel-generator（生成新代碼）來(lái)實(shí)現(xiàn)對(duì)源代碼的操作。這個(gè)相應(yīng)規(guī)則源自于兩端的等效寫法。 比如說(shuō)： wx:for 和 Array.map的對(duì)應(yīng)， wx:if和邏輯表達(dá)式的對(duì)應(yīng)。

然而，并不是所有的規(guī)則都這么顯而易見(jiàn)

比如JSX

對(duì)于這種情況我們會(huì)不斷遍歷JSX表達(dá)式，如果發(fā)現(xiàn)是函數(shù)調(diào)用，將會(huì)用“返回值替換”， 也就是會(huì)用getView的返回值來(lái)替換對(duì)應(yīng)JSX表達(dá)式，替換的時(shí)候需要處理好數(shù)據(jù)綁定。

再比如下的JSX

wxml的變量綁定“{{}}”是不能出現(xiàn)函數(shù)調(diào)用（wxs除外）的，這種情況，我們將會(huì)使用“表達(dá)式前置”， 也就是相應(yīng)表達(dá)式的值提前放置在小程序的data中，轉(zhuǎn)化之后的wxml可能如下：

遍歷AST的時(shí)候，需要不斷的判斷 JSX表達(dá)式 是否需要前置。最后轉(zhuǎn)化之后的data會(huì)保護(hù)很多這樣的var

由于JSX的足夠靈活，在進(jìn)行JSX轉(zhuǎn)向wxml，我們將會(huì)有很多類似的轉(zhuǎn)化規(guī)則。

那是不是 wxml轉(zhuǎn)JSX就一帆風(fēng)順呢？ 也不是， 首先一個(gè)問(wèn)題。babel-parse并不識(shí)別wxml代碼格式。對(duì)于wxml，我們需要預(yù)處理wxml， 使其可以被parse識(shí)別。另外wxml的很多奇怪表現(xiàn)也是我們轉(zhuǎn)化的時(shí)候需要兼容的。

比如：

小程序 的data里面并沒(méi)有a屬性，更別說(shuō)b屬性，c屬性。但是這個(gè)在小程序里面是表現(xiàn)正常的，而且很常見(jiàn)。我們不希望轉(zhuǎn)化之后的程序在這種情況下報(bào)錯(cuò)，我們對(duì)這種表達(dá)式進(jìn)行了容錯(cuò)，react-native（預(yù)計(jì)0.56版本）支持optional-chaining之后，我們也會(huì)跟進(jìn)用optional-chaining來(lái)改造這種情況。

wxml到JSX的轉(zhuǎn)化，我們已經(jīng)基本完成。JSX到wxml的轉(zhuǎn)化已經(jīng)覆蓋所有常見(jiàn)的寫法。 隨著越來(lái)越多的規(guī)則被添加進(jìn)來(lái)，我們轉(zhuǎn)化引擎能夠覆蓋的情況將會(huì)越來(lái)越多。

但是轉(zhuǎn)化引擎應(yīng)用于實(shí)際項(xiàng)目還有一段距離，因?yàn)椴还苁切〕绦蝽?xiàng)目還是JDReact項(xiàng)目都不可能只有View， Text組件， 即使我們把 users && <FlatList/>  轉(zhuǎn)化為小程序  <FlatList wx:if="{{users}}"/> 也是沒(méi)有作用的，小程序根本就不認(rèn)識(shí)FlatList。 要想讓小程序認(rèn)識(shí)FlatList，我們需要在小程序端實(shí)現(xiàn)一個(gè)小程序版的FlatList，好在發(fā)展到今天，小程序的自定義組件已經(jīng)很完善。

意味著我們需要對(duì)齊兩端組件，需要在小程序端實(shí)現(xiàn)一套JDReact的組件庫(kù)，包括FlatList， SectionList，JDImage，JDSwiper等，同時(shí)實(shí)現(xiàn)組件的對(duì)應(yīng)屬性。 在React Native端，我們也必不可少的需要實(shí)現(xiàn)一套這樣的小程序組件，包括 form，radio， radio-groupd等。實(shí)際上出于對(duì)齊屬性的考慮，包括view/View， text/Text這些基本組件，也是通過(guò)在另外一端實(shí)現(xiàn)對(duì)應(yīng)組件這種方式實(shí)現(xiàn)的。

對(duì)齊小程序組件庫(kù)：

對(duì)齊React Native 和 JDReact組件庫(kù)：

生命周期和事件

data驅(qū)動(dòng)視圖， 生命周期和事件提供了對(duì)data修改的時(shí)機(jī)。小程序的組件提供了與React相似的生命周期

小程序自定義組件生命周期： 

React的生命周期：