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

原创
2018/07/13 11:43
阅读数 1.1K

内容大纲:

  • 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。比如拖动排序功能!

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

第三个模块大家仔细看会发现,实际上是和中间的业务层独立开的,这样更有利于项目的扩展和二次开发。第三个模块这里我们把他定义为内核,基于这个内核,我们可以做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

展开阅读全文
加载中
点击加入讨论🔥(3) 发布并加入讨论🔥
3 评论
0 收藏
0
分享
返回顶部
顶部