スキーム遠位共同市場チャートデータ

序文

多くの場合、フロントエンドのビジネス背景開発データチャートに、この高度な設定ライブラリに対する同様のEcharts、書き込みには通常あまり、ほとんどの場合、統計グラフの下の文書、プロジェクトのほんの一部を表示するために多くの時間を要しコンフィギュレーション、低繰り返し開発効率を忘れやすいです。大幅な設計パーソナライズされたチャートのプロダクトマネージャー（チャートを参照してください今日はかなり良いですなスタイルで、その後、あなた自身のビジネスにコピーしたかった）、チャートスタイルの同じタイプが異なる場合があり、彼らは再書き込みにコードを持っています。それは気持ちが常に低開発効率、製品設計の効率が低いことです提供します。

我々はデータチャートの様々な開発における通常のプロセスのフロントエンドを見て記事の冒頭で、それはEcharts例に経験したことがあります。

オープンecharts公式サイト
参照凡例を達成するように、コードは、必要なコピーの好適例の一例を見つける、実施例のインターフェースを見ます
オープンビジネスプロジェクトモジュールを介して、おそらくの導入（この場合にも依存WebPACKのは、いくつかの最適化問題を解決するために設定する必要があるかもしれません）、おそらくHTMLスクリプトを導入することで、依存関係をインストールする必要性を見つけ、コードをコピー
出会うの詳細およびUIまたはプロトタイプが一致しない場合、ドキュメントの設定を探し始める、といった：等の軸の色、スケールの色、内部のピッチ、リマインダ、テンプレートをコピーし、
第二グラフを行い、そして折れ線グラフを発見することは同様であるが、これは複数のポリラインより数字である場合、UIは、上記のいくつかの詳細に変更し、その後、手順4を繰り返し受けています。
しばらくして、別のビジネスプロジェクトは、再びデータチャートを行います。この時、前に行っていると思うし、その後、旧プロジェクト比較表を見つけ、同様のコードをコピーし、不一致の内容を変更するには、場所がステップに始まった4

あなたは、グラフを行う毎回ではないので、同じ繰り返しは、自身がより多くの、あなたは上のグラフに2本のコードまたは300のラインを作ることができる構成コードと一緒に、多くの時間を持って過ごし、4と5を数回繰り返します。経験豊富ないくつかのようにA、後でAPIに精通し、おそらく少し投げ、それでも良いたび、低開発の効率を感じます。その後、シェアは次のテキストを入力し、今日行われています。

スキーム

各業務アプリケーションのシナリオは、開発会社、バックグラウンドデータチャートをプロジェクトのために、2以上の効率を解決するために、私は、次の二つの方向によってプロセス思います。

抽象コードは、アプリケーションコードの量を減らす設定は、文書を再読み込み時間を過ごすためにすべての開発者を回避ばかに - 開発効率を向上させるため。
製品の設計効率を向上させる - パーソナライゼーション、インタフェースのチャートと対応するアセンブリコードを減らすある程度、統一チャートスタイルを使用します。

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

优点：

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

缺点：

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

实施

JS组件库

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

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

下图为此方案的示意图：

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

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

Iframe方案

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

新建代码库，安装echarts依赖
新建页面组件（比如一个折线图组件）
封装组件参数，回调方法等
打包输出为一个个静态资源页面，发布到静态资源服务器
写一个网页文档并在网页上展示实例
业务系统不需要安装任何依赖，通过Iframe配置url引入组件，通过postMessage发送配置和数据
如果代码需要升级或者修改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。从发现问题到解决问题，从提出想法到实施落地，以上便是全部内容，希望能给大家带来一些启发，今天的分享就到这里。