在Vue2项目中使用ElementUI和Echarts

=Start=

缘由:

自己毕竟不是专门做前端/UI的,所以在页面布局以及样式上面没有那么专业,但爱美之心人皆有之,我也想做出一些好看的页面,用的时候感觉也会好些。这时,就需要借助一些UI框架以及图表工具了,对应的比较流行的就是ElementUI和Echarts了,这里简单介绍一下它们在Vue2的项目中该如何引入和使用,方便以后参考。

正文:

参考解答:
一、Vue2.0 项目中怎样添加 ElementUI 和 Echarts

方法一:直接在 package.json 文件里面的 dependencies 里配置

然后再执行 npm install 命令。

方法二:直接执行命令

二、Vue2.0 项目中如何使用 ElementUI 和 Echarts

2.1 elemnt-ui 只需在 main.js 里添加

2.2 对于用到 echarts 的页面,哪个页面用到就在哪个.vue文件中添加

补充:.vue 文件结构介绍

三、简单样例

ElementUI样例

Echarts样例

四、一些注意事项

需要注意的是:Echarts对应的DOM容器必须要指定宽高,否则Echarts无法渲染dom !!!

 

错误:
Uncaught TypeError: Cannot read property ‘getAttribute’ of null
参考:
这个错误的发生是因为当方法被调用的时候这个HTML元素的对象还没有加载进去,所以你需要把这个报错的方法用在DOM对象加载之后。

或则你把js文件的调用放在body的最后,就是俗称的网页底部,在确定对应的HTML元素被加载之后再运行。

在 Vue2.0 里面一般就是放在 mounted 里面,然后整个网页就恢复正常了。

错误:
Uncaught Error: series.type should be specified.
参考:
https://segmentfault.com/q/1010000012411869

错误:
Uncaught TypeError: Cannot read property ‘get’ of undefined
参考:
echart_obj.setOption(echart_obj_option);
即便是 空option 也需要先 setOption 之后再 setOption 其它的部分(当echarts的两个option存在不同的参数的时候),否则会报错。

 

参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/4004.html

《在Vue2项目中使用ElementUI和Echarts》上有12条评论

  1. 前后端分离开发风险浅析
    http://pirogue.org/2018/12/17/SPA/

    3. 越权漏洞的发生
    3.1 参数归属校验缺失
    3.2 直接请求后端接口
    3.3 前端框架引入的风险

    4. 解决方案
    4.1 前端后端一起鉴权,Node层校验登录态,后端校验登录态,同时后端校验数据归属;
    4.2 Vue-router使用“mode: history”模式,前后端一起配合鉴权。

    Vue-router 中hash模式和history模式的区别
    https://www.jb51.net/article/144341.htm

  2. 保护你的API(上)
    http://abruzzi.github.com/2016/05/about-session-and-security-api-1/

    在大部分时候,我们讨论API的设计时,会从功能的角度出发定义出完善的,易用的API。而很多时候,非功能需求如安全需求则会在很晚才加入考虑。而往往这部分会涉及很多额外的工作量,比如与外部的SSO集成,Token机制等等。

    这篇文章会以一个简单的例子,从应用程序和部署架构上分别讨论几种常见的模型。这篇文章是这个系列的第一篇,会讨论两个简单的主题:

    基于Session的用户认证
    基于Token的RESTful API(使用Spring Security)

    ==

    前后端分离之后
    前后端分离之后,在部署上通过一个反向代理就可以实现动静态分离,跨域问题的解决等。但是一旦引入鉴权,则又会产生新的问题。通常来说,鉴权是对于后台API/API背后的资源的保护,即未经授权的用户不能访问受保护资源。

    要实现这个功能有很多种方式,在应用程序之外设置完善的安全拦截器是最常见的方式。不过有点不够优雅的是,一些不太纯粹的、非功能性的代码和业务代码混在同一个代码库中。

    另一方面,各个业务系统都可能需要某种机制的鉴权,所以很多企业都会搭建SSO机制,即Single Sign-On。这样可以避免人们在多个系统创建不同账号,设置不同密码,不同的超时时间等等。如果SSO系统已经先于系统存在了很久,那么新开发的系统完全不需要自己再配置一套用户管理机制了(一般SSO只会完成鉴权中鉴别的部分,授权还是需要各个业务系统自行处理)。

    本文中,我们使用基础设施(反向代理)的一些配置,来完成保护未授权资源的目的。

    保护你的API(下)
    http://abruzzi.github.com/2016/05/about-session-and-security-api-2/

发表评论

电子邮件地址不会被公开。 必填项已用*标注