概述

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

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

背景

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

因為我們在進行項目開發(fā)時，常常會遇到以下情況：

01

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

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

02

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

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

03

場景三：新業(yè)務開發(fā)，技術(shù)選型中

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

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

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

效果演示

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

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

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

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

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

原理介紹

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

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

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

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

比如JSX

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

再比如下的JSX

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

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

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

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

比如：

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

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

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

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

對齊小程序組件庫：

對齊React Native 和 JDReact組件庫：

生命周期和事件

data驅(qū)動視圖， 生命周期和事件提供了對data修改的時機。小程序的組件提供了與React相似的生命周期

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

React的生命周期：