echarts从放弃到入门(1)

2018-07-04  本文已影响67人  糖砂西红柿

序言

本文纯粹个人手打,除了参考echarts文档外无参考任何资料,请尊重开源文化,如果恰巧你想转载这篇幼稚的文章请注明出处。

首先呢,还是要感谢echarts给我们提供一个这么棒的开源图表库(认真脸)。
本教程意在帮助大伙去阅读echarts 的文档,而不是去讲解echarts 的API,echarts里面那么多API如果再摘出来讲一讲就显得略low了。echarts的文档看起来费劲的主要原因不是因为文档不够齐全,而是文档的条理性不够强(其实也是必然,说的东西多了,条理性必然下降),所以关于这篇教程,你认真阅读后大概会有这样一种体验---能快速定位问题出在哪里,去查哪个大类的API,而并不知道具体api的实现。

其次我们需要思考一个问题


美人鱼.jpg

我每每在使用echarts的时候都会思考这个问题。


滑稽.jpg
  如果将echarts的功能比作美人鱼的上半身(人身),那么echarts的文档就可以比作美人鱼的下半身(鱼身),这样想大伙可能就会理解作为一个使用echarts前端民工的辛酸了。
  希望这篇文章可以帮助大伙快速熟悉echarts的套路,在升职加薪的道路上再添浓墨重彩的一笔(小伙子,你的想法很天真啊)。
生活起落表情包.jpg
哔哔了这么久(内心活动:要是把'哔哔'换成'前戏'会不会更加吸引眼球呢,幸亏大家看不到我的心理活动,要不然我苦心经营的光辉形象就轰然倒塌了),也该进入正题了。

总体来说开发的时候也是遵循28定则的,所以本篇教程只介绍开发中最有可能的情况,大概会占到echarts内容的15%,但是胜任日常的开发也是足够的,高端玩法就需要大家自己去看文档了,不过话说回来,有基础的时候看那些高级玩法,说到底也就只是API的事了。

文档入口.png

首先强烈推荐大家先把5分钟上手Echarts和个性化图标样式看上2遍以上

5分钟上手系列的重要性就不言而喻了。我们主要是看'个性化图标样式'这个选项中的内容。

个性化样式.png
  这句话大伙需要特殊注意,我在初尝echarts的时候,就是没有注意到这句话,在一开始总有种难以下咽的感觉。我这里先说一句,一定要谨记这句话,千万不要钻牛角尖。因为当你打开一个稍微复杂一点案例的时候,你就会被各种诡异的写法所震撼。大伙不要怀疑自己是不是学的假的echarts,大伙要知道我们看的是echarts4的文档,但是很多种你从未看过的实现方式是出自echarts2的文档,比如给一个系列中的单个柱状图换颜色,如果你翻遍echarts4的文档一定是找不到的,所以碰到这种情况,大伙尽量不要在生产环境的echarts4代码中,写入echarts2的文档内容,鬼知道什么时候就不支持了!
在'Echarts样式简介'中,下面这句话也比较重要
图片.png
大伙在看echarts文档API的时候,一定会碰到一个又一个的 itemStyle, lineStyle, areaStyle, label,这些一模一样的属性,时长会对我们阅读文档的时候造成困扰,但是等你慢慢接受了echarts的这种风格的时候,你就可以较为快速的写出想要的风格。
但是我还是想吐槽一句,这种写法对刚开始阅读文档的人真的不友好啊!_因为在这种设计模式下,会充实着不同的代码完成相同的事情,但是相同的代码却完成了不同的事情这两种情况_。为了一点点写法的优化,放弃了一点点代码的可读性,真的...真的...也是仁者见仁智者见智了!
多种方式如直接引入或是webpack打包,安装ecahrts这种问题,我就不做介绍了
API选项介绍
图片.png

  首先是这部分API,在日常开发中这部分是API我们用到的相对较少,注意点是直接引入后echarts需要调用init方法传入DOM才能正常的使用相关功能。所有图表相关的行为和事件都是在这部分进行配置的(比如多表联动,图表事件等)。这部分内容我们会放到'echarts从放弃到入门(2)'中讲解。

'配置项'介绍
图片.png
这部分是echarts中最杂,但是却是最简单的一部分。
我们需要养成这样一种思维,不光是在看echarts的文档时候,再看任意一个文档的时候都应该有这样一种思维:
定位问题 ----1---->回想解决问题的文档大类(需要详细记忆)----2---->根据解决问题得大类找到具体的解决方案(无需详细记忆)
在阅读echarts文档的时候,这点尤为重要。下来我就试图帮助大家建立这种思维。
图片.png
一个最最简单的图表结构就是上面的情况,所以当产品经理或是美工过来跟我们改需求的时候我们我们脑子里的思路应该是这样的:
首先知道需要修改的地方在哪里,其次是需要知道修改问题的API大类是什么,其次就是找到解决问题得方案了。
这里我们以修改图表标题的位置为例。首先我们需要知道修改标题的具体什么内容。
然后我们并不需要想起标题位置怎么修改,第一个反应应该是修改位置应该在图表的'配置项'中去寻找
图片.png

第二个反应应该是在这么多的配置项中,哪一个是修改标题的(注意这里并不是要大伙去想,哪一个API是修改标题位置的!因为根据echarts的套路,修改标题位置的API必然在标题的配置项大类中,我们需要做的应该只是知道哪个大类是用来配置修改标题的。)这一步就必须详细记忆了,根据不同的业务逻辑,我们记忆的主要方向可能是不尽相同的。再次强调一下,这一步必须详细记忆,否则面对echarts文档你会感觉到异常茫然的!回到例子中,我们需要修改的标题所以根据我们的记忆,知道标题大类就是echarts配置项中的title属性。

图片.png
找到title大类后,我们就需要仔细去阅读文档了,通过阅读我们能够得知,title属性所对应的配置对象中left,right,top,bottom是用来控制标题位置的。至此,我们就能愉(fen)快(nu)的完成需求的更改了。
相信读到这里,大伙就能大体清晰通过echarts愉(fen)快(nu)的解决变更需求的套路了。
其实我最最想说的就是这样一种核心套路。
具体的问题与配置项大类之间的映射关系

此处我还需要特殊说明下,在绘制echarts图表的时候,大体上能分出两个容器,最外层的容器就是整个被echarts初始化成canvas的那个大容器,这个容器一般大小是不会改变的,日常开发中我们改变的通常都是图表本身的大小而不是外层容器的大小。所以这一个配置项中改变图标大小并不会造成文档流紊乱(说人话就是,大容器内爱咋咋地不会影响到大容器外的排布)。

上一篇下一篇

猜你喜欢

热点阅读