Scheme distal common market chart data

Foreword

Often in the front-end business background development data charts, similar Echarts for this highly configurable library, takes a lot of time to view the document, only a small part of the project under the statistical charts in most cases, usually not much to write easy to forget the configuration, low repetition development efficiency. Product manager for design personalized chart significantly (see chart today is a style that is quite good, and then wanted to copy into your own business), the same type of chart styles may differ, they have to re-write the code. It gives the feeling is always low development efficiency, low efficiency of product design.

At the beginning of the article we take a look at the front end of a normal process in the development of a variety of data charts, it may be experienced to Echarts example:

1. Open echarts official website
2. See Examples interface, like reference legend to be achieved, the code will find examples of suitable examples of copies required
3. Open Business project copy the code, find the need to install dependencies, perhaps by introducing html script, perhaps the introduction of (in this case might also need to configure the dependent webpack solve some optimization problems) by way of module
4. Discover the details and ui or prototype does not match, start looking for document configuration, such as: the axis color, scale color, inside pitch, reminders, copy templates, etc.
5. When do the second chart, and found a line chart is similar, but this is a figure more than polylines, ui has undergone some changes in the details, and then repeat step 4 above.
6. Some time later, another business project, again to do data chart. This time, think have done before, and then find the old project comparison chart, copy similar code, modify the details of the inconsistencies found the place began to Step 4

Because every time you do a chart is not the same repeat steps 4 and 5 several times, spent a lot of time has, together with the configuration code itself more and more, you can make the chart two or three hundred lines of code on. Experienced several such a toss later, probably a little bit familiar with the API, but still feel good every time low development efficiency. Then there is the share made today, enter the following text.

 

 

 

 

Program

For each business application scenarios project development company background data charts, in order to solve the above two efficiency, I do think the process through the following two directions:

• Abstract codes to reduce the amount of application code, Fool configuration avoids every developer to spend time re-read the document - to enhance the development efficiency.
• Use unified chart style, to some extent reduce personalization, a chart of the interface and the corresponding assembly code - improving product design efficiency.

 

简单来说，就是封装公共图表组件供团队使用，约定统一图表样式，提供可视化界面文档

优点：

• 只关心更核心的配置、组件抹去配置细节、提升开发效率
• 提升产品设计效率、省去设计选择的时间

缺点：

• 缺少一定灵活性（抽离常用部分，牺牲灵活性，多用共性）
• 公共图表组件开发需要投入成本 

 

实施

JS组件库

目的和方向已经明确，我们可能会第一时间想到，那肯定就是基于三方图表库做一次组件封装，通过npm安装依赖，最后再写好文档就行了。现在称它为JS组件库方案，那我们来考虑考虑此方案组件库的一个实现和使用流程，以Echarts为例

1. 新建一个代码库，安装echarts依赖
2. 新建组件（比如一个折线图组件）
3. 封装组件参数，回调方法等
4. 如果要兼容vue，angular，react，组件代码需要写三套兼容，或者通过代码优化和构建处理，一套代码生成多种框架组件
5. 定版本，发布组件库
6. 写一个网页文档并在网页上展示实例
7. 业务系统安装组件库使用
8. 如果代码需要升级或者修改bug，需要重新修改组件库，并发新版本，业务系统重装依赖

下图为此方案的示意图：

 

但是以上的方案带来了一些麻烦和问题：

• 可能需要兼容多套框架，组件库开发成本增加
• 修改bug和库升级都需要发版本，每一个业务系统都有可能需要在一个版本之后更新依赖，维护成本增加

 

Iframe方案

而我最初的下手点是通过iframe + postMessage来实施了这套方案，下面介绍一下此方案。此方案最终把一个个组件输出为一个静态的页面，通过iframe的方式，嵌入到我们的业务系统之中，通过postMessage来传递数据、配置和事件绑定。先介绍一下大致开发和使用流程，而后对其优劣做分析。

1. 新建代码库，安装echarts依赖
2. 新建页面组件（比如一个折线图组件）
3. 封装组件参数，回调方法等
4. 打包输出为一个个静态资源页面，发布到静态资源服务器
5. 写一个网页文档并在网页上展示实例
6. 业务系统不需要安装任何依赖，通过Iframe配置url引入组件，通过postMessage发送配置和数据
7. 如果代码需要升级或者修改bug，重新修改组件库，打包更新静态资源，业务系统不需要重装依赖直接访问就更新。如果存在变化比较大的类似组件，可以考虑输出新版本，比如老版本是xxx.com/v1/bar.html,新版可以定义为xxx.com/v2/bar.html，互不影响

 

下图为此方案的示意图：

 

 

 

 

 下面我们来对比一下两个方案：

 

  

优化

稳定性：

Iframe有个比较需要特别谨慎的地方就在于其稳定性上的问题，由于所有业务系统的图表都指向到公共图表项目，都需要对其进行访问，如果出现了问题，那影响是很大的。由于业务系统是分散的，我们在发布新的公共图表项目版本的时候，需要进行一轮测试，测试新版本，首先需要满足的是不影响已有业务系统。于是，针对这两个问题，我们一方面需要严格保障公共图表项目的代码质量，在代码合并权限控制和人为review上需要格外重视；一方面可以同样通过Iframe的方式，在公共图表的文档网站页面加入一个页面菜单、嵌入所有中后台业务系统的相关页面。由于我们中后台统一接入了公司内部开发的sso权限登录系统，因此可以根据当前的登录用户和他的权限，看到他所能够看到的业务系统的图表统计相关的页面。那我们给一个测试用户配置所有业务的权限，就能通过公共图表系统本身查看到所有业务相关界面，以此来做测试验收。

也因为如此，公共图表项目本身不仅提供了页面组件给业务中后台系统使用，也同时集合了所有业务系统的数据统计界面，变成了一个真正的数据大盘。到此我们的方案就是一个完整的公共图表数据大盘。

资源大小

在静态资源大小方面，每一个html组件，只引入了一个三方图表库和组件本身的一小段js代码，并没有引入任何框架，尽可能的减少文件大小。

迭代原则：

首先做封装是有成本的，并不是一开始我们就写好所有的组件库，而更多应该是在开发需要某一种图表时，再考虑进行封装，封装的同时不仅要考虑当前版本使用，也要尽量考虑通用性和后期其他项目使用的情况

纯个性化配置

当然很多情况下 需要个性化配置我们的图表，既然当前已经有了公共系统，如果遇到个性化的图表，难道又要让业务系统去安装Echarts依赖，然后以旧的模式写配置吗？所以，在公共图表项目内部也提供一个纯个性化配置的图表，也就是没有任何多余封装的组件，配置信息完全需要业务方写好，组件直接调用生成，不做任何处理。这样我们依旧不需要管理依赖，仍然也只是关心配置。

界面优化和约定

如何统一用什么样式的图表，这需要产品、设计和研发一起商量做好约定，这块是需要投入成本的

多图表库支持

上周在公司内部分享的时候，被问到可以支持多库吗。确实不排除后期需要多库的情况，或者某些图表库不支持我们想用的功能，因此在代码架构配置中做了处理，已经支持多三方图表库存在的情况，具体内容可以看github仓库。

 

Iframe方案可能会被吐槽的一些问题

• 阻塞父页面加载：由于单页面框架内使用Iframe大部分都是在框架本身生命周期中创建节点，所以并不会阻塞业务本身
• 安全问题：因为我们的图表项目是自己写的，并且是纯静态资源，没有接口的输入，也没有任何业务，因此没有任何攻击的价值
• 性能低下：因为在PC端这样的场景之下，Iframe本身会带来的性能问题是微不足道的，并且一个界面之中的图表大部分情况下是不会超过10个的，即便有10多个，也都并不会导致卡顿。配合上缓存策略，图表的加载实际也很快

 

代码展示

业务代码在使用组件时，只需要大致下面这些代码，不需要安装任何依赖

 

 

 

仓库演示

https://dashiren.cn/public-chart/dist/index.html

仓库地址

https://github.com/zimv/public_chart

 

结语

基于我们需要解决的问题，选择哪一种方案，其实都可以，只是刚好我偏向于Iframe。从发现问题到解决问题，从提出想法到实施落地，以上便是全部内容，希望能给大家带来一些启发，今天的分享就到这里。