泛谈一下uniapp以及我的想法
我一直认为文章的时效性是一个很重要的参数。我在看别人写的文章或者博客的时候，会特别注意文章的发布日期。当文章发布的日期超过1年的时候，我就会开始警惕文章的内容是否有效，时间越长越是如此（基础性的知识可以不受这个范围的约束）。
知识是不断更新的，旧有的已经被淘汰的知识本身的价值是很小的。在我们互联网的前端开发这个职业里面更是如此。所以这里我会给出文章发布的具体日期，给看这篇文章的人一个参考。
发布日期：2020/5/26
前言
这篇文章主要目的是分享我个人在探索uniapp期间的一些奇思妙想，整片文章的个人意见会相当主观，希望各位在看这篇文章之前先去看uniapp官方文档，以免先入为主。
官方文档并非同步更新的，我发现官方在部分地方会有遗漏，个人建议最好同步着当前的uni-app v3版本升级 这篇文章看，这样才是比较完整的内容。
v3编译器
正式上线正式版
v3编译器这是我认为uniapp近期最重要的部分，内容方面上面已经给出了链接。
Hbuilderx更新日志，2.5.1！v3版本编译器正式发布，v3编译器进入Hbuilderx的正式发布的时间是在2020年1月3日。官方对v3编译器的描述来看，各方面提升很大，同时有break change （破坏性更新）。
从这个时间点开始，新创建的项目是默认开启v3编译器的，如果这个时间段的新创建的项目你突然发现特别容易出bug，而v3编译器是最直接的原因。
早期
在刚刚发布v3版本的编译器的时候，此时大多数人还没有开始使用这个特性。从商业的角度来看，v3版本还存在很多问题，无法直接在实际的生产环境上使用，实际上从后面的几个月的时机表现来看，也的确是这样，出现了很多的问题；从生态的角度来看，从刚发布的v3的时候，市场上面的所有第三方插件都是不兼容v3的，旧有的第三方插件能不能使用完全看“运气”，这时候对于使用v3版本来开发的开发者来说，生态基本为0。就算是运气比较好，有能使用的插件，他们也没有使用v3特性，这也就意味着这种“旧”的东西它无法享受v3带来的好处，这时候你升级v3的这一行为基本是没有必要的。
什么时候算是一个好的时机呢？ 第一，我觉得首先得解决v3版本的稳定性，这个问题其实随着时间的推移慢慢已经解决了，大概在4月份左右就算是比较稳定了，稳定的标志就是在还算长的一段时间内没有推出更新；第二，我认为生态的问题也是可以靠时间来解决。但期望着第三方零散作者的力量不太稳定，同时v3的特性（break change）导致了，新的插件只要想享受v3带来的性能上的提升必然需要放弃兼容v3以前的版本。根据以上的特点，我认为生态转变的标志：有一定技术能力的技术团队，维护了一套组件完善的UI框架，且这个UI框架要求必须开启v3编译器。
大概在4月份的时候，新出现了一个UI框架——uview-ui，当时已经进入测试阶段，而这个框架就是专门针对v3的，在2020年04月11日正式发布。
其他老牌的UI框架，比如thorUI，据小道消息说也在酝酿v3的版本。
后期
App老版“自定义组件编译模式”将于4月的HBuilderX 2.7版本下线，这篇在2020/02/26发的文章，官方这个意思在我看来就是在说： 我们要强行推进生态。不过因为疫情的影响, 推迟到了5月19号。2.7.5版本正式下架了自定义组件编译模式。
这里不去评判官方的行为好坏，但这些行为让开发者认识到，官方是很看中这次v3版本编译器的。这种情况下，v3的普及速度会大大加快
UI框架
我说一下，我观察到的uniapp设计的基本思路： 在多端中，如果有一端不支持某个特性，那么为了追求多端的功能和表现上的统一，大多数时候官方会放弃这个特性。除非这个特性是必要或者是增强特性。（这个放弃的特性，在能使用的端里，实际上你仍然可以使用）
这里说一个我实际遇到的案例
图下是element-ui的checkbox多选组件
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jTRohkKC-1594302881520)(http://insectq.199604.com/img/image-20200525232644349.png)]
图下是uview-ui的checkbox多选组件
这两个组件的使用方法的差别就在于，element-ui能在check-box-group中直接v-model绑定数据，而uview-ui则是通过change事件去赋值，从使用上来看明显是element-ui的更方便。什么原因导致uniapp的组件选择这么封装？从实现原理上来说是provide/inject，这个特性uniapp是全端支持的。但其他的类似uini-ui和vant的官方也是这种不完善的做法，这些队伍都是拥有强大的技术团队的，所以我的基本想法是:这不是因为技术人员的能力问题，而是其他原因导致的。
后来当我实际在项目中使用uview-ui的checkbox组件的时候，我发现了问题，uview-ui的checkbox组件的数据更新是有问题的。我使用checkbox组件的场景比较复杂，当时的情况下，checkbox组件的选中状态莫名“被异步”到下一个事件循环。从而我理解了，插件市场中的各类插件甚至uni-ui在设计组件的时候会选择各种"不方便的做法"，因为看上去能做出来的”很便利“的特性是的确存在问题的，会表现在某个端就是无法实现，有异常。（我是在微信小程序中遇到问题的，其他端的情况暂时不得而知）
我从上面这经历中产生了一个想法：如果有人想要快速了解uniapp，希望有确切的方法论来了解uniapp的边界情况（即劣势或危险的场景），可以将传统web的技术栈作为参照物，从第三方框架和工具中，去寻找这些框架和工具的作者选择不去做的事情。
作用域插槽
我相信在vue中的各项接口的设计都是有其目的的，其中的scoped-slot也不例外。但作用域插槽这个特性在uniapp中并不支持
我认为作用域插槽的作用，主要在于有一类组件内部复杂的数据逻辑，而外部想要通过slot介入的使用，就需要scoped-slot来向外暴露内部数据，然后使用这些数据来完成功能。
我认为，复杂组件的拥有以下基本特性
- 高度封装
- 复杂的内部数据
- 复杂的内如逻辑
因为缺少作用域插槽，内部的数据无法暴露在外，因此如果一个严重依赖内部数据的组件：比如日历组件。缺少了这一关键技术点，使得这类的复杂的组件将会丧失大量关键功能。（实际上uniapp相关的日历组件的现状的确是这样的）
不同于上面的通过UI框架、工具来获得技术的边界情况，这次是从已知技术缺陷（边界情况）的角度来倒推测出组件的发展
最后
以功能最完善的web端作为参照物，观察其他类似技术栈的与传统web的区别，特别注意官方和框架开发选择不去做的的事情。
同样也可以从已知技术缺陷（边界情况）的角度来推测出组件生态的发展。
这两个方法能够一定程度上让开发者更快了解：uniapp什么能做和什么不能做
做的的事情**。
同样也可以从已知技术缺陷（边界情况）的角度来推测出组件生态的发展。
这两个方法能够一定程度上让开发者更快了解：uniapp什么能做和什么不能做