发布自己的npm包到全局仓库
去npm官网注册一个账号
传送门: https://www.npmjs.com/signup
本地登录账号
|
|
恭喜,登录成功。
初始化
|
|
输入完npm init之后,跟着填写项目信息就可以了。
生成的package.json
接下来就是愉快的码代码时间….
发布
|
|
永远年轻,永远热泪盈眶
传送门: https://www.npmjs.com/signup
|
|
恭喜,登录成功。
|
|
输入完npm init之后,跟着填写项目信息就可以了。
生成的package.json
接下来就是愉快的码代码时间….
|
|
代码写法代表组件类型:
所以我们新增一个组件的时候,可以从组件是否含有内部状态、是否有交互等几个方面来将其归入组件或控件,并以此来确认其相应的代码规范。
延伸来说,除了基础的组件与控件的分别之外,我们还推荐大家从业务的角度出发再划分出一种组件类型,叫做容器。
卡片本身应当是一个纯渲染组件,但在我们代入具体的业务场景后就会发现,卡片本身其实是有状态的,最常见的如数据加载中、数据为空、数据错误等。这样一个无交互但含有自身状态的组件无论归于上述的哪个分类都会让人感到奇怪,所以我们又引入了容器这样一个新的分类,专门用来存放卡片这类组件。
编写组件库本身并不是我们的最终目的,让更多的人在业务开发中使用起来才是,所以一个组件库的文档是否足够清晰、完善,也是决定一个组件库成败的关键。
什么样的文档是好的?我想它起码应该达到以下两个要求:
属性全覆盖的重要性在这里就不赘述了,因为使用者在不阅读源码的前提下想要了解组件的所有功能,除了阅读组件文档外就没有其他的方法了,大部分的组件库也都可以做到这一点,但示例丰富,就是体现组件库开发者良心之处的地方了。
外层的div没有意义
改正
举个例子,card组件可以选择sm/md/lg三种大小
子组件props里设置了size、 data里设置了size_: ‘sm’
在组件created钩子函数里使this.size_ = this.size
调用el-dialog实例的open和close方法要用到ref属性拿到实例
|
|
el-dialog组件不能嵌套
el-dialog封装的一些Attributes值类型为Boolean时参数前面要加上:
在template里用到的图片地址如果放到script标签里要用require()包起来
在webpack.base.conf.js的entry配置里加上babel-polyfill