echarts3中使用字符云报错_从echarts2升级到echarts3需要做什么修改

还没有统一的说明文档，这里简单列一下，如果有问题可以在这个 issue 下继续说明

1. 引入方式简化

2 中打包的文件内置了 esl 模块加载器，所以引入 echarts 就强制引入了一个 AMD 的环境，3 中对这点做了改进，打包文件是 UMD 规范的，可以 requirejs 引入，或者直接标签式引入，如果是 npm 安装的话也可以直接用 CommonJS 的方式 require 引入，具体可见 5 分钟上手 ECharts 和 在 webpack 中使用 ECharts

3 中构建好的文件也不再支持按需加载，因为像 2 那样尽管是按需加载，但是因为很多共用模块不得不放在 echarts.js 文件中，所以导致必须要加载的 echarts.js 文件很大(400k)，而每个图表的文件又只有10几k，失去了按需加载的意义。所以 3 改为按需构建，可以在线构建，也可以通过 npm 安装，按需引入后用 webpack 构建。因为 3 的模块化更细粒度，所以最小需求的饼图可以做到构建出来只有 170k 左右。

2. 接口简化

首先是把数据驱动和声明式接口做得更加彻底了，所有数据项的改动和配置项的改动都统一使用 setOption 方法，有需要的话可以在这个方法基础上二次封装(比如定时更新数据的封装)，不再有 addData，setSeries等方法

其次是监听事件的简化，事件名称不再像 2一样需要引入 config 模块，而是都改成像 dom 事件一样的字符串，具体见 events 文档，需要注意的是，legend，地图等的选中事件名称都从 legendselected, mapselected 改为了 legendselectedchanged, mapselectedchanged，如下示例：

myChart.on('legendselectchanged', function () {} );

然后是不再像 2 那样通过组件暴露接口去实现程序实现数据区域选择等功能，而统一改为 dispatchAction 的方式，例如：

myChart.dispatchAction({

type: 'dataZoom',

start: 10,

end: 20

});

这种方式可以使得所有行为的管理更加统一，而且不用暴露内部的代码组织。

可以参见文档 action

3. 地图数据不再内置

3 中对于地图数据精度提升了很多，地图体积也大了很多，再内置就不合适了，所以 3 中把所以地图数据外置了，但是对地图引入方式进行了大大的简化。可以直接引入一个地图的 js 文件，也可以引入地图的 json 文件后通过 registerMap 方法注册地图。

4. 配置项结构的改动

我们在 3 中尽力做到跟 2 配置项兼容，特别是折，柱，饼，散点，仪表盘，漏斗图等基础图表，有些配置项层级的改动，比如 label，areaStyle 等原先在 itemStyle 层级下的都移到了 series 层级下跟 itemStyle 同级，例如：

{

label: { normal: { show: true } }

itemStyle: { normal: {} }

}

这些小改动有许多，这里不一一列举了，当然这些改动都会做到向后兼容，原先的写法也依然能用，只是不再推荐。

5. 地图和关系图的改动

地图不再使用 markPoint 和 markLine 去画点和线的数据了，markPoint 和 markLine 的定位就是辅助标记，在 3 中有特定的 lines 类型绘制特定的线数据，点数据也可以使用地理坐标系上的散点图实现，见示例 全国主要城市空气质量

还有关系图绘制也是改动很大的一个地方，2 中的 force 图在 3 中不复存在，取而代之的是更加通用的 graph，在 graph 中可以应用更多的布局方法，除了 2 中的 force-directed 布局，也可以是环形布局，也可以预先布局好后存放到 x，y 属性中直接展现，也可以自己扩展布局，比如这个 echarts-dagre 扩展

6. 去掉了拖拽重计算，树图，和弦图，字符云，韦恩图

树图，字符云和韦恩图这三个图我们觉得在 2 中很不成熟，3 中对其优化改进前先暂时不支持，拖拽重计算我们觉得使用的人并不多，又会增加不少代码体积，所以也先去掉了，不排除后面会通过扩展的方式加入。

然后关于 3 的新特性，可以见文章 echarts 3 带来了什么，实际上这篇文章发布以来后的各个新版本我们又陆续加入了很多新特性。感兴趣的话可以看示例 和各个版本的 changelog