扩展组件库是对小程序内置组件能力的补充，如使用 Tabs 或 vtabs 组件可以快速创建横向/纵向选项卡、使用 wxml-to-canvas 组件可以通过静态模板和样式绘制 canvas 导出图片用于生成分享图等场景、使用 emoji 组件可以快速引入类似微信表情的能力。而像WeUI组件库更可以支持高效构建同微信原生视觉体验一致的UI，令用户的使用感知更加统一。
平常开发小程序的过程中，你有使用小程序扩展组件吗？你希望官方新增支持什么样的扩展组件能力？对于扩展组件/WeUI有什么需求或建议呢？
参与本话题优秀回答者将获得微信正版周边礼品一份，快来参加吧！
*图片仅供参考，实际奖品选择与发放将视官方周边更新与存货情况进行适当调整
*获奖情况将在后续「社区每周」公告中进行公示长
首先，对官方提供“默认集成、无需安装、不占包体积”这样的扩展方式表示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不应该封装在里面，单独提供一个子组件会比较好一点
其实吧，你们都误会官方了 官方提供这些扩展组件 只是给你们提供思路，并不是让你们拿来直接用的
这个我用过不少。一个一个来说：
这个使用过一次，本来准备用在项目的聊天功能上的。如下图：
但是非常遗憾，那天测试的时候发现扩展组件emoji里面的表情图全部失效了。所以我自己弄了个emoji功能。
这个也是用过，就是在一个带直播功能的项目里面用过，当时直播组件是1.0.2的时候，没有自带回放功能，所以采用的是后端调用获取回放文件接口功能，这个接口返回的是一大堆的短视频文件，在项目需求重直播，轻回放的情况下，我使用了video-swiper来自动拼接播放回放视频。这个组件也是有个问题，播放视频列表要3的倍数的时候才正常。否则最后的3取余后的视频不播放。还有一个问题是居然默认是从第二个视频开始播放（从数组里面下标为1开始播放，0直接忽略）为修复这2个BUG也是折腾了不少时间。
这个我也是用过，在项目里也跑过一段时间，因为一个大概2000多条记录的长列表，发现用scroll-view下拉刷新到700多条的时候直接白屏所以开始使用长列表组件。这个组件BUG比较少，一定要注意的是要控制好每个item的height，跟真实显示的height要一致，否则会有闪动的情况。这个组件的说明比较详细，有坑的地方都在文档里tip里写得很清楚。但是就算这样，社区私聊我讨论这个组件的问题的人还是不少，社区搜索一下还是有很多人使用过程中碰到问题无法解决。（这里要说下，有很多时候，其实问题不在官方组件的问题。包括扩展组件在内的官方组件功能在没有被深挖情况下而被开发人员嫌弃不好用）
没用过。
没用过。
没用过。
用过，用在城市选择上。后面因为界面UI要求实现一些特殊的效果，最后换成自己写的一个。
没用过。
没用过，打算用。
用过，后面因为项目需求画图是动态的，而且模板需要随时更新，时效性要求高，不适合前端canvas图，改到后端画图。这个没啥说的，挺好用的。就是支持的标签不多。很多时候要二次画图。
另外WeUI有个项目一直在用。这个跟微信可以保持一致风格，使用简单，问题比较少。另外其他的功能性的扩展组件目前都还没怎么用过，但是看了下，需求是有的，只不过是用其他方式代替实现。
需求和建议：
需求：
主流的，高频的组件的对开发和产品来说实用性非常高。所以我的需求就是官方组件库能一直跟随最新的流行前沿的前端技术而更新。比如有段时间流行的瀑布流效果。
另外说点题外的话：老实说上面列出来的这些扩展组件都是非常实用的。这里推荐大家一定有空要多关注官方扩展组件库，没事就来刷新一下，官方提供的新的扩展组件库一般都不会发布公告告诉你的，即时发了公告你也不一定会看到，所以应该主动的没事就关注官方的官方组件库，很多可能你暂时用不到，但是下个项目中你就会用到了，到时可以直接用官方造好的轮子，站在巨人的肩膀上写代码不亦乐乎！
建议：
1、扩展组件的文档和组件演示demo，代码片段能尽善尽美。现在的组件有的有代码片段演示，有的有demo代码，有的就是文档介绍。有的貌似文档还不全。希望tip多写些，能想到的可能出现的注意事项都写下来。这个确实很枯燥（此处必须有感恩~），但是你的枯燥换来大量开发老铁的安逸，我们很感谢的。
2、扩展组件的稳定性和兼容性能再加强下。
3、持续更新主流实用组件。能不停的造轮子，也不停的维护现有的轮子。定期给轮子保养换换机油什么的是必须要做的功课
4、扩展组件最好支持原生安装（类型直接代码片段里复制组件源文件方式，有源文件可以自定义优化和完善，这个很有必要）和npm/直接插件包（默认集成不占空间）方式
5、比较高频的需求扩展组件个人整理了下：自定义tabBar，中间带异性凸起的，转盘抽奖，带色块颜色的选择器picker，个性化的时间/日期/时间（日期）区间选择器。（其他的希望大伙跟帖补充）
最后说一句扩展组件这个确实很实用。必须感恩！
PS：以上仅代表个人已经，接受各种反驳和讨论交流。另外这里只说扩展组件哈，功能扩展和第三方框架什么的就不说了，坑太多，玩玩可以，参考学习里面的代码思维和逻辑还是很有价值的，用在项目还是算了。如果框架能一直随着官方的新特性去一直更新维护还可以试着用在项目上，如果像wepy这样的，冲着支持多端去的，然后用着用着突然发现就不再维护的框架还是算了（我现在还有个项目是wepy1.72的，维护这个项目我知道用第三方框架的苦和累）
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 的作用。