react+mobx 構建H5製做工具項目經驗總結

內容大綱：

• 一、功能介紹
• 二、技術架構
• 三、性能優化
• 四、細節分享
• 五、開源說明

1、項目功能介紹

好久沒寫過技術類的文章了，此次給你們分享一個近期的項目，採用react+mobx+jquery構建的大型工具類項目。查看項目網址。

若是用過易企秀，maka或者百度H5，搜狐快站的朋友應該對這個工具是很是熟悉的，用戶經過托拉拽等操做，便可輕鬆實現HTML5代碼的編輯工做，大大節約了開發成本，也能夠對模板進行二次編輯，快速生成新的H5頁面，今天的主角是H5DS (全稱：HTML5 Design software) 這是一款WEB的H5製做工具。讓不會寫代碼的人也能輕鬆快速上手製做H5頁面。

作產品前，規劃很重要，這將直接決定項目的成敗！有的項目須要1年，2年或者更長的時間去規劃，規劃 好了才能厚積薄發！這時候咱們須要逃離程序員的思惟，不要單純的從程序開發的角度去看待整個項目！

1. 產品思惟：程序員在要求產品經理懂一些代碼的時候，做爲程序員也要有產品思惟，在作產品前，內心得有個譜，要作一個怎樣的產品（大型項目，小型項目，精品項目，隨便搞搞練手…）？面向的用戶羣體（to C, to B，面向設計師，面向程序員…）？產品定位（面向高端用戶，面向低端用戶）？用戶羣體的需求特徵（懂程序？懂設計？…）？用戶的操做習慣（好比設計師大部分都會使用PS，是按照PS的設計風格來作？…）？等等，一大堆的問題，在作產品前，先儘可能的總結這些疑問，而後給產品一個比較好的定位。
2. 程序員思惟：一款優秀的工具具有有高拓展性，方便易用，性能卓越，咱們的目標不僅是作工具，還要作一個vscode同樣的高擴展性的工具，如何解決高擴展性的問題？如何作編輯器的內核抽離？這些應該是程序員考慮的事情。
3. 如何推廣？如何包裝？如何運營？如何讓這個項目火起來並被你們接受和承認？如何讓更多程序員參與其中？這些是站在一個運營人員的角度考慮的問題。

兼顧以上幾點，咱們不只是一個優秀的程序員，仍是一個優秀的產品經理，更是一個接地氣的運營人員，當咱們作項目的前期，不管是產品，程序員，運營推廣，這些方面的都得考慮到，雖然一我的不能作所有的工做，可是懂點不至於被別人忽悠。若是你的目標是作管理而不只僅是一個程序員，那這些能力，多少應該掌握一點。

2、技術架構方案

技術選型以下：

前端：react, mobx, less, jquery

後端：nodejs, mysql, ngnix

工具：babel, webpack, gulp, eslint

H5DS的技術選型基本上是JS的技術棧，只能說這套技術很前端。接下來我解釋下，爲何要這樣選型。

1. why react ?

   

   整個H5頁面製做的思路是這樣的：生成後的H5頁面雖然是單頁，可是單頁下面仍是有多個子頁面，咱們能夠大體的能夠分爲3個類。APP包含了整個頁面的內容。Page包含了單個子頁面的內容，Layer是每一個子頁面裏面的元素。這樣理解咱們的思路就很清晰了。每一個H5頁面對應有一個JSON文件，而JSON轉化爲JSX模板，再經過renderToStaticMarkup將JSX轉化爲HTML, 我以爲這幅圖是最有效的說明，react強大的服務端渲染函數，能夠直接吧JSX轉化爲HTML。沒有任何人說過，服務器渲染方法就只能在服務器端使用，這裏我直接拿到前端使用，並且效果還很是棒，具體的方法renderToStaticMarkup

// 這個JSON 文件大體格式
{
  ...,
  "name": "H5頁面名稱",
  "desc": "H5頁面描述信息",
  "pic": "主圖URL",
  "pages": [ // H5由多個子頁面組成
    {
      ...,
      layers: [] // 子頁面由多個圖層組成
    }
  ]
}

// JSX -> HTML 的方法
import { renderToStaticMarkup } from 'react-dom/server';
renderToStaticMarkup(JSX);

1. why mobx ?

我是個野蠻的開發者，喜歡用最簡單的代碼，去實現業務，而mobx更加靈活多變，沒有那麼多限制和約束，而redux比如墨守成規的名門子弟，雖然約束是可讓代碼更加規範，若是是以大量的代碼堆積出來的規範，我仍是以爲已經脫離了技術的實際意義，一樣是增長維護成本的，我絕對不是一個合格的程序員，若是能 code less，do more，我寧願犧牲規範不擇手段。

1. why jquery ?

以前不少朋友這樣對我說：用了react就不要用jquery了，jquery能作的事情react也能作，爲何還要用其餘庫？一點也不規範。其實個人回答每每是這樣的：我比較任性，並且喜歡jquery！爲何都廣泛認爲jquery和react不要共存，大體有如下幾點：

1. 從框架層面講，react能夠經過state修改dom，數據會從Virtual DOM到真實的DOM走一遍，若是用了jquery是直接修改DOM，這樣致使的結果就是state和真實的DOM就不能對應起來了，react也就失去了他存在的意義。
2. 從思想方面來說，jquery直接操做dom和react的思想所違背。

可是實際的業務變幻無窮，有哪一個框架能說本身能輕鬆實現全部業務？jquery是工具庫，react是ui庫，若是運用得當，我的以爲配合起來仍是很是不錯的選擇！有時候用jquery操做DOM，在性能方面能完勝react。好比拖動排序功能！

技術選型的問題說完了，接下來聊聊整個項目的架構吧！

第三個模塊你們仔細看會發現，其實是和中間的業務層獨立開的，這樣更有利於項目的擴展和二次開發。第三個模塊這裏咱們把他定義爲內核，基於這個內核，咱們能夠作web層，server層，以及擴展layer層，內核更像ueditor那樣的存在，能夠直接在項目中引用，讓內核再也不依賴任何server，能夠獨立使用。

3、性能優化處理

作工具類的項目，性能是很是大的挑戰，我總結了如下幾個常見的性能優化點：

1. 數據緩存。（indexeddb,localStorage,localSession）
2. 交互優化。（防抖debounce，節流throttle，事件委託）
3. 內存釋放。（componentWillUnmount，DOM釋放，引用地址釋放）

4、技術細節分享

一、圖片裁剪緩存方案

由於編輯器中，圖片裁剪是經常使用的功能，若是採用傳統裁剪模式（前端把裁剪信息傳到服務器，由服務器完成裁剪，返回新的url）對服務器的壓力很是大，爲了節約這些性能開銷，咱們自創了一個裁剪的方法，圖片裁剪後，並無直接丟到服務器去，該方法大大節約了服務器的開銷。具體業務流程以下：

二、拖動排序的性能優化方案

拖動排序若是用純react去實現。業務應該是這樣的：

若是用jquery + react 去實現：

第二種結合jquery的方式，大大減小了react中render函數的執行，不用屢次執行diff操做，實現了高性能的拖動方案。

三、全機型適配方案

咱們固定了顯示區域大小爲 320 x 514，要兼容全部機型，就要對其進行縮放處理，要麼高100%，要麼是寬100%，經過JS去計算顯示區域的縮放比例，而後居中處理，就可作到最大化的兼容各類機型。背景是全局的，示意圖分別表示手機經常使用尺寸的實例，高度超出的處理，寬度超出的處理，紅色部分是顯示區域，灰色部分是320*486的原始尺寸比例，黑色陰影部分是灰色部分進行scale縮放填充的區域。

5、關於開源說明

項目已經在github( https://github.com/h5ds/h5ds ) 上面開源，供你們學習使用，擁抱開源是咱們的選擇，可是但願你們能遵照使用規範，針對我的，咱們是免費的，可是針對商業使用，咱們是收費的，這個決定相信你們都能理解。

歡迎加入QQ羣交流：549856478