Reactive Pattern — Custom to Custom & Best Practices

今天我们来聊聊 Lightning Web Components 里一种特殊的通信方式：，自定义对自定义反应，。这个听起来有点拗口，其实就是让两个独立的组件能够联动——一个发起变化，另一个自动响应。这个能力对于构建在 Flow 里嵌入的组件特别有用。 首先，两个组件都得遵守一个约定，叫做 ，FlowAttributeChangeEvent 契约，。简单说，源组件要负责派发一个事件，里面带上属性名和新值；反应组件则通过 `@api` 标注的属性来接收这个变化。 事件构造的时候，一定要注意：传给构造函数的那两个参数，第一个是，确切的 API 属性名，，第二个是，更新后的值，。这个属性名在你的 JS 文件、`js-meta.html` 配置文件和你用来触发事件时写的字符串，，三处必须完全一致，，一个字母都不能差。值呢，必须跟这个属性声明的数据类型匹配，比如你声明的是数字，就别传字符串。如果你要传一条记录，那就传一个包含字段和值的 ，JSON 对象，。 那在反应组件这边，怎么优雅地处理这个变化呢？最佳实践是，一定用 get/set 模式来包装 `@api` 属性，。因为 setter 有两个触发源：一个是外部 Flow 属性变化，另一个就是我们刚才说的事件触发。不管变化从哪里来，setter 都会执行，这样你就能在里面统一做状态更新，确保组件的逻辑是稳健的。这里要记住一条铁律：，永远不要在组件内部直接修改 `@api` 属性的值，——想改的话，一定要去触发 `FlowAttributeChangeEvent`，让整个流程按规矩走。 还有个小细节：事件对象一旦构造出来，就，别再去改它身上的 `bubbles`、`composed` 这些属性，了，因为它们在 LWC 里是只读的，硬改可能导致未知错误。另外，如果你的组件既要触发导航，又要触发属性变化，一定要留意，别让这两个动作同时飞出去，，否则可能出现竞态条件，让界面变得不可预测。通常的做法是把它们错开执行，或者通过一步回调用异步的方式处理清楚。 总结一下就四步：源头发事件，目标用 setter 接，三处名字要一致，值类型要匹配。这样你的自定义组件就能在 Flow 里如鱼得水，相互反应顺畅无 bug 了。 好了，这块内容就讲到这里，有什么疑问随时提。