3.0.3 BREAKING CHANGE 是非必要而且危险的

[cncolder]

相关平台

微信小程序

小程序基础库: 1.0.0
使用框架: React

复现步骤

https://github.com/NervJS/taro/pull/6996/files#diff-c3713fcdd092b87eb695a56f1d47f3b5R210

此处的 component 是从 page 入口导入的, 是一个 class, 生命周期不是 static method, 应该是 component.prototype.onShareAppMessage, 后面的 config enableShareAppMessage 条件没有必要.

https://github.com/NervJS/taro/pull/6996/files#diff-f035659abb914ec7b148ba77e7500928R30

此处函数式组件的初始 onShareAppMessage 值是 undefined, 即不是函数也不是数组, 应该恢复成字符串判断, 只有这样才能在页面第一次初始化时正确赋值, 同上 config enableShareAppMessage 条件没有必要.

hook 版本如何修复待考证.

对于 onShareAppMessage 这种需要返回值的分享类生命周期, 最早的 hook 版本是每次都覆盖, 之前我的 pr 修改为固定不变的函数, 3.0.3 版本变成了数组, 经过 safeExecute 处理后返回第一个 hook 的值.

期望结果

原本不需要 BREAKING CHANGE
即使真的需要, 应该发布 3.1.0 版本.

实际结果

用户没看 release note, 直接更新版本并上线, 不仔细测试, 会导致之前的分享页面被屏蔽, 造成事故.

环境信息

👽 Taro v3.0.3


  Taro CLI 3.0.3 environment info:
    System:
      OS: macOS 10.15.5
      Shell: 5.7.1 - /bin/zsh
    Binaries:
      Node: 14.3.0 - /usr/local/bin/node
      Yarn: 1.22.4 - /usr/local/bin/yarn
      npm: 6.14.4 - /usr/local/bin/npm
    npmPackages:
      @tarojs/cli: 3.0.3 => 3.0.3
      @tarojs/components: 3.0.3 => 3.0.3
      @tarojs/mini-runner: 3.0.3 => 3.0.3
      @tarojs/react: 3.0.3 => 3.0.3
      @tarojs/router: 3.0.3 => 3.0.3
      @tarojs/runtime: 3.0.3 => 3.0.3
      @tarojs/taro: 3.0.3 => 3.0.3
      @tarojs/webpack-runner: 3.0.3 => 3.0.3
      babel-preset-taro: 3.0.3 => 3.0.3
      react: ^16.10.0 => 16.13.1
      taro-ui: ^2.3.4 => 2.3.4

[fjc0k]

+1。我在这个 PR #7055 也做了类似的阐述：

另外，我觉得 #6996 带来的 breaking changes 似乎不太妥当，似乎用 disableShareAppMessage、disableShareTimeline 更为合适，一是因为这样不会带来任何不兼容更新，二是其实更多的需求是让用户分享，而不是禁止用户分享，一个十分常用的功能却要手动在每个页面开启是十分令人抓狂的。

[cncolder]

@fjc0k 如果改成 disable 虽然可以避免事故, 但是更加背离小程序, 因为原本小程序就是根据有没有分享生命周期决定是否显示分享菜单的.

https://developers.weixin.qq.com/miniprogram/dev/reference/api/Page.html#onShareAppMessage-Object-object

[fjc0k]

@cncolder 我提那个点是基于 enable* 提的，相对于 enable*，disable* 不会给现有代码带来任何副作用，而且也能给少数用户提供禁止的途径。当然，如果 enable* 无必要，那 disable* 也无必要。

[cncolder]

@fjc0k 是的, 原生小程序根据 Page 实例有没有 onShareAppMessage 决定是否显示分享菜单, 也就是说 3.x 长期以来有个 BUG, 在初始化页面时给 onShareAppMessage 绑定了一个工具函数, 导致页面强制显示分享菜单, 并且无法关闭.

如果使用 component.prototype.onShareAppMessage 判断应不应该为 Page 实例分配默认的工具函数, class 组件就和原生开发的 Page({}) 保持一致了.

现在的问题是出在 hook 版本上, 官方对用户有些放任了, 生命周期 hook 原本是页面的专利, 现在却允许用户在子组件中使用并且多处出现, 甚至是 useShareAppMessage 都允许多次调用. 或许最初的实现是对的, useShareAppMessage 是覆盖关系, 只有最后一次调用会生效.

[luckyadam]

@fjc0k 是的, 原生小程序根据 Page 实例有没有 onShareAppMessage 决定是否显示分享菜单, 也就是说 3.x 长期以来有个 BUG, 在初始化页面时给 onShareAppMessage 绑定了一个工具函数, 导致页面强制显示分享菜单, 并且无法关闭.

如果使用 component.prototype.onShareAppMessage 判断应不应该为 Page 实例分配默认的工具函数, class 组件就和原生开发的 Page({}) 保持一致了.

现在的问题是出在 hook 版本上, 官方对用户有些放任了, 生命周期 hook 原本是页面的专利, 现在却允许用户在子组件中使用并且多处出现, 甚至是 useShareAppMessage 都允许多次调用. 或许最初的实现是对的, useShareAppMessage 是覆盖关系, 只有最后一次调用会生效.

暂时先改进对类组件的支持，尽量先减少一些伤害，hooks 得再思考一下有没有好的方式来支持

[songkeys]

有个 beta 版本的 API 可以隐藏胶囊里的分享按钮，或许可以解决 hooks 的问题：
https://developers.weixin.qq.com/miniprogram/dev/api/share/wx.hideShareMenu.html

[shjyh]

对这样的更改真的失望，要不是今天测试都没有发现这个问题，分享直接发出页面截图泄露敏感的运营数据。
原本可以通过小程序的hideShareMenu/showShareMenu做到的功能，而且已经封装好相关的hook了，现在全都要配置一遍。
至少给一个全局配置的默认开关吧，不用每个页面去更改