echart在前端数据可视化中有丰富的使用方式，但是其也有一般通用的实践方式。经过多个项目，现将个人echart使用的经验总结如下：
尽量将每一个echart可视化单独拆分为一个组件
从代码习惯上来说，将不同的echart可视化拆分为组件是一个良好习惯。
下面是一个例子，我们有频道偏好和内容产地偏好两个页面模块，其中频道偏好中有一个可视化区域，内容产地偏好有电视剧、电影、少儿、综艺四个区域
在代码层面，通过下面组件结构实现
频道偏好一个组件，内容产地偏好有1个父组件和4个子组件，父组件代码如下：
将组件拆解到具体可视化的好处是：
- 可以将需求业务逻辑拆分地更为清晰，强化组件逻辑即为业务逻辑
- 降低代码耦合度，减少代码功能依赖
- 便于后期需求变化和迭代，代码易于维护
很多小伙伴可能觉得增加组件层级麻烦，将所有功能写入一个组件中，这样其实不利于功能开发。将组件按照可视区域细分能够强化需求的理解和实现，这样任何时候一看到代码层级，都是和页面业务逻辑是统一的，一目了然。
组件细分的概念其实并不局限于echart功能，在任何功能实现中都应该秉持这一理念。将功能按组件细分，这样直观的一个好处是可以减少任何一个组件的代码行数。笔者在项目中深知组件没有细化的痛苦，维护前人上千甚至几千行代码的组件，每次看到都很崩溃。有的甚至变量，属性值，接口返回等都在同一组件中倒处使用，而同样字段的使用方式根据页面呈现有时候又各不一样。将组件分离，只要花少许精力将这些共用的值包装好，仅在父子或同级组件中进行传递，这样代码功能逻辑清晰很多。做好这件事往往是工欲善其事，必先利其器，如我上图中示例中的crowdDetailInfo这个对象，这是在不同组件中传递的统一数据对象，我只需要传递它，不同组件各取所需拿其中的属性就好了。
做好组件细分，后期迭代和维护也变得简单，对于上面的例子，可能有的同学觉得内容产地偏好功能都写在一个组件中，甚至echart配置都用一个，会减少代码文件。但是经验来说，尽量前端的封装和共用要做到适可而止，谁知道需求方当前说的所有可视化都一样，未来是否会分开不同逻辑展示呢？需求变化嘛，经常和预想不一样，你们懂的>_< 这样分开配置，比起统一封装我觉得会更灵活而敏捷。（未完待续）