vue常用的第三方组件库,vue3.0打造企业级组件库

为什么vue的组件库结构都很复杂？

这跟vue没什么关系，这是业务本身就很复杂，换react，ag，jq来写，只要业务本身不变，就不会有什么本质的区别。

市面上目前已有各种各样的UI组件库，比如Element和iView，他们的强大毋庸置疑。

但是我们面临的情况是需求越来越复杂，当它们不能再满足我们需求的时候，这个时候就有必要开发一套属于自己团队的组件库了。

vue的组件库常用的解决方案：COPY：你可能会说我讲究速度，复制之前的组件到新项目中，慢慢的你会发现随着你的项目的增加代码量在成倍上升，重复工作浪费了你很多时间。

子模块：我可以抽离出所有公共的组件放入一个子模块（gitsubmodule）中，这种方式虽然解决了重复工作，但对目录结构以及使用者的要求比较多，不够灵活，还是不满意。

使用开源组件库：这可能是一个好的选择，但是，一用才发现很多并不是我们想要的，尤其是移动端组件库：C端产品定制化需求多。组件库风格与产品不符。适配方案不同rem/px/vw等。

针对以上痛点，写一个通用组件库是较优的方案。内容分为两部分。组件库的两个核心思想的实现：全局引用和按需引用。从使用者和开发者两个角度看问题。

谷歌人工智能写作项目：小发猫

vue3.0和2.0的区别是什么？

vue-cli2.0与3.0在目录结构方面，有明显的不同typescript类型注解教程，typescript 引用。vue-cli3.0移除了配置文件目录，config和build文件夹。

同时移除了static静态文件夹，新增了public文件夹，打开层级目录还会发现，移动到public中。

配置项，3.0config文件已经被移除，但是多了.env.production和env.development文件，除了文件位置，实际配置起来和2.0没什么不同。

没了config文件，跨域需要配置域名时，从挪到了中，配置方法不变。

Vue3.0不论是原生的html标签还是vue组件，他们都会通过h函数来判断，如果是原生html标签，在运行时直接通过VirtualDom来直接渲染，同样如果是组件会直接生成组件代码。

数据监听，Vue2.x大家都知道使用的是es5的object.defineproperties中getter和setter实现的，而vue3.0的版本，是基于Proxy进行监听的，其实基于proxy监听就是所谓的lazybydefault。

版权声明：本文为CSDN博主「水墨-青花」的原创文章，遵循CC4.0BY-SA版权协议，转载请附上原文出处链接及本声明。

如何评价饿了么开源的 Vue 组件库 Mint UI

1.设计用心。虽然是从自己的业务中提取的“基础组件”，但是开源过程中还是非常用心的做了拆分、取舍工作，使组件高扩展。2.使用方便。我们项目中是按需引用组件，哪里用哪里引。

虽然这些组件也可以自己写，但是小团队时间和精力都花在业务上，很难形成一套组件规范，毕竟Mint有文档…3.应该说我Vue大法好，没有它就没有组件库存在的意义，希望Vue生态越来越好。