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

#1

内容大纲:

  • 1、功能介绍
  • 2、技术架构
  • 3、性能优化
  • 4、细节分享
  • 5、开源说明

一、项目功能介绍

很久没写过技术类的文章了,这次给大家分享一个近期的项目,采用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. 如何推广?如何包装?如何运营?如何让这个项目火起来并被大家接受和认可?如何让更多程序员参与其中?这些是站在一个运营人员的角度考虑的问题。

兼顾以上几点,我们不仅是一个优秀的程序员,还是一个优秀的产品经理,更是一个接地气的运营人员,当我们做项目的前期,无论是产品,程序员,运营推广,这些方面的都得考虑到,虽然一个人不能做全部的工作,但是懂点不至于被别人忽悠。如果你的目标是做管理而不仅仅是一个程序员,那这些能力,多少应该掌握一点。

二、技术架构方案

技术选型如下:

前端: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。比如拖动排序功能!构建大型项目的时候,有的插件可能会依赖jquery,这里也是一方面原因。

技术选型的问题说完了,接下来聊聊整个项目的架构吧!

第三个模块大家仔细看会发现,实际上是和中间的业务层独立开的,这样更有利于项目的扩展和二次开发。第三个模块这里我们把他定义为内核,基于这个内核,我们可以做web层,server层,以及扩展layer层,内核更像ueditor那样的存在,可以直接在项目中引用,让内核不再依赖任何server,可以独立使用。

三、性能优化处理

做工具类的项目,性能是非常大的挑战,我总结了以下几个常见的性能优化点:

  1. 数据缓存。(indexeddb,localStorage,localSession)

  2. 交互优化。(防抖debounce,节流throttle,事件委托)

  3. 内存释放。(componentWillUnmount,DOM释放,引用地址释放)

四、技术细节分享

1、图片裁剪缓存方案

因为编辑器中,图片裁剪是常用的功能,如果采用传统裁剪模式(前端把裁剪信息传到服务器,由服务器完成裁剪,返回新的url)对服务器的压力非常大,为了节约这些性能开销,我们自创了一个裁剪的方法,图片裁剪后,并没有直接丢到服务器去,该方法大大节约了服务器的开销。具体业务流程如下:

2、拖动排序的性能优化方案

拖动排序如果用纯react去实现。业务应该是这样的:

如果用jquery + react 去实现:

第二种结合jquery的方式,大大减少了react中render函数的执行,不用多次执行diff操作,实现了高性能的拖动方案。

3、全机型适配方案

我们固定了显示区域大小为 320 * 486,要兼容所有机型,就要对其进行缩放处理,要么高100%,要么是宽100%,通过JS去计算显示区域的缩放比例,然后居中处理,就可做到最大化的兼容各种机型。背景是全局的,示意图分别表示手机常用尺寸的实例,高度超出的处理,宽度超出的处理,红色部分是显示区域,灰色部分是320*486的原始尺寸比例,黑色阴影部分是灰色部分进行scale缩放填充的区域。

五、关于开源说明

项目近期我们会在gitee和github上面开源,供大家学习使用,拥抱开源是我们的选择,但是希望大家能遵守使用规范,针对个人,我们是免费的,但是针对商业使用,我们是收费的,这个决定相信大家都能理解。

欢迎加入QQ群交流:549856478

开源地址(喜欢就给个star,谢谢支持!):https://github.com/h5ds/h5ds

#2

看到 react + jquery 这种配置,就没兴趣了

#4

技术是为项目服务的,如果在性能和规范之间做取舍,你会怎么选择?别为了技术而去刻意使用react,会让你的代码维护成本增加,而且性能低下,jquery操作DOM,和原生操作DOM是一样的原理,如果不操作DOM,你能把强交互应用优化做到提升一个数量级别算我输。

#5

并不认同。。。。

#6

曾经我和你想法一致。时间久了,你会认同的~

#8

如果错误的思想也能做出项目,而且扩展性维护性都很好,何来对错之分呢?对或者错是谁来定义的呢?

#9

并没觉得这种混乱的使用,可维护性和扩展性能好到哪里。

#10

建议先看看我的项目,如果是采用纯react也可以做,代码量会增加很多,而且性能也比较低,前提是需要去看下react diff到render是如何实现的。

#11

如何和mobx 配合服务端渲染

#12

你错了,jquery 和 react 代表的是两种思想。是两代web技术,一个是十年前的主流,一个是10年后的主流。。。
既然用了react,那就不要再用 jquery…

#13

错误的思想,只能导致更加错误结果。。。

#14

我在文章中也说了,jquery是直接操作dom的,而react是间接操作dom的,由于react的单向数据流,dom的状态是不可逆的,如果jquery直接修改dom会导致dom和虚拟dom不能同步,但是,如果是修改key的情况下,dom是重新渲染的,这样就会避免这些问题,react虽然不提倡使用jquery,也要看实际的情况,虚拟dom性能未必好,文章中我也做了分析,为什么虚拟dom在某些方面,性能不及直接操作dom好,别被技术牵着鼻子走,无论用什么技术,首先要把项目做出来,在性能和规范之间做取舍,在规范和可维护性之间做取舍,才是一个架构师该有的度量。

PS:jquery在这里,可以当做成一个工具库使用。

#15

你说jquery在这里只是用来操作dom 的,
我想要和你说,
react有api直接操作dom的啊,

#16

我不是说jquery这个库不好,
毕竟它在过去10年,是web开发的主流,
生态系统很庞大,
但是现在已经改朝换代了,
它并不适合react生态系统的思想。

#17

看用到什么地方了,如果是考虑到跨平台跨终端,采用严格的react模式是没错的,用jquery只是当做工具,还有就是贴合项目的需求,生成的页面是依赖jquery的,如果采用纯react,生成的页面也采用react的那套东西,那么生成的代码是没法进行二次开发和修改的。react是有操作dom的,但是并没有jquery那么强大,要做很多代码处理,代码量的增多,后期维护成本也很大,可读性也比较差,在我看来,react只是给我提供了一种web的解决方案,但是他并不是最理想的框架,看过魔道祖师的人都知道,何为魔道何为正道,结果才是最重要的,可以看看项目地址:www.h5ds.com 文档还在整理中,结合技术的优点,你会发现,项目的可拓展性是非常高的,可维护性和性能也是非常不错的。

#18

你够了。。。

#19

jquery 在 react 生态 系统中,就是一种要 完全 清除干净的 病毒。。。

#20

… 我觉得那是你的偏执,技术都是贯通的,没有什么是绝对的,如果在react中使用jquery是病毒,那你用mobx+react还不如去玩vue。先别说那些没用的,你可以实践下,试试react修改dom快还是jquery,简单的一个例子:拖动排序,你试试用react做和试试jquery做,react无论怎么做优化,最终都会输给jquery,只是看使用者如何舍弃,如果你选择规范,OK,可以舍弃性能,如果你选择性能,那么可以舍弃规范,万事没有绝对,等你做了10年前端再回顾我说的话!

#21

jquery就是封建残余。。。

#22

好吧,你说封建就封建吧!也没见你能说出什么有力的言辞,思想被react束缚对技术而言不见的是一件好事情