State Management & Derived Attributes Best Practices

同学们好，今天我们来聊聊 LWC 在 Flow 里面的状态管理，你会发现它和 Aura 有根本性的不同。在 Aura 里，我们可能会直接去改一个属性，但在 LWC 里，这样做就会出问题。 LWC 强制执行非常清晰的所有权分离。一个用 @api 装饰的属性，只能由父级去修改——在 Flow 的场景里，Flow 运行时就是父级。也就是说，Flow 屏幕把值传给组件，是通过 @api 属性进来的。而组件自己内部使用的状态，应该用 @track，或者更简单，直接用没有装饰的普通属性。 当组件内部的状态发生变化，需要告诉 Flow 的时候，我们不能直接去给 @api 属性赋值。正确的做法是触发一个 FlowAttributeChangeEvent 事件，把属性的新值传出去。因为 Flow 运行时需要追踪这些变化，才能维护好界面的反应性，还有条件可见性那些准确的状态。如果你偷偷改了 @api，Flow 就不知道内容变了，界面就会出现各种奇怪的现象。 其实呢，平台还保留了一些向后兼容的行为，比如在导航的时候会提取 @api 属性当前的值。但千万别去依赖这个，这只是过渡期的兜底方案，未来的版本随时可能不支持。 接下来要讲一个非常重要的模式，叫“双位置模式”，专门用来处理派生属性。比如，表单里某个字段的值一改，你要立刻更新一个隐藏的状态。这时候你需要在两个地方触发事件：一是在那个“驾驶属性”的 setter 里，保证每次值变化都能驱动整个反应链；二是在 connectedCallback 生命周期里，这样当组件刚初始化展示的时候，也能基于初始值触发一次更新。两个位置缺一不可。 还有一个很常见的踩坑点：有些人会想用 Promise.resolve().then() 去延迟触发事件，觉得这样可以等一等生命周期。千万不要这么做！这样当用户重新访问这个屏幕的时候，你延迟的事件可能会覆盖掉 Flow 恢复过来的保留值，造成数据错乱。 最后，为了让大家养成好习惯，可以在项目里配上 linter 规则，强制检查“不能直接修改 @api 属性”这个模式。有了工具的提醒，代码就不会不小心写出反模式来。 好了，这节课的重点就是：LWC 把属性所有权分得很清楚，Flow 里的 @api 是只读的，通过事件来通信，记得用双位置模式，别依赖向后兼容，更别用 Promise 去延迟事件。这部分掌握好，Flow 里的组件交互就稳了。