z***@qq.com
z***@qq.com
  • 发布:2025-12-31 16:38
  • 更新:2025-12-31 16:38
  • 阅读:22

【意见】uni.showModal应保持一致性

分类:uni-app

从官方文档中showModal的说明

从 4.76 起,钉钉小程序会优先使用原生的 showModal,而不是使用 confirm 或 alert 模拟

我觉得应该撤回这一决定,尽可能保证端的一致性问题,设计的初衷应该保持端的一致性,差异性留在参数上,让开发人员尽可能只看官方文档,尽可能少的看平台文档,这样避免有过多的差异性,本身使用uni的目的就是想磨平多端的差异性。

现在因为showModal, 升级项目要对showModal单独的做hack, 我始终认为不应该有这样的设计。

其他建议

  1. 如果需要使用原生的方法,可以uni.native.showModal, native就锁定当前的平台

仅个人观点

2025-12-31 16:38 负责人:无 分享
已邀请:
Ask小助手

Ask小助手 - Ask社区AI助手

该问题请在专业群( uni-app 官方技术交流群 1 ) 咨询,群中有相关专业的管理员和群友。

您提出的问题确实值得关注。根据知识库文档,从 HBuilderX 4.76 起,钉钉小程序优先使用原生 showModal 是为了更好地适配平台规范(如钉钉官方文档),并非随意变更。uni-app 的核心目标虽是抹平多端差异,但当平台强制要求使用原生能力时(如钉钉对弹窗样式的规定),框架需遵循平台规则以保证基础功能可用性。

建议解决方案:

  1. 条件编译处理差异:通过 // #ifdef MP-DINGTALK 区分钉钉平台逻辑,避免全局 hack
    // #ifdef MP-DINGTALK  
    uni.showModal({ /* 钉钉特定参数 */ })  
    // #else  
    uni.showModal({ /* 通用参数 */ })  
    // #endif
  2. 使用插件市场方案:推荐尝试插件市场的统一模态框组件,它们通常已处理多端兼容性问题
  3. 反馈需求:可通过 uni-app 官方论坛 提交增强一致性的建议,团队会评估后续优化

这种设计变更通常出于平台合规性或性能优化考虑。建议关注 HBuilderX 更新日志,新版本常会优化跨端体验。当前 alpha 4.87 版本仍维持此策略,说明平台差异暂时无法完全消除。

内容为 AI 生成,仅供参考

要回复问题请先登录注册