DEX475

课程介绍

同学们，今天我们来聊聊LWC里的状态管理。你可能会问，什么是状态管理？简单说，就是我们怎么把组件里的数据和操作这些数据的方法，打包得更好管理、更容易维护。 想象一下，你写了一个计数器组件，里面既有显示数字的逻辑，又有增加、减少的逻辑，全混在一起，代码一多就容易乱。状态管理器就是帮你把这些数据和对数据的操作抽出来，单独放在一个专门的JavaScript模块里，这样渲染界面的代码就只负责显示，数据逻辑就放在状态管理器里，分工明确，代码自然就更整洁、更好测试了。 在LWC里，我们有一套专门做状态管理的工具，叫做@lwc/State。它给了我们几个好用的功能：比如defineState用来定义状态，atom用来声明一个响应式的值，computed可以自动计算派生出来的值，setAtom可以帮你修改数据。还有一个特别的fromContent方法，能让你在多个组件之间共享同一个状态实例，数据跨层级传递就更方便了。 最关键的一点是，这些状态是直接接入了LWC的响应式系统的，也就是说，你一改数据，页面上的内容就会自动更新，不用你手动去刷新。 不过要注意，现在这个状态管理功能在Experience Cloud里还不能用，所以如果你的项目要发布到Experience Cloud，就要先避开。 那么在这一章里，我们会从最简单的计数器例子开始，一步步讲到带嵌套组件和平台集成的复杂管理场景，完整地走一遍状态管理怎么用。这样一来，你就能把组件代码写得既清爽又高效。好，我们接下来就动手试试看！

课程章节

本课程共有 7 个章节

• 1

  State Management — Concepts & Benefits

  第 300 页

  我们现在来看一下LWC里面一个特别重要的概念，叫做状态管理。就像是给一个稍微复杂点的应用程序准备的一套工具。 你可以想象一下，最开始我们用LWC的时候，父组件传数据给子组件，就靠属性一层一层往下传，这叫“亲子道具传递”。这在小应用里很舒服，可一旦应用变大了，这种简单的传法就不够用了。那会有什么麻烦呢？ 我们总结出了六个典型的问题，等一下我会一个一个给你解释，让你感觉它们就像自己碰到过的一样。 第一个问题叫“支柱钻探”，你听这个名字可能觉得有点怪，其实它就是传数据的时候要穿过很多层组件，好比你在一个长长的队伍里传话，从队头传到队尾，很容易传错或者很累。比如最顶层的组件有个数据，但是最底层的某个小组件才要用，你就得一层一层往下传属性，即使中间那些组件根本用不着这数据，它们还是得接过手再传下去。时间一长，代码又乱又难维护。 第二个毛病，是把数据逻辑跟UI代码搅和在一起。组件既要负责画界面，又要负责管数据怎么获取、怎么更新，这样职责不清，后面想改一个东西，可能就得动很多地方。 第三个，状态更新的逻辑分散在各处。如果好几个地方都能改同一个数据，你很难搞清楚到底哪里动了手脚，调试的时候头很大。 第四个，是性能问题，因为有时候我们把加载数据和界面渲染绑得太死。比如页面一打开，就一股脑把一大堆数据全拉下来，然后才开始渲染，那用户就得等着，体验很差。 第五个，是复杂的多组件状态交互。一个用户操作可能同时影响好几个组件，比如你点了个按钮，左边的列表要刷新，右边的详情要更新，顶上的状态也要变。如果没有统一管理，很容易漏掉某个地方的更新。 第六个，状态逻辑缺乏可重用性。你在这个组件里写了一套很棒的数据处理方式，但下一个组件要类似的功能，还得再写一遍，很浪费。 为了解决这六个问题，LWC就提供了状态管理器这个思路。它的核心是什么呢？就是一个专门用来封装数据和操作数据的模块。好比我们请了一个专业的管家，把数据和对数据的修改方法都交给他管，别的组件就不用自己操心怎么存、怎么取了。 但这并不是从外面引入一个第三方库，而是LWC自己的一种习惯用法，是很原生的解决方案。这样你用起来更顺手，跟LWC本身的生命周期、响应系统都是天衣无缝的。 那它怎么跟LWC的响应系统配合呢？LWC里面有一个概念叫“原子”，你可以把它理解成数据的最小单元，是有响应式的。当这个原子的值变了，所有引用了这个原子的组件就会自动重新渲染。这个跟之前我们熟悉的父子组件传值一样，只不过现在不是从父组件传下来，而是组件自己去订阅这个原子，就像大家看同一块公告板，公告板上的内容一更新，想看的人都立刻得到通知，然后各自刷新自己那部分界面。 那组件怎么拿到这个共享的状态管理器呢？有两种方式。一种是通过组件层次结构，也就是用`fromContext`这样的方法，让上层提供，下层消费。另一种就更直接了，把状态管理器做成一个单例的模块，然后各个组件直接导入它，就像大家共用同一个工具包。这两种方式可以根据场景选择。 所以你看到，状态管理器并不是要把LWC原本的数据传递方式彻底替换掉，而是当简单道具传递已经开始碍手碍脚的时候，给你一套更优雅、更可维护的方案。它解决了支柱钻探、逻辑混淆、更新分散、性能耦合、复杂交互和重用性这六座大山，让代码清爽很多。 好，这一部分我们就先说到这儿，你只要记住核心就是一个专门的模块来管共享数据和操作，组件自动响应变化，就抓住了灵魂。有问题随时可以问我。

  ▶ 播放视频 查看详情
• 2

  defineState — Syntax & Structure

  第 301 页

  同学们，今天我们来聊聊Lightning Web Components中一个非常实用的工具——`defineState`函数，它用来帮我们创建状态管理器。 你可以把`defineState`想象成一个工厂的入口，专门生产状态管理器。怎么生产呢？它接收一个回调函数，这个回调函数就像一份生产蓝图。这个蓝图会拿到一个工具包，里面有三个核心原语：`atom`、`computed`和`setAtom`。然后，蓝图后面还可以跟一些你自定义的初始化参数。 在这个蓝图里，你可以用`atom()`来定义基础状态，就像我们在纸上画出一个个数据格子；用`computed()`来生成计算属性，它是自动根据其他状态算出来的值，就像表格里自动求和的单元格；还可以用`setAtom()`来定义修改状态的动作，就像写好操作这些格子的方法。最后，蓝图需要返回一个对象，这个对象就是状态管理器对外暴露的公共API，比如一些属性和操作方法。 当我们调用`defineState`时，它不会直接给你一个现成的管理器，而是返回一个工厂函数。你需要再调用这个工厂函数，比如 `myManager(args)`，才会真正创建出一个具有自己独立状态的实例。就好比你有了生产汽车的图纸，但得启动生产线才会造出一辆具体的车，每辆车都有自己独立的油量和里程数。 在组件里面，我们怎么使用这个实例呢？很简单。要读取状态值，就通过 `instance.Value.属性名` 来访问；要调用某个操作，就通过 `instance.Value.方法名()` 来执行。也就是说，所有从蓝图返回的属性和操作，统统挂在一个 `.Value` 代理对象上，这样你就能方便地读取和修改状态了。 总结一下，`defineState` 给了我们一种清晰的结构来组织状态逻辑，让状态定义、计算和修改都井然有序，而且每个组件实例都能拥有独立的状态副本，非常适合构建可复用的复杂逻辑。 好了，关于`defineState`的核心概念就讲到这里。有什么问题，我们随时讨论。

  ▶ 播放视频 查看详情
• 3

  State Management Primitives — atom & computed

  第 302 页

  嗨，同学，今天咱们聊聊 LWC 里面怎么更方便地管理状态的响应式。 你可能已经习惯了用 `@track` 或者 `@wire` 来让数据变化的时候自动更新界面，但还有一种更细粒度的工具，叫“基元”。它有两个核心概念：“原子”和“计算”。 先说“原子”。你可以把它想象成一个能装任何值的盒子，这个盒子和 LWC 的响应式系统是连着的。重点是，你不能直接伸手进去改里面的东西，只能通过一个专门的方法叫 `setAtom()` 来更新它。这就保证了状态的修改是受控的，框架能立刻知道有变化，然后更新用到这个值的地方。 接着是“计算”，它用来处理派生数据。什么叫派生数据？就是依据其他一些数据算出来的值。比如，你有一个状态叫“计数”，你想自动算出它的双倍值，没必要自己再维护一个变量。这时候就用“计算”基元，它接收两个东西：一个依赖项数组，和一个计算函数。 框架很聪明，它会自动追踪这个数组里哪些值发生了变化。一旦任何一个依赖项变了，它就会重新执行你的计算函数，把最新的依赖值按顺序传进去。举个例子，如果依赖数组是 `[计数]`，那计算函数就是 `(c) => c * 2`，把这个计算赋给一个变量 `doubleCall`，那每次计数更新，二倍值就会自动同步，不用你操心。 而且不管是原子还是计算，你都可以选择让它成为组件内部的私有状态，不暴露给外面；也可以通过将它们放在返回的对象里，变成公开可访问的属性，让父组件或别的地方也能用。 最后一个小提醒：依赖项数组一定要写全。如果你用的某个状态在数组里漏掉了，那这个计算出来的值就不会跟着那个状态变，导致数据过时，也就是我们常说的“陈旧值”。所以，依赖数组别漏项。 这样，就能写出很干净的函数式派生状态，逻辑清晰又好维护。下一节我们再深入看看实际怎么在组件中用它们。

  ▶ 播放视频 查看详情
• 4

  Actions, Public API & Counter Example

  第 303 页

  同学们，咱们今天来看状态管理中一个非常核心的点，叫做“动作是状态突变的守门人”。 什么意思呢？你可以把状态想象成一个保险箱，里面放着所有重要的数据，我们管这些数据叫“原子值”。而想要修改这些值，只有一条路——必须通过，动作，来调用 setAtom。这就好比你不能直接伸手进保险箱里拿东西，必须找那个专门掌管钥匙的守卫，也就是动作。 所以动作到底是什么？说白了，它就是个函数。它可以接收参数，执行同步或异步的逻辑，最后返回一个值。但关键在于，你希望外面能用到的东西，都必须在返回声明里明确暴露出去。公共API只包含你返回的值和这些操作。没有返回的，外面根本看不见，也碰不着。 这里有个非常容易踩的坑，大家一定要注意：你的动作不论初始化参数是什么，，永远返回一致的形状，。也就是说，返回对象的属性结构不能变。消费者依赖你的API，如果一会有这个属性，一会儿又没有，组件就会直接崩掉，维护起来也特别痛苦。 在模板里，我们又是怎么使用这些状态的呢？状态值通过像 `{counter.Value.call}` 这样的语法去访问，而动作呢，是绑定到组件的方法上，这样用户点击按钮之类的事件就能触发。 还有一条铁律：状态管理器必须纯粹。它只能管数据，绝对不要在里面去碰 DOM API、元素引用或者事件对象。比如你千万别在里面写 `document.querySelector`，也别去处理事件冒泡。把UI和状态彻底分开，状态管理器的任务只是计算和返回数据。 那放哪儿最好呢？最佳实践是创建一个专门的 API 模块组件，这个组件，没有 HTML 文件，，只有 JavaScript 和元数据。这样它就是个纯逻辑容器，别的组件可以随时 import 使用，跨组件共享状态特别方便。 总结一下：动作是唯一能改状态的地方，通过 setAtom 变更原子值；它是个能返回值的函数；暴露出去的 API 形状必须一致；模板里用特定语法访问和绑定；状态管理器必须纯粹，不碰任何 DOM 相关的东西；把它放在无模板的 API 模块里，方便复用。 咱们在开发时把这些点记牢，代码就会又干净又健壮。好，这一节先到这里。

  ▶ 播放视频 查看详情
• 5

  Share a State Manager — fromContext Pattern

  第 304 页

  同学们，咱们今天来聊聊 Lightning Web Components 里一个特别有用的模式，叫做“fromContent”模式。 这个模式是用来干嘛的呢？想象一下，你有一个组件树，里面有很多子组件，它们都需要共享同一份状态，比如一个计数器。按照传统方法，你可能得一层层地把数据通过属性往下传，或者用事件往上冒泡，管理起来很麻烦。但 fromContent 模式可以让你跨过这些层级，直接在任意深度的子组件里，拿到由祖先组件提供的同一个状态管理器实例。就像在家里的任何一个房间，都能直接打开水龙头用水，而不需要从厨房一桶一桶地传过去。 怎么做到呢？分为两个角色：提供者和消费者。 提供者组件会在自己内部创建一个状态管理器实例，比如代码里写的 `counter = counterManager(100)`，这就创建了一个初始值是100的计数器管理器，并把它保存成组件的一个属性。你可以把这个提供者看作是那个“总水阀”，它负责生成和保管唯一的那个状态对象。 然后，消费者组件想要拿到这个实例的时候，不是直接去属性里找，而是用 `fromContent(counterManager)` 这个方法来搜索。它怎么搜索的呢？很有趣：它先从自己开始找，如果没有，就沿着组件树一层一层地往上找，直到找到最近的、匹配类型的那个管理器实例。这样，不管消费者在组件树的哪一级，只要能找到一个提供者，就能自动连上。 这里有一个特别重要的点，时机问题。提供者必须在它自己连接到 DOM 的时候就去设置好这个实例，而且一旦设置好之后不能再改，否则会出问题。对于消费者来说，在 `linkedCallback` 这个生命周期方法被触发之前，是拿不到这个引用的。所以千万不要在构造函数里就去访问它，否则拿到的会是 undefined。可以把这个想象成：房子还没建好时，水龙头当然没法出水。 实际例子里，我们通常会把一个复杂的 UI 拆成几个独立的子组件，比如显示数字的、加一的、重置数值的、调试信息的。每一个子组件都通过 `fromContent` 引用同一个状态管理器，这样它们就都能读、能写同一份数据，实现了完美的共享。而状态管理器的逻辑本身，会放在一个专门的 JavaScript 模块组件里，这个模块没有 HTML 模板，只是纯粹的逻辑，这样导入的时候就非常干净。 总结一下，fromContent 模式让共享状态变得很简单，你只需要在根组件“放”一个状态管理器，任何子孙组件都能通过“向上查找”的方式自动获取到它。记住：提供者要早设置且不改变，消费者要等到 linkedCallback 再用，其他就交给框架来帮你处理吧。 好了，这个知识点就讲到这里，有什么问题随时可以提出来。

  ▶ 播放视频 查看详情
• 6

  Nested State Managers — Platform Integration

  第 305 页

  同学们，今天咱们来聊一个在Lightning Web Components里处理数据非常优雅的模式——，嵌套状态管理器，，也有人管它叫，数据瀑布，。别被名字吓到，其实就像多米诺骨牌一样，一件事情自然引发下一件，整条链自动完成。 想象一下，我们需要拿到一条记录，但不是简单地查一次就完了。咱们的情况是：先要知道这个记录是什么类型，然后根据类型去拿页面布局，再根据布局里列出的字段，去拿完整的记录数据。这中间每一步，都依赖前一步的结果。如果用传统的办法，可能要写很多代码去手动串联。但有了状态管理器，我们可以把平台提供的 ，smRecord， 和 ，smLayout， 组合起来，变成一个干净的流水线。 整个神奇的地方在于，我们有两个配置原子——也就是两个不起眼的小变量，一个存 `recordId`，一个存 `objectApiName`，它们藏在内部不对外暴露。然后定义三个步骤，用 `called()` 连接起来： - 第一步，用记录ID去获取一条最小化的记录，就是为了揪出它的 `recordTypeId`。 - 第二步，拿到这个类型ID后，自动去拉取对应的布局信息。 - 第三步，用布局里给出的字段列表，正式去取完整的记录数据。 当这些步骤串好之后，会自动生成一个干净的计算结果，把每个字段的display value或者原始value提取出来，变成一个整齐的对象。更重要的是，整个过程中每一个步骤产生的错误、加载状态，都会被统一汇总，你随时可以看到哪一步卡住了，出错在哪里，非常省心。 那怎么触发这条瀑布呢？非常简单，你只要调用一个action，比如 `setRecordId` 或者 `setObjName`，去更新那两个配置原子里的值。一旦值变化，整条链就会像多米诺骨牌一样，从第一步开始，自动重新评估，一直流到最终数据出来。 这种模式，实际上为复杂的、有依赖关系的数据检索，提供了一种，反应式、声明式的替代方案，。相比于传统 `@wire`，它把每一步的输入输出表达得更清晰，依赖关系一目了然，而且完全自动响应变化，代码量少，维护起来也舒服。 打个比方，就像自家厨房装了一套智能料理机：你只需要把食材（recordId和对象名）放进配置，剩下的事儿——取菜谱、看需要什么调料、最后出菜——全是自动流水线，你发个指令，坐等结果就行。状态、火候、有没有哪一步失败，面板上全能看见。这就是嵌套状态管理器带给我们的便利。 好了，今天这节课就到这里，大家去试试搭建自己的数据瀑布吧！

  ▶ 播放视频 查看详情
• 7

  State Management Examples & References

  第 306 页

  同学们，今天我们来看三个特别棒的代码示例，它们会帮大家更好地理解 LWC 里的状态管理模式。先别被“状态管理”这个词吓到，其实就是怎么有组织地管理组件里会变化的数据，让代码干净、好维护。 第一个例子叫“平台状态管理器示例”。它演示了怎么把 smRecord 和 smLayout 这两个内置管理器组合起来用。还记得我们之前学过的 @wire 吗？这个组合模式就是 @wire 的另一种选择。特别适合处理真实的业务数据请求，用的是嵌套状态管理器的思路，把数据一层层组织得很清楚。 第二个例子是个“简单商店”。它模拟了购物车的功能，但所有数据都只存在于客户端，没有存到服务器上。这个例子专门教我们怎么管理那些临时的、本地的数据——比如用户往购物车里加东西，但还没最终提交订单。虽然逻辑要连贯，但暂时不需要服务器持久化，这个模式就非常实用。 第三个例子在 lwc-recipes 项目里，叫 opportunitiesStateManager。这是一个完整的状态管理器应用，包含一个列表组件和另一个专门展示汇总信息的消费者组件。它展示了怎么把同一个数据源给不同的组件消费，每个组件只看自己需要的部分。 听完这三个例子，咱们总结几条最佳实践，以后你自己写状态管理器时一定用得上： 第一，一定要在 API 模块组件里定义状态管理器。这样结构清晰，其他组件都从这里拿数据。 第二，用 fromContent 的提供者/消费者模式来共享数据。这种模式让父组件提供数据，子组件消费，单向流动，好调试。 第三，保持返回的数据形状一致。不管什么情况，状态管理器返回的对象结构要稳定，这样消费者组件才不会出错。 第四，把 DOM 相关的逻辑完全排除在状态管理器之外。状态管理器只关心数据和业务逻辑，别让它碰 UI 更新的事儿。 最后，一定要尊重连接生命周期计时。什么意思呢？就是你的状态管理器要能正确处理组件的连接、断开，及时回收资源，避免内存泄漏。 记住这几点，你写的状态管理器就会健壮又好用。好了，以上就是今天的分享，下次我们可以动手练习其中一个例子，边写边感受。

  ▶ 播放视频 查看详情