前端常常会在的业务中后台开发数据统计图表，对于类似Echarts这种配置性极强的库，需要花费很多时间查看文档， 一个项目中统计图表大多情况下只占少部分，平时写的不多容易忘记配置，重复开发的效率低。产品经理对于图表的设计个性化明显（今天看到一种样式的图表觉得也挺好，然后就想照搬到自己业务之中），同类型的图表可能样式不一，代码又得重新写。总归给人的感受就是开发效率低，产品设计效率低。
在文章的开始我们先来看看一个前端平常在开发各种数据图表时，可能经历的过程，以Echarts为例：
因为每次做的图表不一样重复步骤4、5几次以后，耗费的时间已经很多了，加上配置代码本身就比较多，2、3个图表就能让代码上一百行。经历过几次这样的折腾以后，可能稍微熟悉了一下API，但是仍然会觉得每次开发的效率好低。于是就有了今天所做的分享，下面进入正文。
简单来说，就是封装公共图表组件供团队使用，约定统一图表样式，提供可视化界面文档
目的和方向已经明确，我们可能会第一时间想到，那肯定就是基于三方图表库做一次组件封装，通过npm安装依赖，最后再写好文档就行了。现在称它为JS组件库方案，那我们来考虑考虑此方案组件库的一个实现和使用流程，以Echarts为例
下图为此方案的示意图：
下图为此方案的示意图：
下面我们来对比一下两个方案：
Iframe有个比较需要特别谨慎的地方就在于其稳定性上的问题，由于所有业务系统的图表都指向到公共图表项目，都需要对其进行访问，如果出现了问题，那影响是很大的。由于业务系统是分散的，我们在发布新的公共图表项目版本的时候，需要进行一轮测试，测试新版本，首先需要满足的是不影响已有业务系统。于是，针对这两个问题，我们一方面需要严格保障公共图表项目的代码质量，在代码合并权限控制和人为review上需要格外重视；一方面可以同样通过Iframe的方式，在公共图表的文档网站页面加入一个页面菜单、嵌入所有中后台业务系统的相关页面。由于我们中后台统一接入了公司内部开发的sso权限登录系统，因此可以根据当前的登录用户和他的权限，看到他所能够看到的业务系统的图表统计相关的页面。那我们给一个测试用户配置所有业务的权限，就能通过公共图表系统本身查看到所有业务相关界面，以此来做测试验收。
也因为如此，公共图表项目本身不仅提供了页面组件给业务中后台系统使用，也同时集合了所有业务系统的数据统计界面，变成了一个真正的数据大盘。到此我们的方案就是一个完整的公共图表数据大盘。
在静态资源大小方面，每一个html组件，只引入了一个三方图表库和组件本身的一小段js代码，并没有引入任何框架，尽可能的减少文件大小。
首先做封装是有成本的，并不是一开始我们就写好所有的组件库，而更多应该是在开发需要某一种图表时，再考虑进行封装，封装的同时不仅要考虑当前版本使用，也要尽量考虑通用性和后期其他项目使用的情况
当然很多情况下 需要个性化配置我们的图表，既然当前已经有了公共系统，如果遇到个性化的图表，难道又要让业务系统去安装Echarts依赖，然后以旧的模式写配置吗？所以，在公共图表项目内部也提供一个纯个性化配置的图表，也就是没有任何多余封装的组件，配置信息完全需要业务方写好，组件直接调用生成，不做任何处理。这样我们依旧不需要管理依赖，仍然也只是关心配置。
如何统一用什么样式的图表，这需要产品、设计和研发一起商量做好约定，这块是需要投入成本的
上周在公司内部分享的时候，被问到可以支持多库吗。确实不排除后期需要多库的情况，或者某些图表库不支持我们想用的功能，因此在代码架构配置中做了处理，已经支持多三方图表库存在的情况，具体内容可以看github仓库。
业务代码在使用组件时，只需要大致下面这些代码，不需要安装任何依赖
https://dashiren.cn/public-chart/dist/index.html
https://github.com/zimv/public_chart
基于我们需要解决的问题，选择哪一种方案，其实都可以，只是刚好我偏向于Iframe。从发现问题到解决问题，从提出想法到实施落地，以上便是全部内容，希望能给大家带来一些启发，今天的分享就到这里。
原文：https://www.cnblogs.com/1wen/p/12258884.html