<view class="fixed_dialog_wrap" catchtouchmove="catchtouchmove" style="z-index:{{zIndex}}" wx:if="{{_visible}}" > <view class="dialog_wrap"> <view class="mask" style="background-color:{{maskBackgroundColor}};" catchtap="{{maskClosable?'onClose':''}}" ></view> <view class="dialog {{bottom?'bottom':''}}" style="{{style}};" > <slot></slot> <text style="display: none;"></text> </view> </view> </view> observers: { visible (new_val) { const _that = this const { bottom, maskVisible } = _that.data const style_visible = bottom ? 'transform:translateY(0)' : 'opacity:1;transform:scale(1);' const style_unvisible = bottom ? 'transform:translateY(120%)' : 'opacity:0;transform:scale(0);' clearTimeout(_that.data.timer_close) if (new_val) { _that.setData({ _visible: true }, () => { _that.setData({ maskBackgroundColor: maskVisible ? 'rgba(0,0,0,0.6)' : 'transparent', style: style_visible }) }) } else { _that.setData({ maskBackgroundColor: 'rgba(0,0,0,0)', style: style_unvisible }) const timer_close = setTimeout(() => { _that.setData({ _visible: false }) }, 300) _that.setData({ timer_close }) } } } 问题：slot 有兄弟节点，有动画；slot 无兄弟节点，大概率触发不了动画。 注意 slot下的 <text style="display: none;"></text> 。在编写该弹层组件时，如果 slot 同级没有兄弟节点，当蒙层展示时，节点挂载顺序如下： .dialog 先挂载 => 开始动画 => slot 内容填充，注意由于 .dialog 挂载时其没有子节点，于是动画的作用对象为空，所以动画开始了个寂寞。 而 slot 内容填充之后，动画已经在这之前开始加载了，所以此时，无动画，进而表现为，slot 在没有兄弟节点的情况下 .dialog 的动画及其难以触发（还是会有极小概率触发，猜测是因为小程序渲染层节点挂载规与逻辑层JS执行顺序导致）。 如果 slot 同级有兄弟节点，兄弟节点就会让 .dialog 有了动画作用对象，不至于开始个寂寞。 请问小程序官方，这算是bug吗，单独就这个问题而言。（不要跟我说用小程序的animation来实现动画，实现了会没办法将小程序组件转化为Vue组件）

习惯了react hooks的开发模式，对于逻辑封装有了一定的癖好，所以很难去接受现在的原生小程序开发模式了。 Page：不支持Behavior，想要混入，得在生命周期中通过this来注入逻辑，太low！ Component：通过Behavior混入一堆不知名变量和函数，当项目复杂到一定程度，然后引入多个的Behavior时，那代码，简直没法看。 我看到已经有人做出了基于Proxy的原生小程序 Composition方案，但是还是不够优雅，为了逻辑复用而制造了很多复杂度高的东西，舍弃了以前的那种基于生命周期的逻辑分离的范式，反正也不是理想的状态。 稍微理想点的就是React Hooks，基于函数的Composition方案，简洁实用很多。

有相关想法的同学可以接着说...

前端工具链发展到现在，从当初的各自为战到如今开放生态下的百花齐放，我们已经经历了许多，不过小程序好像在走IE的老路，理由如下： ·内核陈旧（在一些新特性的实现上，没有跟上webkit的步伐，导致一些功能受到限制，比如CSS3的backdrop-filter属性） ·工具链落后（小程序的基础设施已远远落后于业界） 这两点很关键，前者涉及用户体验，后者涉及开发体验，对于小程序的未来发展有很大的影响。我有如下建议： ·更新小程序内核版本 ·开发者工具支持hot reload ·优化小程序运行时，支持全局组件以及原生支持的数据中心功能 ·开放工具链，对接业界生态，或者自建插件体系（like Umi），支持让开发者写插件来优化构建流程提升开发体验，或是可以直接使用babel或者webpack插件 最后就是关于架构方面的，建议小程序团队开发一个cli，规定一下小程序开发架构，并做一些优化，比如路径alias...

- 当前 Bug 的表现（可附上截图） [图片] - 预期表现 如上图 - 复现路径 如上图 - 提供一个最简复现 Demo Page({ data: { }, onShow: function () { console.log('onShow') //did not work // this.testAnimation() }, onReady: function () { console.log('onReady') //worked this.testAnimation() }, testAnimation:function(){ const animation = wx.createAnimation({ duration: 2000, timingFunction: 'ease', delay: 0, }) animation .scale(4, 4) .step() .scale(2, 2) .step({ duration: 200 }) .scale(4, 4) .step({ duration: 200 }) this.setData({ animationData: animation.export() }) } })

- 需求的场景描述（希望解决的问题） onShareAppMessage 默认冒泡，能否阻止其冒泡？ - 希望提供的能力 提供阻止其冒泡的参数（类似于组件）

- 当前 Bug 的表现（可附上截图） [图片] 如上图所示，直接报错为页面（页面路径）没找到，删除app.json中的usingComponents字段以及字段中的所有内容，即恢复正常，即便是空的usingComponents字段，同样会导致这样的问题。 下图是我的app.json: [图片] 下图是目录结构： [图片] - 预期表现 正常情况下，应该如调试那般可以在手机上访问到页面并正常显示。 - 复现路径 在app.json中声明组件之后，调试&真机调试通过，无法在手机上“编译并预览”，上传到线上也无法预览。 - 提供一个最简复现 Demo 如上文描述

- 当前 Bug 的表现（可附上截图） 第一次打开开发者工具或者是小程序 [图片] 点击调试 [图片] - 预期表现 应该是瞬间响应的（使用get就瞬间响应） - 复现路径 第一次打开调试工具或者小程序 - 提供一个最简复现 Demo 使用微信开发者工具打开包含上述post请求的页面，就会出现上述情况，当再次点击调试时（打开开发者工具时，默认会执行调试），是瞬间响应的。

- 当前 Bug 的表现（可附上截图） 当image的mode="widthFix"，同时只给image一个宽度，image显示的时候就会有一个迅速缩小的过程（如果原图片高度大于 根据宽度widthFix之后的高度），而且原图高度远大于widthFix之后的高度时，image的这种缩小就越明显，视觉上的表现为-闪烁！这种情况下的用户体验极差。 下图是不加 mode="widthFix" 时，且只设定宽度的image的表现 [图片] [图片] [图片] 下图是加上 mode="widthFix"的表现： [图片] 事实上，当加上 mode="widthFix" 而且只给image设定宽度不设定高度，之后图片是有一个明显的缩小的过程的（高度缩小为 widthFix根据设定的宽度和原图比例而生成的高度） - 预期表现 预期表现是没有这个缩小的过程，给image设定mode="widthFix"之后，在编译过程中，编译工具根据设定的图片宽度，以及原图的横纵比自动生成一个高度并赋予给image（fixedHeight = width * ( srcHeight / srcWidth )）。这样，在编译过程中就已经生成了高度，而不是在image展现的时候才进行计算，出现一个拉伸/缩小的过程，这样不仅可以避免闪烁，而且还可以减少客户端压力。 暂时性解决方案，还是要给image标签设定一个差不多的高度，让它自己去调整，不过这样依然会有视觉上的细微变化，不够完美。 - 复现路径 复线路径上方已说明。 - 提供一个最简复现 Demo demo同上。