首先，对官方提供“默认集成、无需安装、不占包体积”这样的扩展方式表示100000个赞。这对有限包体积还要求快速启动的小程序来说无异于一种极大的便利。

然而，真正使用下来，略微失望。

官方的扩展从功能角度划分，两类。

Ui组件和框架类扩展/工具类。

UI类的扩展，恕我直言，略显鸡肋。

WEUI扩展，出发点很好：和微信ui保持一致，提供较为全面的常见组件，补充内置组件的不足。

然而，真有公司或个人使用WEUI组件么？追求精美的话，必然会自己设计ui；图省事简单的话，大把的全套ui可选择，如taro-ui、minui、colorUi等等。而且无论从组件的ui设计、组件的全面性、社区的生态来说，都比weUI好的多。

扩展ui组件方面，上面的帖子都提到了很多。兼容性问题、适用场景问题，不一而足。个人使用的感受：这些组件真的都进行过详尽的测试么？拍手叫好的帖子真的有深入使用过吗？emoji、recycle-view、tabs等等组件，基本上是看似美好，拿过来问题多多，改造的工作量和时间，真的不如重新写一个。

UI组件库，在我看来，不应该是这样零零散散，不成体系和生态；也不应该是非要贴近流行趋势，什么流行提供什么，譬如上面有提到提供异性tabbar、日历，互动场景，抽奖，截屏，上传头像裁剪，其他营销级别的组件，完完全全没有必要。毕竟UI是一个仁者见仁智者见智的东西，真提供了，你也会发现，和我要的不一样啊！

官方提供的ui框架，提供完备的定制、扩展接口才是ui组件的正确方向。纯靠官方提供的组件库，注定生命力不会太强。定制性强、扩展性强、社区生态化才是ui组件的可持续发展之路。

框架扩展/工具类组件是我非常支持的一类扩展。

小程序毕竟不是完全web环境，对于基于dom或者其他一些第三方库的兼容性或多或少会有一些问题。同时，小程序受限的包体积和无需下载、开箱即用的特性，决定了在开发过程中，我们对于第三方/扩展库的使用会比较慎重。

官方提供的一些库的扩展，譬如mobx-binding、lottie和threejs的小程序版本，很大程度上减少了开发者适配的工作量，然而这些工具类/框架扩展，除了kbone，没有一个进入微信内置库。而且，动作太慢....mobx的binding，自己改造的版本都用了很久，官方的版本才放出来；至于向官方建议的redux-binding官方版本，官方说评估，然后...然后就没有然后了。

如果官方能再提供或者引入一些常见js库的内置集成，譬如lodash、moment、redux的小程序binding等（当然这些是需要慎重考虑的，毕竟微信内置支持牵涉多多），那岂不美哉？

kbone只是稍作了尝试，并未深入使用。惭愧，官方力推的框架，还是需要深一步的了解和使用。

最后，请加强扩展组件的稳定性和可用性测试，完善文档和demo。

最后，请扩展组件支持分包。

最后，轮子不是造出来就行了的，是需要持续维护和优化的。

出个 table 吧，真的很需要这个。自己作为自定义组件的方式封装过 table ，如果官方能出一个就好了。

日期-时间选择器 也很需要，现在要选一个日期加时间的效果要么分为日期选择器+时间选择器。要么用多列选择器或picker-view自己做数组实现，都不是特别方便，如果官方能出一个就太好了。

时间范围选择器 开发中经常有需要选择时间范围的组件，只能用picker-view自己封装，如果能带快捷选择就更好了。

使用过sticky, 发现还是有些小问题， - -最后直接postions: sticky，虽然有点兼容性问题，不过大多数都支持了。

wxml-to-canvas跑了下demo，还是有一些效果无法实现，现在只支持简单的 view、text、image 三种标签。建议把扩展组件放到weui里面去。不用单独引扩展。

希望支持一些动画类型的扩展吧，比如类似于lottie.js的这种。

再支持下官方版的自定义导航栏、table表格组件、头像裁剪组件、日历、circle环形进度条等扩展组件就舒服了。

最后再求个截屏api。截全屏或者一部分。😁

至于营销组件 大转盘、老虎机、九宫格这种应该是不会支持了吧。

出个重力感应图片移动的组件吧，自己写一堆的代码效果还不好

我自己写了个tabs和emoji组件，等我写完了发现官方也做了个，害！

官方的这个tabs，个人感觉封装的不合理，swiper不应该封装在里面，单独提供一个子组件会比较好一点

其实吧，你们都误会官方了  官方提供这些扩展组件 只是给你们提供思路，并不是让你们拿来直接用的

weui相比较其他的小程序ui框架，感觉要精简不少。很多实际开发会用到的组件，比方说商品列表，要么自己开发，要么使用其他框架。

以Vant UI为例，提供了van-card组件，文档如下：

https://youzan.github.io/vant-weapp/#/card#dai-ma-yan-shi

使用这个组件，可以轻松做出商品列表，无论是电商还是外卖小程序，开发都很方便。

通过这个例子，我发现每个小程序是有实际业务场景的，但大体都可以分为电商、社交等大类，如果weui可以在基础UI库上进行拓展，也许可以进一步降低开发门槛，提高效率。

经常做微信开发的朋友都知道，微信有一套完善的规则体系，在遵守微信开发规范的前提下，才能够顺利的通过审核，优质的小程序有机会获得官方渠道的推荐。但优质的小程序，毕竟还是不多的。很多技术团队没有很规范的开发流程，也没有很多专业的设计师和产品经理，小程序开发更多的是摸着石头过河，不断的踩坑填坑。

如果weui可以做为一个好的标杆，在开发者不知道应该如何在合适的业务场景选择组件，或者是不明白用户操作用什么交互方式好，那么按照这个参照来，即便在界面上看起来不算出彩，但可以规避很多问题，也能逐渐体会到weui设计思想的精髓。

一直在使用微信小程序的扩展组件库，包括之前的WeUI，和tabs组件，已经现在正在学习的Kbone和KboneUI，最欣慰和开心的是，作为一名开发者，碰到问题时在开放社区上提问，无论是开发或是运营的，很快都有官方的同学和热心的网友回复，满满的正能量。在使用的过程中，确实是有不少体验，正好这次有下面这个话题，还有纪念品拿，赶紧来参加了。

你希望官方新增支持什么样的扩展组件能力？对于扩展组件/WeUI有什么需求或建议呢？

1）WeUI

1、最大的需求是希望组件库更加丰富，目前库里的组件还是太少，很多场景都必须自己改写WeUI组件或者引入类似vant-weapp这样的第三方组件库才能实现效果。比如顶部的tabss这样的基础组件，还有像卡片试图、评分、步进器、开关、下拉菜单、步骤条等常用特色组件。

2、希望还能针对一些特定的应用场景推出一些扩展组件/WeUI组件，例如电商类、资讯类等，减少重复造轮子的时间。

2）富文本处理组件

希望有官方增加对富文本的处理组件，目前原生的rich-text是没有对属性参数nodes中的富文本进行处理的，比如清除无效的标签、样式、统一适合移动端的样式等。

后面的想到再补充啦，希望多一些这样的官方话题活动

图片打包插件

希望官方可以出一个插件可以将所有大于指定大小存储的图片哈希处理后打包到一个文件夹下，这样我就可以将这个文件夹一股脑放到腾讯云COS上。

就是类似 webpack 里 file-loader 和 url-loader 的作用。