Signal Refresh & Register Container

DEX475 - Refresh Component Data with RefreshView API

📄 第 320 页 🎬 视频课程

课程章节介绍

同学们,今天我们来讲一下LWC刷新架构的三个关键角色,它们通过闪电/刷新模块连在一起工作。你可能会疑惑,一个简单的刷新操作,怎么还要分成几个部分?别急,我慢慢给你说。 首先,第一个角色是“事件触发者”。任何组件都可以发出一个名叫RefreshEvent的信号,告诉大家“嘿,该刷新啦!”通常,这是一个按钮组件,比如你点了一个“刷新数据”按钮。 第二个角色是“刷新容器”。容器需要主动注册,用registerRefreshContainer这个方法,来监听刷新事件。当容器收到事件后,它会收到一个叫freshPromise的承诺。这个承诺很贴心,它会等所有处理刷新的程序都完成后才解决,并且会返回一个状态,比如刷新完成、因为报错完成、或者警告。容器可以用这个状态来做很多事情,比如显示加载动画、处理错误、或者弹出提示。 第三个角色是“参与者”。各个组件注册自己的处理程序,来真正执行刷新数据的逻辑。容器在它的模板里,一定要包含处理程序的组件,还有触发事件的按钮组件。 这里有个重要的机制:刷新事件会像泡泡一样沿着DOM向上冒泡。也就是说,离触发按钮最近的、注册过容器的祖先组件,会先收到这个事件。另外提醒一下,LWS和RST环境下,注册参数的格式稍微有点不同,使用时留意一下就行了。 好了,这就是刷新架构的简单模型:按钮触发事件,容器统一管理状态,参与者干活。记住这个小分工,后面用起来就清楚多了。

关键词

LWC Lightning Web Components Salesforce