Display & Propagate Errors

各位同学，咱们今天聊一聊错误处理这个容易被忽略但又特别影响用户体验的话题。想象一下，用户在操作时遇到错误，突然看到一个风格怪异、措辞模糊的红色弹窗，是不是既困惑又恼火？所以，错误显示必须做到“一致且有帮助”——所有报错看起来都像一家人，而且告诉用户到底哪里错了，该怎么修。 Salesforce 给我们提供了很便捷的内置工具。第一个就是 ShowToastEvent，它能弹出一个标准的 toast 通知，像一个小提示条，你可以设置 title、message 和 variant。但真正的麻烦在于，后端报上来的错误长得五花八门——有时是 Apex 异常，有时是 LDS 的错误结构，有时干脆是 JavaScript 抛出的原始对象。怎么办呢？我们接下来讲一个神器，叫做 reduceErrors。 reduceErrors 来自 ldsUtils 模块，它专门负责把各种形状的错误“暴力”拆解，最后压平成一个纯字符串的数组。比如你尝试调一个 wired 方法失败了，直接用 reduceErrors(error) 就能得到一段人类能读懂的报错文本，你就可以安心地塞进 toast 的 message 里了。这里面有一个重要原则：，永远在消息里加上纠正措施，。比如“无法加载记录，请确认您有读取权限”而不是只报“Error 403”。让用户知道接下来该点哪里、找谁或者刷新页面。 如果你想搭建一个更复杂的界面，Salesforce 的 lwc-recipes 项目里提供了一个叫 errorPanel 的组件，它就是一个可以拿来即用的错误显示模板，上方图标加文案，样式统一又美观，你只需要传给它一个 errors 数组就行。这能节省你反复造轮子的时间。 接下来我们说错误传播，就像传球游戏，错误得按约定路线走，不能乱扔。我们有三种标准方法： 1. ，throw，：用于组件树上抛同步错误。子组件里出错，直接 throw new Error('…')，然后上层的 error boundary 或者 try-catch 就能接住。但注意，这只在同步代码里有效，异步回调里 throw 没用，要考虑定制事件。 2. ，CustomEvent，：典型的孩子向父母喊话。子组件用 this.dispatchEvent 发一个带错误信息的事件，父组件在模板里监听 onerror，然后统一处理。这样一来，错误处理和显示逻辑都集中在父组件里，容易维护。 3. ，Lightning Message Service 或 pubsub，：当你的错误需要跨越不同 DOM 分支，比如从工具条组件发给主面板，它们之间没有直接的父子关系，就用消息通道。LMS 是官方推荐，pubsub 更轻量。无论哪种，都相当于一个广播电台，谁想知道错误就去订阅。 最后说说最佳实践模式，可以总结成一句话：，错误从子组件来，在父组件集中处理，用统一的方式温柔地告诉用户，并且永远不会悄悄失败，。具体做的时候，要显式处理所有的同步错误和所谓“rewrite”错误——也就是把原始错误包装成用户看得懂、有行动指引的信息。比如用 reduceErrors 解析后，拼上“请刷新后重试”之类的话。这样整个应用的容错性、品牌感和友好度都会提升一大截。 好，这一页的核心就这些，大家记住：一致、有帮助、有行动指引，让错误不再可怕。