DEX475

课程介绍

大家好，今天我们来聊聊Lightning基础组件。你可以把它们理解成Salesforce提前帮咱们做好的一套积木块，外观上自动遵循了SLDS设计规范，界面统一又好看，直接在Lightning命名空间里就能调用。不管是LWC还是Aura组件都能用，当然，我们强烈建议你优先选LWC。 整套基础组件分成了十个大类，咱们会把每个类别都走一遍，还会附上完整组件列表。用的时候要注意，大部分组件要求的最低API版本是45.0，一些比较新的组件版本要求更高。它支持的运行环境也很广，比如Lightning Experience、移动端、Experience Builder站点、LWR网站等等，基本覆盖你日常开发的场景。 再说说命名，标签里写组件名是用破折号分隔的，比如lightning-button，而JavaScript导入时模块路径是用斜线分隔的，像lightning/button。组件有三种典型的使用模式，后面会细讲。如果需要为组件设置全局性的属性，也有一套统一处理方式，很好掌握。事件处理这块，咱们主要通过自定义事件来通信。 架构思路上，我们提倡组合和扁平化结构，避免层级嵌套太深。插槽机制能很方便地实现组合，把内容嵌进组件里。如果是数据驱动的组件，要善用属性的方式把数据传进去。最关键的是，所有这些组件都从底层支持了WCAG 2.1 AA级别的无障碍访问标准，你用了它们，就能默认提供相当好的辅助体验，省心又合规。 好，这一节先给你一个整体概念，具体每个类别我们接着往下看。

课程章节

本课程共有 12 个章节

• 1

  Base Components — Overview & Categories

  第 248 页

  同学们，今天我们来聊聊Lightning Web Components里一个特别基础但很重要的概念——基本组件。你可能会想，基本组件到底是什么？别急，我慢慢给你捋清楚。 首先，这些基本组件被分成了十大功能类别，几乎涵盖了你做界面时所有常见的需求。你不需要自己去造轮子，Salesforce已经帮你准备好了。 第一个类别是，动作和菜单，。想象一下一个按钮，它可以是普通样式，也可以是带品牌色的、中性的、表示破坏操作的、或者表示成功的变种。所有可点击的触发器，比如按钮、按钮组、菜单，都在这儿了。 接下来是，容器，。你想把一组内容收起来？用手风琴。想突出展示一张卡片信息？用卡片。想弹出一个对话框？用模态框。还有标签页和响应式布局，帮你把页面安排得明明白白。 ，图像与视觉效果，，这个分类里有什么？头像，用来显示用户照片；徽章，显示个数或状态；图标，表达含义；地图，嵌入地图；还有药丸，一种紧凑的标签样式。视觉效果一目了然。 ，输入组件，，这个是重头戏。不管你是要文本输入、数字、日期、选择列表还是文件上传，基本组件都带内置验证，帮你处理各种数据输入类型，省心。 那表单呢？，表单组件，更是厉害，它能根据你对字段的配置自动生成或更新记录，并且遵守字段级安全，不需要你写额外的代码去控制权限。 ，导航组件，，比如面包屑，让你知道当前在哪个位置；垂直导航，适合做侧边栏。这些都能快速搭建。 然后是，收件箱，，其实是消息通知类的组件。包括模式对话框，像Alert警告、Confirm确认、Prompt输入提示，还有Toast消息，类似短暂弹出的通知。这些交互你肯定都用过。 ，输出组件，，就是只读展示的数据，它会根据用户的区域设置，自动格式化数字、日期、货币等，比如你看到 $1,000.00 而不是 1000.0。 ，进度组件，，显示流程状态，比如进度条、路径指示器，让用户知道当前走到了哪一步。 ，表和树，，用来处理大量数据。表格可以排序、筛选、无限滚动，树可以展示层级结构，这些都是通过扩展机制支持大数据集。 最后是，实用程序模块，，它不显示任何UI，但提供了一些有用的服务，比如获取用户信息、操作数据，帮助你在组件里调用。 特别要注意的是，这些基本组件没有版本控制。也就是说，你改变组件的API版本，并不会改变基本组件的行为。它们始终是跟着SLDS最新的设计更新走的。所以，用基本组件，就等于你自动获得了最新的样式和交互，始终保持统一和现代。 记住，用好这些基本组件，开发效率会提高很多，界面也好看、一致。这就是今天的内容，下次我带你看看具体怎么用它们。

  ▶ 播放视频 查看详情
• 2

  Base Components — Minimum API Version & App Containers

  第 249 页

  同学，我们来看今天这个挺重要的概念——基本组件版本控制。听起来有点绕，别急，我一句话跟你说清楚。 在Lightning Web Components里，我们用的那些基础组件，比如按钮、表单、数据表格，它们自己是没有版本号的。你就算在组件的 .js-meta.xml 配置文件里改了 API 版本，基础组件本身的行为也不会变——它永远是给你最新、最稳定的那一版。简单讲，你永远在跟最新的基础组件打交道，不能挑个老版本用。 但是！注意这个“但是”——API 版本会控制你的组件所运行的整个 LWC 框架的行为。换句话说，框架怎么解析、编译、优化你的代码，是跟着这个 API 版本走的。所以我们要求的最低 API 版本是 45.0，也就是 Spring ‘19 那个版本。打个比方，如果你的组件设置的是 58.0 以下的版本，系统会自动把它当成 58.0 来处理。所以，最好的习惯就是：始终更新到最新的 API 版本，这样你的组件就能享受框架最新的特性和性能优化。 接下来我们看第二部分：应用容器。这些基础组件本来设计上是和平台无关的，但实际很多组件离不开 Salesforce 平台本身的特性。比如说，记录表单肯定要靠 Salesforce 的数据，LDS 模块要跟后台通信。所以，并不是所有基础组件都能在所有环境里使用。你去翻组件参考文档的时候，会有一个“目标”面板，清清楚楚列出每个组件能在哪些容器里运行。比如一个组件可能只支持 Lightning 应用程序，不支持在 Lightning 站点里用。 然后针对新的 LWR 站点，只有一部分组件支持服务端渲染，也就是 SS。还有嵌入式服务聊天、Experience Builder、CRM Analytics 这些产品，它们自己还有额外的命名空间。这些特殊情况，你在实际开发时一旦遇到了，查一下组件参考就知道该用哪个、该注意什么了。 简单回顾一下：基础组件没版本控制，你永远拿最新版；但你的组件文件里的 API 版本控制的是框架行为；最低要求 45.0，低于 58.0 按 58.0 算，所以及时升级 API 版本；不同容器能用的基础组件不一样，用之前记得翻组件参考。 好了，这部分概念不难，记住它的逻辑就行。我们继续下一个知识点。

  ▶ 播放视频 查看详情
• 3

  Base Components — Naming, Namespaces & API Modules

  第 250 页

  好，我们来看一下Lightning Web Components里面引用组件和模块的一些命名习惯。你在HTML模板里直接用标签的时候，像按钮组，就写`lightning-button-group`，中间是连字符，这叫破折号分隔的名称。但是如果要在JavaScript文件里导入这个模块，就需要用斜线分隔的写法，比如`lightning/buttonGroup`，这代表一个模块路径。记着：模板里用标签名，JS里用模块路径，这两种写法对应不同的使用场景。 接下来说几个重要的最佳实践，帮你少踩坑。第一，只使用文档上公开记录过的属性。那些看起来能用、但实际上属于内部或保留的属性，随时可能被Salesforce悄悄改掉，你的代码就崩了，所以要管住手。第二，关于样式，尽量多用组件自带的一些变体，还有Salesforce设计系统提供的工具类，比如用`variant`属性或者直接套SDS的类名，而不是自己写一堆自定义样式去强行覆盖，这样维护成本更低，也符合平台规范。第三，当你需要拿到模板里某个元素的引用时，推荐用`lwc:ref`指令标记它，然后在JavaScript里通过`this.refs.xxx`去访问。这样做要比传统的`id`加`querySelector`高效得多，因为`this.refs`是直接引用，不需要让引擎在整个DOM里扫描查找，性能更好。 最后，我们看一下这些API模块大概怎么分类。它们可以分成三类，这样你找起来也更方便。第一类是跟界面直接相关的UI模块，用来创建用户看得见的交互元素，比如toast消息、提示框、警告框、确认对话框，这些通常都是调用`.open()`方法就直接弹出来。第二类是服务或工具模块，提供平台层面的能力，比如导航到别的页面，或者使用消息服务在组件间通信。第三类是数据访问模块，封装了Lightning Data Service的线适配器，还有一些专门处理Salesforce数据的函数，让你读写数据更简单。搞清楚这几类的区别，以后要用什么功能，直接去对应类别里找就好了。

  ▶ 播放视频 查看详情
• 4

  Usage Patterns — Use a Base Component in Markup

  第 251 页

  今天咱们来看一看这个最基本、最常用的模式——如何在标记里使用我们的基础组件。 你可能会觉得，哎，这不就是把一个带属性的组件标签往模板里一放就完了吗？对，就是这么简单。比如说我们放一个“按钮”组件，写上 `variant="brand"`，再加个 `label`，就搞定了。但背后发生了什么呢？这其实是基础组件一个特别棒的设计：它把复杂的内部逻辑全都封装好了。刚才那个 `variant="brand"` 这个属性，组件内部会自动把它转换成标准的 SLDS CSS 类，也就是 `slds-button_brand`，加到内部的按钮元素上。这一切都是自动的，你根本不用操心该加哪个类，会不会拼错。 而且，你看到了吗？不仅仅是组件特有的属性，像 `variant`、`label`，连那些 HTML 原生就支持的全局属性也全都暴露出来了，比如 `title`、`class`，甚至事件处理器 `onclick`。这些全都是公开的公共属性，你直接用就好。这样你就拥有了完全的控制权，想怎么调整按钮的样子和行为都可以。组件内部会很聪明地把这些值传递到它内部对应的那个真正的 HTML 元素上去。 所以，如果你想调试一下，看看它最终渲染成什么样，完全可以在浏览器的开发者工具里检查 DOM 结构，理解它怎么工作的。但一定要记住一个非常重要的原则：你可以在调试时看，但千万不要在你的业务代码里去依赖那些内部生成的 DOM 结构，或者那些 CSS 类名。因为这些属于我们组件的“内部实现细节”，Salesforce 是可以在未来的更新中，随时修改而不提前通知你的。你如果写了依赖内部结构的代码，以后可能就突然失效了。所以，请只通过组件暴露出来的公开属性去使用它，这才是最安全、最推荐的做法。 好，这一页我们就讲到这儿。核心就是：放心地用这些封装好的组件，用属性去控制它们，别去碰它们的内部肚子里的东西。这样你的代码才稳定、好维护。

  ▶ 播放视频 查看详情
• 5

  Usage Patterns — Module Import & Extension

  第 252 页

  同学们好，今天我们来聊聊 Salesforce Lightning Web Components 里的模块导入模式，主要是通知和吐司这类组件怎么用。以前我们习惯用浏览器自带的 alert、confirm、prompt，但那些会阻塞页面，体验不太好。现在 LWC 用模块导入的方式，比如你想弹个警告框、确认框或者提示框，就导入 lightning/alert、lightning/confirm、lightning/prompt 这些模块，然后调用它们的 .open() 方法，传入一个配置对象就行了。最关键的是，这些方法是非阻塞的，也就是说代码不会卡在那等用户点确定，而是返回一个 Promise，你可以用 async/await 等到模式关掉后再拿到用户的反馈，这样处理异步逻辑更优雅。 再说吐司通知，强烈建议大家用 lightning/toast 这个模块。它直接导入，用起来很方便，而且能在所有环境跑，包括 Lightning Web Runtime（LWR）站点。相比之下，老的 lightning/platformShowToastEvent 是基于事件的，LWR 根本不支持，所以新项目就直接用 lightning/toast 吧。 最后有个约束要记住：在扩展模式这块，官方只允许扩展两个基础组件。一个是 lightning/modal，用来创建自定义的模态框，带 header、body、footer 这些子组件；另一个是 lightning/datatable，用来开发自定义列的数据类型。除了这两个，不允许扩展任何其他基本组件类，否则会出问题。 好了，这部分就这么简单，记住三点：用模块导入替代老式弹窗，吐司用 lightning/toast，扩展只认 modal 和 datatable。接下来我们做个小练习巩固一下。

  ▶ 播放视频 查看详情
• 6

  Global Attributes — Support & Class Passing

  第 253 页

  同学们好，今天我们来聊一个在 Lightning Web Components 开发中经常被忽略，但非常重要的小细节——就是那些看起来很通用的 HTML 全局属性，在用到我们基本组件（比如 `lightning-button`、`lightning-badge` 这些）的时候，它们的表现和我们心里想的可能不太一样。 你可能会觉得：诶，既然 `lightning-button` 最终渲染出来也是一个按钮，那我给它加个 `autofocus` 属性，是不是一打开页面它就能自动获得焦点？或者给它加个 `title`，鼠标悬停时就能显示提示文字，对吧？但实际上你会发现——有时没效果，有时效果出在奇怪的地方。这是为什么呢？ 我们来看一下原理。很多 Salesforce 提供的基本组件，它们内部其实是由多层 HTML 元素组合起来的。比如一个按钮，外层可能有个 `<div>` 或者 `<span>` 做包装，里面才是真正的 `<button>` 元素。当我们给这个组件标签写一个 HTML 全局属性，比如 `autofocus`，组件并不会自动把这个属性“转发”到内部的真实按钮元素上。所以，虽然你写了 `autofocus`，内部那个按钮根本收不到，页面打开的时候焦点就不在它身上。 再比如 `title`，这个属性更微妙。你加上 `title`，它其实是落在了最外层的包装元素上——可能是个`<span>`标签，而不是里面的按钮或者图标。那用户把鼠标放上去，看到的小气泡提示，它的位置和交互就可能不是你预想的那样。所以，看起来你在写 HTML 属性，实际效果却打折扣。 那怎么解决呢？Salesforce 的设计师们已经想到了这一点。他们认为，不该让开发者去猜内部结构，于是为每个基础组件提供了专门设计的属性，目的是“直送”到正确的内部元素上。比如说 `lightning-badge` 组件，你想给里面的图标加一个替代文本（就是屏幕阅读器读的那个），你就不应该用 HTML 全局的 `aria-label` 或者 `title`，而是要用它自己提供的 `icon-assistive-text` 属性。这个属性就能准确地作用在里面的图标上，不会跑偏。 再比如说，我们经常想调整组件的样式，顺手就给组件加了个 `class="my-custom-style"`。那这个类最终会放到哪里呢？同样，它会被添加到组件最外层的包装元素上，而不是你心里想的那个内部按钮或者输入框。至于组件内部的那些设计系统样式（我们叫 SDDS 类），它们完全由组件自己管理，我们是没法通过一个外部 class 去轻易覆盖内部特定元素的。如果你想调整内部某些元素的样式，就得用组件的暴露属性（比如 `variant`、`styling-hook`）或者用 CSS 自定义属性（Styling Hooks）来实现。 所以说，同学们，当你下一次想用全局属性去控制一个 Lightning 基础组件时，一定要先停一下，去查查这个组件的官方文档——就在组件参考里面的“规范”选项卡。那里清清楚楚列出了这个组件支持哪些属性，以及这些属性的表现行为是怎样的。这能帮你避免很多意想不到的小坑，也能让你的代码更稳健、更被支持。 好了，今天的小知识点就是：，全局属性不是你想用，想用就能用，——要先查文档，找到组件专属那个正确属性，你的意图才能准确到达目标元素。下课！

  ▶ 播放视频 查看详情
• 7

  Handle Events on Base Components

  第 254 页

  同学们，咱们今天聊聊在Lightning Web Components里怎么处理事件。这页Slide讲的其实就是事件的黄金法则，用起来很简单，但要想用得巧，有几个关键点你可得记牢。 首先，基本组件的事件处理，完全遵循咱们LWC的标准模式——就是“oneventname”这种写法。比如说，你想处理一个按钮的点击事件，直接加个`onclick`属性就行；要监听一个输入框内容的变化，就用`onchange`。这些标准DOM事件，你不需要做任何额外的配置，原生支持，开箱即用。 那如果遇到基本组件自己特有的自定义事件呢？举个例子，闪电数据表（lightning-datatable）选中某一行的时候，它会触发一个“行选择”事件，名字可能叫`rowselection`。这种事件怎么处理？很简单，去看那个组件的文档标签页，里面会明确写出事件叫什么名字、传递什么数据。你想监听它，就在使用组件的时候加上对应的`on`开头属性，比如`onrowselection`，然后写个处理方法。 反过来，如果你自己有个组件，里面包含了基本组件，你想从你这个组件里向父组件抛一个自定义事件，该怎么做？用`CustomEvent`构造函数。调用的时候，你可以通过一个叫`detail`的属性来携带数据。就像这样： ```javascript this.dispatchEvent(new CustomEvent('myevent', { detail: { message: '你好' } })); ``` 父组件里要监听，也是同样的规矩：用`on`加上你的事件名，比如`onmyevent`，事件对象里的`event.detail`就是你传过来的数据。 好了，基本操作讲完，咱们再来聊聊高阶的心法——事件传播的最佳实践，一共有三条。 第一条：除非万不得已，别用合成事件。什么是合成事件？就是那些能穿过阴影边界（shadow boundary）的事件。LWC组件的封装性很强，默认事件都只在当前组件的模板里流动。当你设置`composed: true`时，事件就会穿过阴影DOM，冒到更上层。这很强大，但也容易导致混乱，因为事件可能意外地触发别处的监听器。所以，能不穿透就别穿透。 第二条：如果你确实需要合成事件，记得在预期处理它的那个目标组件上，把传播停下来。用什么方法？在事件处理方法里调用`event.stopPropagation()`，这样可以防止事件继续向上冒泡，干扰到更不该感知它的组件。 第三条：无论在哪种场景下，都要尽量减少不必要的传播。事件冒泡越深，影响范围越大，越容易产生副作用——比如不小心更新了不该更新的状态，或者触发了多余的逻辑。干净、可控，才是好代码。 默认情况下，LWC里的自定义事件是不会冒泡（bubbles: false）也不会穿过阴影边界（composed: false）的，这其实是一种安全的默认设计。除非你明确传入了`bubbles: true, composed: true`，否则事件就只在当前组件内部自生自灭，不会往外泄漏。所以，你要根据实际需要来决定是否放手让它传出去。 总结一下，处理事件记住三点：标准事件直接用，自定义事件查文档，抛事件用CustomEvent带detail，监听永远是`on`加事件名。至于传播，谨慎使用合成，及时停止，别让事件满天飞。这样你写的组件，既灵活又稳健。 好，这一页就讲到这里，有问题随时提。

  ▶ 播放视频 查看详情
• 8

  Base Component Composition — Composition Structure

  第 255 页

  同学们，我们接着来看Lightning Web Components中一个非常重要的设计模式，叫做“组合结构”。这个模式是大家在构建组件时最常用到的，也是最基础、最直观的一种方式。 想象一下，父组件就像一个容器，它里面留了一些空位，这些空位我们称为“插槽”。子组件呢，就可以放进这些插槽里，自动就形成了父子关系。这种声明式的写法，跟HTML的嵌套方式非常相似——你在模板里一眼就能看清楚整个组件的层级结构，哪个组件包含了哪个组件，一清二楚。 那除了简单的静态组合，我们还可以做动态组合。比如你有一组数据，可能是一个数组，里面每一项的数据都不一样。你可以用循环的方式，在父组件里遍历这个数组，把每个子组件动态地生成出来，再放进插槽里。这样，虽然子组件的数量是变化的，但父子之间依然保持着清晰的插槽关系。 举一些实际开发中常见的例子，你会发现这种组合结构无处不在。比如： - ，手风琴组件，（accordion）里，一定会包含多个，节，（section）； - ，面包屑，（breadcrumbs）里，包含一个个，面包屑项，（breadcrumb item）； - ，按钮组，（button-group）里，包含多个，按钮，（button）； - ，布局组件，（layout）里，包含多个，布局项，（layout-item）； - ，表单，（form）里，包含各种，输入/输出字段，（input/output field）； - ，选项卡集，（tabset）里，包含多个，选项卡，（tab）。 这样的组合对在标准组件里至少定义了十种，它们都遵循同一种模式：外层组件提供骨架，内层组件通过插槽填充具体内容。 那么，为什么我们要优先用这种组合方式，而不是单纯地通过属性（properties）来传递所有配置，把组件做成一个扁平的、大而全的结构呢？因为组合这种方式： 第一，，可读性高，。你看着模板代码，结构一目了然，维护的时候也不需要跳来跳去查属性。 第二，，可维护性好，。当你想调整某个子组件时，直接改它就行，不影响父组件的复杂逻辑。 第三，也是最重要的一点，它，符合HTML天然的工作方式，。Web开发的基础就是元素嵌套，组合就是让自定义组件也同样遵循这个思路，让学习曲线更平缓，也让组件之间的协作更自然。 所以，记住一点：在设计大部分用例的组件时，请尽量使用组合结构，而不是把所有东西都塞进属性里。这不仅能让你的代码更优雅，也帮你养成更符合标准Web开发思维的好习惯。 好了，这一小节就到这里，大家可以回味一下，下节我们再看具体的实现细节。

  ▶ 播放视频 查看详情
• 9

  Base Component Composition — Flat Structure

  第 256 页

  同学们，咱们今天聊一个Lightning Web Components里关于组件设计的小技巧，叫做，扁平结构，。听起来有点抽象对吧？别担心，我慢慢给你解释。 想象一下，我们平时搭建界面，习惯用“合成”的方式：就是在一个父组件里，直接把子组件的标签写在模板里，一层套一层。就像搭积木，一个父组件管着一大堆小积木（子组件），每个子组件自己再负责渲染。这种方式很清晰，代码读起来也直观，所以大多数时候都是首选的。 但有时候呢，我们遇到数据量特别大的情况，比如一个超长的列表、一个几千行的表格，你会发现页面开始卡顿了。这时候我们就需要考虑一种替代方案，也就是“扁平结构”。它不是说组件本身变扁了，而是设计思路上变“扁平”了。 在扁平结构里，我们不直接在模板里写一大堆子组件标签了。而是，通过属性（比如 options、data、items、columns 这种名字），把配置数据传进去。然后这个基本组件内部靠自己来管理所有子元素的渲染，它会直接生成大量的原生 HTML 元素。 咱们熟悉的 `lightning-select`、`lightning-combobox`、`lightning-datatable` 还有 `lightning-map`，这种复杂组件就是典型的扁平结构。你看，我们用 `lightning-datatable` 的时候，不就是在父组件里传给它 `columns` 和 `data` 两个属性就完事了吗？它背后噼里啪啦帮你生成好多原生的 `<table>`、`<tr>`、`<td>`，你一个子组件标签都没写。 那它有什么好处呢？，性能！， 原生 HTML 内联渲染比创建成百上千个自定义组件实例要快得多，内存占用也少。而且这么做，组件作者（就是 Salesforce 团队）能对每一个细节的渲染和验证做更细致的控制，保证底层运行高效又安全。 那问题来了，为什么我们不所有地方都用扁平结构呢？凡事都有权衡嘛。扁平结构的缺点是，可读性和可维护性会变差，。如果你自己写了一个扁平结构的组件，里面全是以数据驱动的方式生成 HTML，别人（包括三个月后的你自己）看这段代码，可能一头雾水，不如看标签嵌套的合成结构那么一目了然。所以一般情况下，我们还是优先用传统的合成方式，它让代码更友好。 最后，老师给你一条性能指导：如果你发现自己的应用里，有特别多层的嵌套合成，结果界面反应慢，该怎么办？可以试试，扁平化，这个思路。怎么做呢？把一些逻辑往上提到父组件，尽可能把子组件里能改成原生 HTML 的地方直接内联掉，减少那些最底层的叶子组件里自定义元素的实例数量、事件处理程序的数量，以及避免不必要的重新渲染。说白了，就是把那些频繁创建、销毁的自定义元素，换成静态一点的原生元素，用父组件的逻辑去驱动，这样能大大提升大型数据场景下的性能。 好，今天就讲到这儿。记住：合成优雅易懂，扁平强悍高效，按需选择，关注数据量，你就能写出又快又漂亮的组件了。下课！

  ▶ 播放视频 查看详情
• 10

  Pass Markup to a Base Component Slot

  第 257 页

  同学们，今天我们来聊聊 Lightning Web Components 里一个非常实用又优雅的概念——插槽合成。 想象一下，你要搭一个组件，比如手风琴菜单，里面有很多可以展开收起的部分。你是不是希望，直接在手风琴标签里丢进去几个部分，它就自动拼成一个完整的菜单？对，这就是插槽的妙用。 简单说，插槽就像一个占位符，你可以把内容从父组件“传送”到子组件的指定位置。它有两种：默认插槽和命名插槽。 默认插槽呢，就是你不给它起名字，所有放在组件标签中间的内容，都会自动跑进这个默认的位置。比如你写 `<lightning-accordion>` 里面放好几个 `<lightning-accordion-section>`，这些 section 就会自动进入手风琴的默认插槽，渲染成一个个可折叠项。面包屑组件也是一样，你把面包屑项放在它的标签中间，它就帮你排好。 可有时候，一个组件想接收多个不同类型的内容，比如闪电卡片组件。它有主内容区，还要有标题、操作按钮、页脚。这时候默认插槽就不够用了。于是我们有了命名插槽，给每个插槽起个名字，比如 “title”、“actions”、“footer”。你在父组件里写标签时，加上 `slot="actions"`，就能把按钮精确地塞到卡片底部的操作区。 还有一个关键点，当插槽里的内容发生变化，比如动态添加或移除元素，组件怎么知道呢？这就是 `slotchange` 事件的作用。基本组件监听这个事件，就能检测并及时响应插槽内容的更新。所以你不用手动写一堆属性去配置组件里该放什么，直接用标签组合，更直观更好维护。 所以记住我们的推荐：能用插槽的组合，就尽量别用属性拼凑。插槽让组件的合成就像搭积木，清晰又好懂，维护起来也轻松。好了，这节课就到这里，我们下次再见！

  ▶ 播放视频 查看详情
• 11

  Pass Configuration and Data — Attributes Pattern

  第 258 页

  这节课我们来看看属性模式和插槽模式的区别，什么时候该用属性，什么时候该用插槽。 属性模式，其实可以看作插槽的一种替代方案。那它的核心思路是什么呢？就是配置和数据不是通过嵌套子元素传进去的，而是直接通过组件属性来传递。这样写出来的模板结构会更扁平，层次更少。但这种方式也有自己的局限性。假如你的组件需要支持很多变体，比如一个按钮组里要放好几种不同类型的按钮，每种按钮的元数据又不一样，那这个时候你要是用属性去配置，那个属性对象就会变得特别复杂，很难读，维护起来也很头疼。所以你看，我们 LWC 里的 button-group 组件，宁愿用插槽和组合的方式，而不是用一大坨属性。 那什么时候适合用属性模式呢？当你有这几个需求的时候：你需要精细地控制渲染，或者想要更简单的元数据校验，再或者你想直接渲染原生 HTML 元素来获得性能优势。我给你举个 Lightning Select 的例子。在这个组件里，选项是通过一个数组属性传进去的，组件内部直接渲染出原生的 select 和 option 元素。这样做比给每个选项都创建自定义组件实例高效多了。因为它扁平化了组件树，大大减少了渲染的负担。 总结一下，属性模式让结构变平，但遇到复杂变体会让属性对象很臃肿；而插槽模式更灵活，适合多变的组合场景。选择哪种，就看你是追求简单校验和原生性能，还是需要应对多变的子内容。

  ▶ 播放视频 查看详情
• 12

  Base Components Accessibility

  第 259 页

  今天我们来看一看Lightning Web Components里一个特别贴心但你可能没注意到的设计——就是基本组件的可访问性。 你可能会想，可访问性是不是要自己从头写很多代码？其实不用，因为LWC的基本组件在底层已经帮你做了大量工作。它们严格遵循W3C的ARIA创作实践指南，组件状态变化的时候，那些ARIA属性会自动更新。 我举几个例子你就明白了。比如手风琴组件，当你展开或收起某一项，它的aria-expanded属性会自己切换，屏幕阅读器马上就能告诉用户这个区域是开了还是关了。再比如输入框，如果你输入的内容不符合验证规则，它会悄悄给你加上aria-describedby属性，自动关联到那条错误提示，这样视障用户就知道为什么提交失败。 再看导航，面包屑组件配好了aria-label和role属性，让辅助技术能清楚地说“这是导航路径，你现在在哪个层级”。这些都不需要你额外操心。 除了交互，视觉上的考虑也很到位。基本组件的颜色搭配完全符合WCAG 2.1的AA级对比度标准，保证文字和背景之间清晰可辨。按钮还贴心地提供了不同目的的样式变体——成功用绿色，报错用红色，品牌色、中性色都有，既好看又不影响辨识度。 表单这块做得特别扎实。每个输入控件都通过label元素正确关联，背后使用WAI-ARIA属性、title属性，复杂表单还会用fieldset和legend分组，加上表单说明文字。甚至输入验证的撤销功能都考虑到了，出错后能告诉你怎么改回去。 图像和图标组件呢，提供了替代文本属性，这些属性会直接映射到底层img元素的alt和title上。如果需要给屏幕阅读器传递信息，但又不想在视觉上显示，还可以用SLDS里的辅助文本样式把它隐藏起来。 所以总结一下，使用这些基本组件，你就有了一个坚实的可访问性起点。它帮你自动处理了复杂的ARIA管理，让你能专注于应用本身的业务逻辑，而不是陷入那些底层细节里。是不是很省心？ 好了，今天我们就讲到这，下次再见。

  ▶ 播放视频 查看详情