Navigation Events & Component Patterns

同学们好，今天我们来聊聊在 Flow 里自定义组件时，如何控制流程的导航，以及两种很实用的数据绑定模式。 先说导航事件。你写的组件放在 Flow 里，用户点击下一步、返回，或者卸载、完成，这些动作其实都需要组件来指挥流程往下走。在 LWC 里，我们专门有一组导航事件，比如 Next、Back、Finish 这些，它们都是从 lightning/stream 这个模块导入的。记好，这些事件只能放在事件处理函数里触发，像 handleClick 这种，绝对不能在生命周期勾子，比如 connectedCallback 里调用，不然会出错。 还有一点特别重要：一旦你调度了导航事件，代码的执行其实是立刻跳转的。也就是说，在 dispatchEvent 之后，不要再写任何代码了，那些代码根本不会执行。你就想象成点击按钮后，这一屏马上切走了，后面任何操作都来不及做。 接下来看颜色选择器模式，这是一个很好的职责分离示范。在这个模式里，组件只对外暴露一个输出值，也就是用 @api 装饰的 color 属性，这个值会传回 Flow。而组件内部的状态，比如用户输入的文本、当前选中的色块编号，统统用没有装饰的普通属性来维护。这样外部只关心最终结果，内部怎么变跟 Flow 无关，结构非常干净。 最后是 salutation 模式，它教我们怎么把多个 @api 输入属性，组合成一个显示值。比如你把称呼、姓名片段这些都作为输入，怎么动态拼出完整的问候语呢？这里没有用 track 去手动更新，而是定义了一个 getter 函数，它会根据所有输入属性，实时计算出派生值。 关键点来了，这种多输入的组件需要防御性编程。因为 Flow 运行时不保证你那些 @api 属性的设置顺序，可能它先设了姓，再设了名称前缀，也可能反过来。所以，我们在每个 @api setter 里面，都要重新触发一次派生逻辑的更新。用 getter 的好处就在这里，因为 getter 每次被访问时都会根据当前所有属性重新计算，无论它们被设置的顺序是什么，最终显示一定是对的。这样你的组件在 Flow 里就非常健壮，再也不会因为属性赋值的先后顺序而显示异常了。 好了，今天这页内容的精华就是这些，导航事件要放在 handler 里触发，触发后别写代码；颜色选择器分清内外状态；salutation 模式利用 getter 和每个 setter 的重新计算来保证多输入顺序无关的正确显示。希望你们能理解并在自己的组件里用起来。