你是否把el-table的插槽写法，封装成“通过JSON”来配置的方式了？它们真的确实必要，并且确实更好用吗？

前端实际的开发中会面临各种页面需求，所以我们不可能永远套用那些限定的UI的模板，最近根据需求自己封装了一个日历组件。 效果图： 对于日历的实现我的逻辑是这样的： 1.首先我需要写的日历是总共展示7列*

对于中大型前端项目，项目规范与代码质量尤为重要。当功能需求变更或需要重构时，随心所欲的(糟糕的)代码可能带来比重新开发还麻烦的问题。 这个问题不用作过多阐述，想必接手过他人代码的同学，多少都有些体会。简单来说，太过随意的代码会让强迫症患者难以容忍，难以阅读理解的代码有时甚至不如…

项目当中如果做新增/修改/删除等等操作通常情况下都需要刷新数据或者刷新当前页面.如果页面简单,调用接口刷新数据即可.如果页面复杂,需要调用多个接口或者通知多个子组件做刷新,可以采用刷新当前页面的方式

element-ui 本身就提供了许多强大的组件。那么为什么还要进行二次封装呢？ 在日常的开发过程中，部分模块重复性比较强，这个时候就会产生大量重复的代码。这些模块的样式基本上是比较固定的，而且实现

上一篇写到用el-tree实现触发部门管理的默认点击事件，但是当我们的部门名称过长时候发现展示效果不尽人意，查看文档后只能自己间接来实现了，借助el-tooltip和el-tree的自定义内容，以下是

大家好，我是虚竹，前段时间忙着寻找大哥三弟，很少有技术文章输出，趁中途栖息时间赶紧补上一篇水文。今天给各位看官讲一讲我的刨坑之旅，因为最近开发了一个项目业务上遇到一个感觉有点啪啪的复杂需求

#columns表头必填项#ajaxConfig选填#Action:""//Action=>query执行查询选填#除了这3个参数，其他用法与el-tableapi完成一致,妈妈再也不用担心eleme

1.组件调用代码调用组件的数据2.组件封装3.样式修改