react+mobx+jquery构建大型工具项目经验总结

内容大纲：

• 一、功能介绍
• 二、技术架构
• 三、性能优化
• 四、细节分享
• 五、开源说明

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);

2. why mobx ?

我是个野蛮的开发者，喜欢用最简单的代码，去实现业务，而mobx更加灵活多变，没有那么多限制和约束，而redux比如墨守成规的名门子弟，虽然约束是可让代码更加规范，若是是以大量的代码堆积出来的规范，我仍是以为已经脱离了技术的实际意义，一样是增长维护成本的，我绝对不是一个合格的程序员，若是能 code less，do more，我宁愿牺牲规范不择手段。

3. 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 * 486，要兼容全部机型，就要对其进行缩放处理，要么高100%，要么是宽100%，经过JS去计算显示区域的缩放比例，而后居中处理，就可作到最大化的兼容各类机型。背景是全局的，示意图分别表示手机经常使用尺寸的实例，高度超出的处理，宽度超出的处理，红色部分是显示区域，灰色部分是320*486的原始尺寸比例，黑色阴影部分是灰色部分进行scale缩放填充的区域。

5、关于开源说明

项目近期咱们会在gitee和github上面开源，供你们学习使用，拥抱开源是咱们的选择，可是但愿你们能遵照使用规范，针对我的，咱们是免费的，可是针对商业使用，咱们是收费的，这个决定相信你们都能理解。

欢迎加入QQ群交流：549856478