Register Refresh Handler — Participant Components

好，咱们今天来讲讲这个刷新处理程序在Lightning Web Components里是怎么玩的，尤其是在LWS和Lightning收件箱这两种环境下有什么不一样。 你可能会问，什么叫刷新处理程序？简单说，就是当外部的数据变了，容器组件想让里头的组件自己重新拉数据、更新界面，这时候就会触发一个刷新动作。那组件得提前告诉容器：“嘿，我准备好了，你可以来刷新我。” 这个“告诉”的过程，就是在`linkedCallback()`生命周期里，调用一个叫`registerRefreshHandler`的方法来注册一个处理函数。注意，这里说的是`registerRefreshHandler`，你看到的Slide里写的`registerRefreshDeliverSector`应该是笔误，我们实际用的是`registerRefreshHandler`。 但麻烦的地方来了——LWS和Lightning收件箱的注册方式不一样。LWS是新一代的运行时，写法简洁：直接传`this`和处理函数引用就好。而老的Lightning收件箱环境，必须用`this.template.host`作为上下文，并且要把处理函数用`.bind(this)`绑定好，不然里头的`this`可能就指错了。所以你在写代码时，很可能得做一个判断，看当前是哪种模式，再用对应的写法。 那这个处理函数得长什么样呢？它必须返回一个Promise，这个Promise最终要解析成一个布尔值。如果是`true`，意思就是“我这边刷新好了，你可以继续去刷新我的子组件”；如果是`false`，就是“到我这打住，下面的别动了”。所以你可以用它来控制刷新的深度，比如你发现数据没变化，没必要让子组件再动，就可以返回`false`。 处理函数里面一般干什么呢？最常见的就是重新获取数据，顺便更新一下UI状态，比如转个圈圈、弹个提示，然后把组件内部状态重新跟数据源同步一下。所以它是个很重的操作，别随便到处写。 还有一点很重要：刷新是自上而下、宽度优先的。也就是说，容器先触发自己的刷新处理函数，等它Promise resolve了，如果是`true`，再去刷新直接子级；所有子级都处理完了，才会到孙子级。这保证父组件先准备好，子组件再动，逻辑不乱。 最后，别忘了一件事：当组件被移除时，你得在`disconnectedCallback()`里，用之前保存的处理程序ID，调用`unregisterRefreshHandler`来取消注册。不然它可能还留着个回调，内存泄漏或者异常调用就麻烦了。 要记住：每个组件只注册自己的处理程序，刷新后代是框架自动根据你返回的布尔值来决定的，你不用替后代操心。 所以整体看来，这就是一套让组件主动声明“我能刷新自己”，并且在合适的时机接收刷新的机制。LWS和收件箱的差异只是历史包袱，你写代码时注意适配一下就行。 好了，这个点就说到这儿，有什么问题随时问。