Lightning Web Components Developer Guide

课程介绍

大家好，欢迎开始使用Lightning Web Components。这个介绍性章节会带大家全面认识一下 LWC，也就是在 Salesforce 平台上构建自定义用户界面的现代方式。咱们今天聊的内容很多，但我会一步一步，用最简单的话帮你们理清楚。 首先，究竟什么是 LWC 呢？简单说，它就是一套利用标准 JavaScript 和 HTML 来写组件的框架，完全贴合 Web 组件标准。也就是说，你写的代码就是浏览器原生能懂的东西，性能好，还容易维护。而且，它跟 Salesforce 以前的 Aura 框架不是对立的，而是可以很好地共存——同一个页面里，Aura 组件和 LWC 组件能够并肩工作，这叫向后兼容性。 接下来，我们还会看到官方的 Lightning 组件库，里面有很多预先做好的漂亮组件，直接拿来用就行，能帮你省下大量时间。要是你想立刻动手试试，甚至不用在本机装任何东西，我们可以利用 StackBlitz 这个在线工具，几分钟就能创建出你的第一个 LWC 组件，马上看到效果。LWC 本身还是开源的，代码公开，社区可以贡献，这让它更有生命力。 在课程里，你还会学到 API 版本控制是怎么回事，它能保证你的组件在平台升级时稳稳当当。我们也会明确列出支持的浏览器和 JavaScript 版本，这样你就知道可以放心用哪些 ES6+ 特性。另外，LWC 能在哪些 Salesforce 目标上跑、用什么样的开发工具，这些我都会详细说明。 最后，我们还会聊聊一个很实际的问题：什么情况下该选 LWC，什么情况下用 Aura 更合适。等你听完这些，心里就会有数了。LWC 的确是在 Salesforce 上构建用户界面最高效、最现代的方式，从这一章开始，咱们一起慢慢掌握它。

课程列表

本目录下共有 31 个课程

• 1

  Get Started with Lightning Web Components

  大家好，欢迎开始使用Lightning Web Components。这个介绍性章节会带大家全面认识一下 LWC，也就是在 Salesforce 平台上构建自定义用户界面的现代方式。咱们今天聊的内容很多，但我会一步一步，用最简单的话帮你们理清楚。 首先，究竟什么是 LWC 呢？简单说，它就是一套利用标准 JavaScript 和 HTML 来写组件的框架，完全贴合 Web 组件标准。也就是说，你写的代码就是浏览器原生能懂的东西，性能好，还容易维护。而且，它跟 Salesforce 以前的 Aura 框架不是对立的，而是可以很好地共存——同一个页面里，Aura 组件和 LWC 组件能够并肩工作，这叫向后兼容性。 接下来，我们还会看到官方的 Lightning 组件库，里面有很多预先做好的漂亮组件，直接拿来用就行，能帮你省下大量时间。要是你想立刻动手试试，甚至不用在本机装任何东西，我们可以利用 StackBlitz 这个在线工具，几分钟就能创建出你的第一个 LWC 组件，马上看到效果。LWC 本身还是开源的，代码公开，社区可以贡献，这让它更有生命力。 在课程里，你还会学到 API 版本控制是怎么回事，它能保证你的组件在平台升级时稳稳当当。我们也会明确列出支持的浏览器和 JavaScript 版本，这样你就知道可以放心用哪些 ES6+ 特性。另外，LWC 能在哪些 Salesforce 目标上跑、用什么样的开发工具，这些我都会详细说明。 最后，我们还会聊聊一个很实际的问题：什么情况下该选 LWC，什么情况下用 Aura 更合适。等你听完这些，心里就会有数了。LWC 的确是在 Salesforce 上构建用户界面最高效、最现代的方式，从这一章开始，咱们一起慢慢掌握它。

  查看课程
• 2

  Set Up Your Development Environment

  同学们好，我们接着来看这张幻灯片，讲的是开发Lightning Web Components——也就是LWC——的工作流程。 其实说白了，就是你可以按照自己顺手的方式来写LWC的代码。我们最推荐你用Salesforce DX这套工具，因为它功能特别全面，能帮你从本地开发、测试到部署一气呵成。不过呢，如果你更习惯用自己喜欢的代码编辑器，也完全没问题，你写完代码后可以用你自己的部署方式把组件推送到Salesforce组织里去。 但是有一个非常重要的提醒：你不能在开发者控制台里开发LWC！这个很多同学容易踩坑，一定要记牢。LWC的源码没法像以前的Aura组件那样直接在网页控制台里写。 那么这一章呢，就是要带你完整地搭建一套能顺利开发LWC的环境。我会逐个给你讲清楚这几个部分：用什么代码编辑器最合适，怎么配置代码检查工具帮我们纠错，怎么设置一个可用的Salesforce组织，怎么安装命令行工具，还有两种最主要的开发模式——一种是用临时org来快速开发，另一种是部署到非临时org做长期开发。这样一来，你就能挑一个最适合你项目的流程来动手了。 准备好了吗？我们接下来就一个一个把它搞定。

  查看课程
• 3

  Live Preview, Mobile Dev, Deployment & Best Practices

  各位同学，咱们来看这一页幻灯片，它讲的是怎么在实时浏览器预览里开发 Lightning Web 组件，也就是我们常说的 LWC。 简单来说，就是你一边写代码，一边就能在浏览器里看到组件的样子，而且这个预览是“活”的——每当你保存源代码，预览画面就会自动更新，不用你手动去部署代码，也不用你一次次点击浏览器刷新。这样带来的好处是，你可以非常快地迭代调整，就像快速地把旧组件“卸下来”、新组件“装上去”一样，几秒钟就能看到改动效果，开发效率会高很多。 这一章会把实时预览会用到的各种工具都介绍到，还会讲到怎么在移动端的场景下做开发设置，以及如何配合你自己熟悉的部署工具来工作。最后，还会总结一些 LWC 开发的最佳实践，帮大家养成好的开发习惯。 总之，学会用实时预览，你就能在更接近“所见即所得”的环境里写组件，把精力都集中在解决业务问题上，而不是耗费在等待部署和刷新的琐事上。好，这一页的内容就是这样。

  查看课程
• 4

  Create Lightning Web Components

  同学们，我们一起来看一下这张幻灯片。它告诉我们，Lightning Web 组件本质上就是一个可以重复使用的自定义 HTML 元素，而且它有自己的 API，也就是说它定义好了可以跟外部交互的方法和属性。 那一个完整的 UI 组件必须包含三个文件：一个 HTML 文件，负责定义组件的结构和展示；一个 JavaScript 文件，负责编写组件的逻辑；还有一个配置文件，用来声明这个组件的元数据，比如它要用到哪些 Salesforce 功能。 不过，如果你的组件是一个 API 模块，也就是一个纯功能库，不包含任何界面，那就可以不需要 HTML 文件，只要 JavaScript 和配置文件就够了。 这一章呢，会完整地带大家走一遍组件创建的过程，包括文件的组织方式、命名的规范、文件夹怎么放，还有 API 版本控制该怎么做。这样大家就能从零开始，一步步搭出自己的 Lightning Web 组件了。

  查看课程
• 5

  HTML Templates

  嗨，同学们，咱们接着讲Lightning Web Components里一个非常重要的部分——模板系统。你可能会问，模板系统强在哪儿？我告诉你啊，它的强处在于它用了虚拟DOM，来智能高效地渲染组件。 咱们在写LWC组件时，模板的根标签一定是 `<template>`，这个别搞错了。在这个根 `<template>` 里面，我们还可以嵌套其他的 `<template>` 标签，这些嵌套的标签可以和指令配合使用，帮我们控制哪些内容该显示、哪些内容要循环。 那从最基础的讲起，数据绑定很简单，你在模板里用花括号 `{property}` 就能把JavaScript里的属性值显示出来。比如你有一个 `message` 属性，写 `{message}` 就绑定了。 更进一步，模板里还能写复杂的表达式，比如做简单的计算，或者调用getter函数，让界面动态变化。 当你想根据条件来显示或隐藏某一块内容的时候，我们就用条件渲染。LWC提供了 `if:true` 和 `if:false` 指令，写在 `<template>` 标签上。比如你想在 `isLoggedIn` 为真时显示“欢迎回来”，就写 `<template if:true={isLoggedIn}>欢迎回来</template>`，非常直观。 列表迭代呢，用 `for:each` 指令，绑一个数组，然后用 `for:item` 指定当前项，`for:index` 指定索引，再搭配 `key` 指令给每个元素一个唯一标识，这样性能最好。像这样： ```html <template for:each={contacts} for:item="contact" for:index="index"> <p key={contact.id}>{index}. {contact.name}</p> </template> ``` 你看，从最基础的数据绑定，到稍微复杂一点的表达式，再到条件渲染和列表循环，这些全都涵盖在咱们的模板系统里，而且背后虚拟DOM会智能地只更新变化的部分，让组件跑得飞快。 好了，这个Slide的核心点就这么多，大家消化一下，下一节我们深入实践。

  查看课程
• 6

  Style a Component

  好，同学们，咱们来看这一页幻灯片。 你可能在开发 Lightning Web 组件的时候，会遇到一个问题：自己做出来的组件，怎么才能跟 Salesforce 标准界面——也就是 Lightning Experience——看起来完全一样，风格统一，不突兀呢？ 答案就在这句话里：要让组件拥有 Lightning Experience 的外观和感觉，就得依赖两个东西——，Lightning 设计系统（SLDS）， 和 ，Lightning 基础组件，。 先说基础组件。当你去用 `lightning` 命名空间下那些现成的基础组件，比如 `<lightning-button>` 、 `<lightning-input>` ，只要你一引用，它们自动就带上了 SLDS 的样式，颜色、字体、间距全都有，你完全不用自己写一行 CSS。这就是“自动获得 SLDS 样式”的好处。 但有时候，你需要在这个基础样式上做点小调整，比如换个品牌的字体或主色调，这时候就可以用到 ，样式挂钩（Styling Hooks）， 。它是一种 CSS 自定义属性，Lightning 基础组件预留了很多这样的挂钩，你只需要在组件里重新定义这些变量，就能轻松改变外观，而不需要重写整个样式。 再来说说 ，蓝图（Blueprints）， 。SLDS 其实提供了一整套设计蓝图，就像搭建积木的图纸一样。比如你想做一个卡片布局或者数据表格，照着蓝图的标记结构和样式去拼，出来的组件自然就和标准界面融为一体了。所以“根据蓝图创建组件”意思就是，按照 SLDS 的规则去搭你的 UI，保证设计的一致性。 还有一个很关键的技术点：Lightning Web 组件默认使用了 ，Shadow DOM，，它会把每个组件的样式封装起来，里面的样式不会跑出去，外面的也不会干扰里面。但这也会带来一个小麻烦：如果多个组件都想用同一套 SLDS 样式，难道每个都单独拷贝一份吗？当然不用。我们可以把 CSS 写成单独的样式表，然后通过 ，`@import`， 来共享。比如在一个 CSS 文件里用 `@import 'c/sharedStyles';` 这样就能把公共的 SLDS 样式或你自定义的样式引入到组件里，既保持了 shadow DOM 的隔离性，又复用了代码。 总结一下这张幻灯片：想让你的组件长得像 Salesforce “亲生的”，就用它提供的 SLDS 和基础组件；基础组件自带样式，用样式挂钩微调，有蓝图可照着设计，在 shadow 隔离下通过 `@import` 共享 CSS。这样你的组件就能既美观又高效。 好了，这一页的内容就是这样，听明白了吗？咱们可以接着看下一页。

  查看课程
• 7

  Composition

  大家好啊，今天我们要来系统地学习一下如何编写Lightning Web组件。这节课内容丰富，但我会尽量用简单易懂的方式，一步一步讲清楚。记住，这些概念后面都有代码示例，你可以马上打开开发环境跟着练，理解会更深。 首先我们得搞清楚组件之间的关系。在LWC里，有四个关键角色：所有者、容器、父级和子级。简单理解啊，所有者就是创建这个组件的那个人，通常也是最先把它放进模板的那个组件；容器是直接把组件包在里面的组件；而父级和子级，就更直观了，一个包裹另一个。这几个角色的能力是不同的——比如父组件能传属性给子组件，但不能直接改子组件内部的东西；所有者有更大的控制权，比如决定子组件的创建和销毁。掌握这些层次，你才能把数据流理得清清楚楚。 好，接下来就是属性。当父组件给子组件传属性的时候，一定要区别对待原始值和非原始值。原始值，就像是字符串、数字、布尔值这些简单的数据，非原始值就是对象和数组。在LWC里，有个很重要的规则：子组件接收到的对象或数组，其实是只读代理。意思就是，你不能在子组件里直接修改这些从父组件传过来的对象。如果尝试修改，控制台会报错。这背后就是我们常说的单向数据流。 这个单向数据流，指的是数据只能从上往下走，从父组件流到子组件。子组件不能反过来直接改父组件的数据。那子组件想要反馈怎么办？就得通过事件，把要改的东西告诉父组件，让父组件自己去更新。这是保持组件可预测性的核心原则。 除了属性传值，父组件还能用 `@api` 来标记子组件里的公共方法。这样父组件就能通过模板引用，直接调用子组件暴露出来的方法，比如让子组件重置表单、聚焦输入框，这就是另一种主动通信的机制。 为了写模板更方便，咱们还有 `lwc:spread` 这个指令。它可以把一个对象里的所有键值对直接展开成子组件的多个属性，省去一个一个绑定的麻烦。就像一个超快速的批量设置工具。 事件监听方面，除了静态绑定，还可以用 `lwc:on` 来动态添加事件监听器。这在处理一些条件渲染或者动态生成的组件时特别有用，让代码更灵活。 接下来是插槽系统，这是组件组合的大头。LWC支持未命名插槽，就是默认的内容投射点；也支持命名插槽，让你能把内容精确分发到不同的位置。你还能用条件渲染决定插槽内容显不显示，甚至可以监听 `slotchange` 事件，知道插槽里的内容什么时候发生了变化。 我们还会把这种基于插槽的声明式合成，跟数据驱动的方法做个对比。声明式合成呢，直接通过插槽把现成的模板片段塞进组件，适合视觉布局强、内容结构固定的情况。数据驱动则是传数据进去，让组件自己决定怎么渲染，适合样式统一但数据多变的情况。两种方式各有各的好，要看场景选用。 最后，我们会看看如何查看组件的依赖关系。这能帮你理清项目中组件之间谁引用了谁，避免循环依赖，让结构更健康。 好了，这节课的脉络就是这样。每个部分我都准备了简洁的代码例子，大家跟着敲一敲，就会感觉清晰很多。我们接着开始深入第一节吧。

  查看课程
• 8

  Fields, Properties, and Attributes

  同学们好，今天这一章，我们来系统梳理一下Lightning Web Components的核心概念——性质和反应性系统。别被这些术语吓到，其实不难，我们一步步看。 首先，咱们搞清楚三个容易混淆的词：字段、属性和属性。在LWC里，字段指的是组件类里面定义的那些变量，普通的不带装饰器的；属性呢，通常指的是用@api标记的公开属性，用来接收父组件传值；而HTML中的那些属性，比如`class`、`id`，是DOM层面的东西。简单说，字段是内部私有的，属性是公开接口，HTML属性是元素的外衣。 接下来是反应性，这是LWC的魔法核心。框架会观察字段的变化，一旦值变了，界面就自动重新渲染。这就像你厨房的灯，开关一按，灯立马亮——响应式地反映状态。默认下，对字段的简单赋值会触发这个机制，但对象或数组的深层变化呢？就需要@track来帮忙了，它能让框架深入观察，好比放大镜，看透对象内部的变动。 说到公开属性，@api是关键。用它装饰的属性，父组件就能传递数据进来。比如你在JS里定义一个`@api message`，HTML里就用kebab-case写成`<c-child message="你好">`。注意命名约定：JS用驼峰式，HTML用连字符分隔，千万别搞混了。 DOM属性访问也很实用。通过`this.template.querySelector`，你就能拿到模板里的元素，直接操作它，就像指点房间里的家具一样方便。 再记住，所有组件都继承自LightningElement基类。它不仅提供生命周期的钩子，还有一堆特有属性，像`this.label`，这些是LWC贴心地帮你准备好的。 还有反射的Web API模式，就是把组件属性同步到HTML元素上，比如为了无障碍访问，你把`ariaLabel`属性反射出去，屏幕阅读器就能识别。布尔属性也类似，像`checked`，直接切换，简洁高效。 getter和setter是数据转换的利器。你可以在设置值时做验证，或者在获取时格式化，比如把时间戳转成可读日期。这样数据进出都有把关。 最后，千万别忽略属性之间的依赖关系。一个属性变化可能影响另一个，用getter或在回调里手动更新，确保逻辑不乱。 这一章的内容虽然多，但都是实战必备。记住这些模式，你的组件设计会又灵活又可靠。好了，咱们下节课再深入具体案例，谢谢大家。

  查看课程
• 9

  JavaScript

  好，同学们，我们这一章要深入了解 Lightning Web Components 里的 JavaScript 全面参考。可以把它当作你编写 LWC 组件的“语法说明书”。因为每一个 LWC 组件，都必须有一个以 ES6 模块形式写出的 JavaScript 文件，所以掌握扎实的 JavaScript 基础，是第一步。 我们先从最基本的现代 JavaScript 功能聊起。包括数组的各种方法、简洁的箭头函数、类、模块、对象，以及处理异步操作的 Promise 和 async/await。这些你可能在标准 JavaScript 里学过，但在 LWC 里它们用得尤其多，比如用数组的 map 去渲染列表，用 async/await 去等待服务端数据。一定要把这些基础打牢。 有了这些基础，我们再来看组件之间怎么优雅地共享代码。在 LWC 里，我们完全依赖 ES6 模块的导出和导入机制——也就是默认导出和命名导出。你有两种常见的共享模式：一种是在同一个文件夹下，多个组件直接引用一个公用的 JS 文件；另一种是把代码封装成所谓的“API 模块组件”，让其它组件通过标准的模块导入来使用。这样做很清晰，也更容易复用。在这个过程中，编译器会自动解析入口点，同时也支持补充文件的导出。但要特别小心循环导入的问题，就是 A 引用 B，B 反过来又引用 A，这会导致代码运行混乱，我们一定要避免。 接着，我们经常需要引入第三方库，比如图表库 D3。在 LWC 里，你不能像传统前端那样随意插一个 script 标签。正确做法是：先把第三方库上传成静态资源，然后使用平台提供的 platformResourceLoader 去加载它。如果你需要对某个元素进行精细的操控，比如让 D3 去操作 SVG，就要使用 lwc:dom="manual" 这个指令，保护那些元素不被 LWC 自动重绘。当然，用第三方库时还要注意 NPS 和 LWS 的合规性，确保你的代码符合 Salesforce 的安全和性能要求。 然后，我们再来探索怎么调用 API 获取数据。最常用的就是 Fetch API。通过它，你可以非常方便地调用 Salesforce 自己的数据接口，比如走 Apex 暴露的 REST 接口，或者调用外部的第三方 API。异步请求可是开发数据驱动组件的核心。 再往下，我们学习一个很酷的功能——动态组件实例化。有时候你不想写死一个组件，而是想根据运行时的数据，决定显示哪个组件。这时候，我们就可以使用 lwc:component 和 lwc:is 这两个特殊属性，在模板里动态地创建和渲染不同的组件。这让你的界面变得极其灵活。 最后，我们还会简单了解一下开发人员预览中的 TypeScript 类型定义。虽然目前还是预览阶段，但对于大型项目来说，类型定义能帮我们提前发现很多错误，让开发体验更好，值得大家关注。 好了，这些就是本章要覆盖的核心内容。从基础语法到代码共享，再到第三方库、API 调用、动态组件，甚至未来的 TypeScript 支持。一步步掌握它们，你就拥有了构建复杂 LWC 组件的完整知识体系。我们接下来逐一深入。

  查看课程
• 10

  Work with the DOM

  同学们，今天我们来看一个非常核心的概念，这个在Lightning Web Components开发里几乎每一步都会遇到，就是，DOM，。 DOM，全称是文档对象模型，你可以把它理解成整个HTML页面的一个活地图。有了这个地图，我们就能用代码去读取、修改页面的内容、结构，甚至是每个元素的样式。LWC之所以强大，就是因为它给了我们好几种不同的方式去和这个DOM打交道，也就是它支持，多种DOM模式，。 具体是哪几种呢？我们一个一个来看，很好理解。 首先是，原生Shadow DOM，。这个“Shadow”是影子的意思，它其实是浏览器自带的一种封装机制。组件里面的DOM结构、CSS样式，全部被包在一个独立的影子里，外部的样式进不来，里面的样式也漏不出去。对于现代浏览器，LWC默认就用它，让组件之间完全不打架。 那如果用户还在用一些老旧的浏览器呢？那些浏览器根本不认识影子DOM。这个时候，LWC会启用一种叫作，合成阴影，的模式。英文是Synthetic Shadow，你可以把它看成LWC专门为老浏览器打的一个补丁，用JavaScript来模拟出影子DOM的封装效果。对我们开发者来说，写代码的方式几乎一样，这是LWC帮我们处理好的兼容性问题。 第三种就是，Light DOM，，光DOM。这个和影子DOM正好反着来，它完全没有封装。组件的内容直接就放在全局的页面DOM里，没有任何隔离。好处是你可以从外部用全局CSS直接定义组件内部的样式，用起来很简单。但缺点也很明显，就是样式容易互相干扰。如果你需要那种轻松的全局控制，或者你正在为一个第三方库做包装，那Light DOM可能会派上用场。 最后还有一个已经在测试阶段的，混合阴影模式，。它的目标是帮助大家把老旧的合成阴影组件，逐步地、安全地迁移到真正的原生影子DOM上，而且不需要一次性大改。你可以让一部分组件先用原生封装，其他的先继续用合成模式，非常灵活。 了解了这四种模式，你可能会好奇：那在不同的模式之间，我们去读写元素、做样式这些操作，到底有哪些不一样的地方呢？这正是我们这一章要深入探讨的内容。 我们后续会覆盖的范围非常全，包括：不同模式下怎么安全地拿到元素；影子DOM内部的树形结构到底长什么样；CSS的作用域在不同模式下差别有多大；还有跨模式的插槽，也就是slot，它的行为会怎么变；以及事件是如何重定向的，也就是事件冒泡出去以后，源头变成了谁。当然，我们也不会忽略可访问性，怎么去做作用域插槽和样式，以及最实用的，怎么在各模式之间平滑转换。 别担心，这些点我都会配着详细的代码示例和实用指南，手把手地带你掌握LWC中DOM操作的一招一式。好了，这一页概览就先到这里，我们来一步步往下走。

  查看课程
• 11

  Access Salesforce Resources

  嘿，同学，今天咱们聊聊 LWC 里特别好用的那些“开箱即用”的模块，它们都以 `@salesforce` 开头，能让你直接访问 Salesforce 平台的各种资源，省去很多麻烦。 首先，你在安装程序里上传的静态资源，比如图片、样式、JS 文件，想用在组件里怎么办？直接用 `@salesforce/resourceUrl` 导入就行，它会给你生成一个可用的 URL。类似的，内容资产文件也有专门的 `@salesforce/contentAssetUrl`，专门处理文件库里的资产，用起来非常顺手。 有时候你需要把 SVG 图标之类的小图形直接插在模板里，而不是作为外部文件？没问题，VG 资源可以直接嵌入到 HTML 模板中，或者你也可以把它当静态资源导入，非常灵活。 再说多语言支持，用 `@salesforce/label` 就能轻松访问自定义标签，这样你的应用就能根据用户的语言显示不同的文字，国际化简直太省心了。而 `@salesforce/i18n` 这个模块更厉害，它提供了地区、货币、时区、数字格式等等和国际化相关的数据，日期、金额格式化瞬间搞定。 想知道当前登录用户的信息？`@salesforce/user` 直接返回用户的 Id、姓名、是否管理员等，不用再去查数据库。在 Experience Cloud 站点里，`@salesforce/community` 和 `@salesforce/site` 能拿到社区或站点的详细信息，做自定义导航、显示站点名字什么的非常方便。 权限检查也简单，`@salesforce/userPermission` 和 `@salesforce/customPermission` 可以让你在代码里判断当前用户有没有某个标准权限或自定义权限，控制组件的显示和功能。 最后，如果你的组件需要适配桌面还是移动端，用 `@salesforce/client/formFactor` 就能知道当前客户端的设备类型，轻松实现响应式。 最关键的一点，这些导入在代码编译时 Salesforce 就会帮你检查，如果有拼写错误或者引用不存在，直接报错，避免了运行时才发现问题，大大提升了可靠性。 好了，这些模块就是 LWC 给你准备好的趁手工具，直接拿来用，让你的开发又快又稳。咱们下节课继续。

  查看课程
• 12

  Component Accessibility

  同学们，这一讲我们来聊一聊Lightning Web Components的无障碍设计。我们都知道，一个好的应用应该让所有人都能用，包括有各种障碍的朋友。所以Salesforce在设计Lightning基础组件的时候，就已经把无障碍功能内置进去了，比如按钮、表单这些基础组件，你拿来直接用，它就自动帮我们做了很多可访问性的处理。 但关键是我们自己写的自定义组件，就得我们自己操心了。这一页Slide其实给我们汇总了一个完整的无障碍工具包，也就是我们在写自定义LWC的时候，可以从哪些方面去保障可访问性。 首先，最基础的就是HTML属性，比如给输入框加个标签label，或者用aria-label给元素提供一个文字描述，这些是最常用的无障碍手段。 然后，更强大的一类是ARIA属性。在LWC里，我们可以直接在模板中用camelCase的方式写ARIA属性，比如ariaLabel，它会映射到标准的aria-label。而且还有默认的ARIA值和静态ARIA值的设定，能帮我们更精细地控制读屏软件的理解。 再往下，有个很实用的技术：在模板之间链接ID。因为我们LWC的Shadow DOM会隔离样式和DOM结构，所以如果两个不同的组件之间需要引用ID，我们可以用lwc:dom="manual"这种轻量DOM操作方式，让ID能够跨边界关联起来，保证无障碍的关联关系不会断掉。 焦点管理也是无障碍的核心。用tabindex控制键盘导航顺序，用delegatesFocus让组件能够把焦点委托给内部的第一个可聚焦元素，这些都能让键盘用户流畅操作。 另外，整个组件的生命周期我们也要心中有数，从constructor到errorCallback，每个钩子里都不能乱操作，否则可能破坏无障碍状态。比如在constructor里不要操作DOM，在renderedCallback里可以设置焦点，但要注意时机，避免重复渲染搞乱焦点。 最后是总的最佳实践：遵循WCAG指南，也就是网页内容无障碍指南的国际标准，同时利用Salesforce的SDS蓝图来设计界面，这样视觉上和无障碍实现上都能保持一致。 简单总结一下，就是基础组件已内置无障碍，自定义组件要自己动手，运用HTML属性、ARIA映射、ID链接、焦点管理，配合正确的生命周期写法，再参照WCAG和SDS，就能做出包容性很好的组件。 好了，这节就讲到这里，大家可以在练习里亲手试试给组件的ARIA属性和焦点，感受一下。

  查看课程
• 13

  Third-Party Web Components (Beta)

  同学们，今天我们来聊聊 Lightning Web Components 里一个挺有意思的新功能，就是用别人写好的、不是 LWC 的 Web 组件。不过要注意，这个功能目前还在 Beta 阶段，后面可能会有变化。 首先，想用这种第三方组件，必须先把你的 Salesforce 环境里那个叫 LWS 的服务打开——Lightning Web Security 得启用。而且有个小限制，Lightning 原生的按钮组件是不支持直接嵌第三方 Web 组件的，这点稍微记一下。 要把这些外部组件弄进来，有两种办法。第一种，你把它当成一个静态资源上传到 Salesforce，然后用一个特殊的工具叫 `platformResourceLoader` 去加载它。第二种呢，是直接把它做成一个 LWC 模块来添加。两种都可以，看你们项目怎么方便怎么来。 这些外来的组件，它们还是遵循标准的 Web Components 规矩来写的，比如要继承 `HTMLElement`，要有自己的生命周期方法，像 `connectedCallback` 这种，然后用 `customElements.define()` 注册一下，一般还会给它挂一个自己的影子根，也就是 shadow DOM。 那数据怎么传给它们呢？有三种路子：可以用普通的 HTML 属性，用组件的属性，或者用一个比较方便的指令 `lwc:spread`，把一串数据一次性传进去。如果你要往组件里面塞一大块内容，比如 HTML 片段，就用插槽，也就是 slot。 绑定事件的时候要注意，只能用 XML 格式的名字，不要写驼峰那种。样式这块也分情况：要是组件用了 shadow DOM，你就通过 CSS 自定义属性来传颜色、尺寸这些；要是它用的是 light DOM，那就可以用加了作用域的 class 来写样式。 对了，如果你的组件还要在手机上跑，那就还得遵守 Salesforce 给移动端准备的另外一套指导原则。 最后再提醒一下，这些东西都还在 Beta 测试，将来正式发布的时候很可能会调整，所以现在咱们先了解思路，别在生产环境大规模用。 好，这一页的核心差不多就这些。有什么问题随时问我。

  查看课程
• 14

  Work with Lightning Base Components

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

  查看课程
• 15

  Communicate with Events

  同学们，今天我们来聊聊 Lightning Web Components 里的事件机制。这部分特别重要，因为组件之间怎么通信，就靠它了。大家可以把事件想象成在组件树里向上冒泡的一个信号，就像小时候玩的传话游戏，从下往上传递信息，而数据向下流则是通过属性，也就是我们常说的“props down, events up”。 首先，LWC 的事件是建立在标准 DOM 事件系统之上的，这让我们用起来很自然。但咱们推荐使用 `CustomEvent` 这个接口来创建事件。为什么呢？因为它跨浏览器表现一致，几乎不需要额外设置，而且能通过 `detail` 属性方便地携带数据。你想想，如果你自己造轮子，还得处理各种浏览器差异，多麻烦。 好，我们来一步步看事件的生命周期。 ，第一步，创建事件。， 很简单，用 `new CustomEvent` 构造函数就行。比如： ```js const myEvent = new CustomEvent('my-event', { detail: { message: '你好' } }); ``` 这里要注意命名约定：事件名称要使用全小写字母加连字符，不要用驼峰，更不要加“on”前缀。因为 HTML 模板里监听时，我们会用 `on` 开头，如果你事件名前面又加一个 `on`，就成 `onon...` 了，会很混乱。所以，事件名叫 `my-event`，监听时写 `onmyevent`。记住，事件名里的大写字母会自动转成小写，所以别紧张。 ，第二步，调度事件。， 用 `this.dispatchEvent(myEvent);` 就能把事件发出去。它会沿着组件层级往上冒泡，父组件就能收到。 ，第三步，处理事件。， 在父组件的模板里，咱们可以声明式地监听，就像这样： ```html <c-child onmyevent={handleMyEvent}></c-child> ``` 只要子组件派发了 `my-event`，父组件的 `handleMyEvent` 函数就会被调用。而且，你还可以用 `lwc:on` 指令来动态绑定监听器，或者一次绑定多个事件处理器，非常灵活。比如： ```html <template lwc:onmyevent={handleOne} lwc:onmyevent={handleTwo}> <!-- 内容 --> </template> ``` 这样同一个事件可以触发多个处理函数。当然，我们也能用命令式的方法，在 JavaScript 里通过 `addEventListener` 直接监听某个元素，比如 `this.template.addEventListener('my-event', this.handleMyEvent.bind(this))`，但别忘了在组件销毁时用 `removeEventListener` 清理，防止内存泄漏。 接下来，我们谈谈事件传播。默认情况下，LWC 里的事件只在组件模板的阴影边界内冒泡，不会穿透 Shadow DOM。如果你想让事件穿透影子边界，必须显式设置 `composed: true`，同时还要搭配 `bubbles: true`，这样事件才能一路向上，穿过各个影子根，到达最外层。就像这样： ```js new CustomEvent('my-event', { detail: { ... }, bubbles: true, composed: true }); ``` 但是要注意，合成事件（composed events）可能会接触到不属于你组件的 DOM 范围，所以要小心数据泄露或者意外触发外部监听器。 说到跨 DOM 通信，有时候你的组件不在同一个 DOM 树里，比如在闪电页面里放了好几个独立组件，这时冒泡机制就不行了。Salesforce 提供了 ，Lightning Message Service (LMS)，，允许你在任意组件之间通过发布/订阅模式传递消息，无论它们在页面的什么位置，甚至跨框架。LMS 使用 `MessageContext` 和 `publish`、`subscribe` 等方法，这是专门用来解决跨组件强耦合问题的。 最后，我给大家总结一些最佳实践： - 始终优先使用 `CustomEvent` 和使用 `detail` 传数据。 - 事件名用小写字母加连字符，保持一致性。 - 谨慎使用 `bubbles: true` 和 `composed: true`，只在确实需要穿透边界时才开启，否则就在组件内部处理。 - 尽量用声明式监听 `on...`，它更清晰，也更符合 LWC 的设计哲学。只有在处理第三方库或特殊需求时，才用命令式监听。 - 记得清除监听器，避免内存问题。 - 跨组件通信，如果组件之间没有直接的父子关系，考虑使用 LMS 而不是层层传递事件。 好了，今天的事件系统就讲到这里。大家只要记住核心思想：事件向上冒泡，携带数据；谨慎配置传播；灵活选用声明式和命令式；跨作用域用 LMS。动手写几个小例子，很快就熟悉了。有疑问随时问！

  查看课程
• 16

  Work with Salesforce Data

  同学们，今天我们来聊聊在Lightning Web Components里怎么优雅地处理数据。Salesforce很贴心地帮我们把方法分成了四层，就像搭积木一样，从最简单到最灵活，层层递进。记住一个大原则：做事情永远从最简单的方案开始，够用就不必复杂化。 第一层，叫基本组件。就是那些开箱即用的闪电记录表单、编辑表单、视图表单。你只需要告诉它处理哪个对象、哪个记录，界面、布局、字段验证、错误提示全都自动生成，完全是靠元数据驱动的，几乎不用写一行逻辑代码。 第二层，是Lightning Data Service提供的线适配器。比如getRecord、getRecords，还有新出的GraphQL适配器。它们用起来就像声明一个数据源，组件会自动响应式地获取和更新数据，数据变了，界面也跟着刷新，非常省心。 第三层，是命令式操作的函数。当你需要明确地、主动地去创建、更新或者删除记录时，就用createRecord、updateRecord、deleteRecord这些方法。它们会让你更直接地控制调用时机，比如在用户点击按钮后才执行。 第四层，是给那些高级场景准备的：比如销售云不支持的对象、需要跨多个记录做复杂事务，或者你想要最大自由度的时候。这时你可以调用Apex方法，完全由自己掌控逻辑。 这四层里，前三层都属于Lightning Data Service服务。它有个特别棒的好处——自带共享缓存。意思是同一个数据在页面不同组件里只加载一次，而且能自动检测变化，你不用手工刷新，更不需要为了存取单条记录去写Apex代码，很大程度上减少了API使用量。 这一章呢，我们会完整地展示一个数据访问的决策树，帮你快速判断该用哪一层。另外，每一层都会给你清晰的代码例子，保证你听完就能动手。不必担心，我们一步一步来。

  查看课程
• 17

  Display Record Data in a Table

  同学们，我们来看这张幻灯片，它介绍了 Lightning 数据展示相关的两个核心组件：，lightning-datatable， 和 ，lightning-tree-grid，。 首先，lightning-datatable 是一个标准的表格组件，它基于 Salesforce Lightning 设计系统（也就是 SLDS）的蓝图来展示行和列，外观和交互都非常统一。而 lightning-tree-grid 顾名思义，是在表格基础上扩展出树形结构，它可以展示带有父子关系、可以展开和折叠的分层数据，就像你在文件夹里一层层打开那样。 这两个组件有不少共同点：都支持自定义数据类型，也就是说你可以自己定义某一列怎么显示数据；都支持在表头或行上添加操作按钮；都可以让用户拖动调整列宽；都支持行选择并显示行号。这些是它们基础的能力。 当然，它们也有各自的特色。lightning-datatable 额外支持，列排序，、，内联编辑，（直接在单元格里修改数据）以及，无限滚动，（滚动到底部自动加载更多数据）。而 lightning-tree-grid 的独特之处就是那套可扩展的子行，让数据带有层次结构。 有一点需要特别注意：，这两个组件目前都不支持移动设备，，也就是说在手机浏览器或者 Salesforce 移动 App 里，你可能需要换用其他方案来展示数据。 本章内容会完整覆盖从最基础的表单显示开始，一路深入到自定义数据类型、内联编辑、可访问性（无障碍设计）以及性能优化，带领大家走过整个生命周期。 最后，关于怎么创建自定义数据类型，我们有两种方式：一种是直接继承 ，LightningDatatable， 或 ，LightningTreeGrid， 类，用代码扩展它们；另一种是利用插槽（slot）来动态传递自定义的渲染内容，这样加载起来更灵活。 好，这个幻灯片的核心就这么多。大家先有一个整体印象，后面我们逐一深入。

  查看课程
• 18

  Use the Wire Service to Get Data

  嗨，同学们，咱们今天来聊聊 Lightning Web Components 里一个特别核心的概念——Wire 服务。你可能会问，Wire 服务是什么？简单说，它就是 LWC 专门用来从 Salesforce 后端取数据的机制，而且它取来的数据是，不可变的，，会以流的方式推给你的组件。你可以把它理解成一个智能的数据管道，一旦数据有变化，它就会自动把新数据推给你，你啥都不用干。 那具体怎么用呢？我们在组件的 JavaScript 类里，用 `@wire` 这个装饰器，指定一个叫做 ，LDS wire 适配器， 的东西。这些适配器底层是构建在 UI API 或者 Connect API 之上的，不同的适配器返回的数据形状也不一样。有的适配器返回一条记录，有的返回列表，有的返回元数据，你选哪个取决于你想要什么。 在你决定用一个 wire 适配器之前，老师给你一个非常重要的提醒：一定要先看看有没有更简单的解决方案，比如系统自带的 `lightning-record-form`、`lightning-record-edit-form` 这些基础表单组件。它们内部已经帮你封装好了很多复杂逻辑，如果你只是想快速做一个查看或编辑记录的界面，直接用这些组件可能几行标签就搞定了，根本不需要你自己手写 wire 适配器。而且，当你确实需要写 wire 适配器时，记住一个原则：，始终选择那个能返回你所需最少数据的适配器，。别动不动就拉一大堆字段下来，只取你真正用得到的，性能才会好。 接下来，咱们这一章会带着你把完整的 Wire 服务学透。咱们会讲到： - 两种写法的语法：一种是直接用适配器的 ID，比如直接写 `@wire(getRecord)`；另一种是带配置属性的写法，像 `@wire(getRecord, { recordId: '$recordId', fields })`，这种可以动态传参。 - 怎么从 `@salesforce/schema` 模块里导入对象和字段的引用，让你在写字段列表时安全又方便，甚至还能处理关联字段。 - 一个特别重要的概念：，反应式动态属性，。你会看到我们在属性前面加上一个 `$` 符号，比如 `$recordId`，这样当这个属性的值变化时，wire 适配器就会重新请求数据，完全是响应式的。 - 接收到数据后，咱们有两种处理方式：一种是把结果直接装饰到一个，属性，上，自动拿到它的 `data` 和 `error`；另一种是装饰到一个，函数，上，这样你可以在函数里写自己的业务逻辑，比如何时显示加载器、何时处理返回的数据。 - 咱们还会深入理解数据在整个组件生命周期里是怎么流动的，从 `constructor` 到 `renderedCallback`，知道数据在哪个阶段可用，才能写出更稳健的代码。 - 当然，少不了最实用的例子，比如用 `getRecord` 拉取一条记录，并展示在界面上。 - 还有错误处理，我们要学会用 `FetchResponse` 对象来优雅地处理网络错误、权限问题等等。 - 最后，我们会把这些有线的数据和基础组件（像模板里的输入框、列表）结合起来，做出完整的功能。 同学们，Wire 服务是 LWC 数据交互的基石，掌握它，你就能灵活高效地和 Salesforce 数据打交道了。接下来，咱们就一步一步把这些内容吃透。记得跟着我的节奏，把每个例子都动手敲一遍，你很快就能得心应手。好，咱们开始吧！

  查看课程
• 19

  Manage State Across LWC Components

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

  查看课程
• 20

  Call Apex Methods

  同学们，今天咱们来聊聊在Lightning Web Components里怎么跟后端数据打交道。想象一下你有个乐高城堡，LWC就是那些五颜六色的积木，但光有积木不行，你得有图纸和材料——这就是Apex的作用。 首先，为什么需要Apex？你看，LWC本身提供了很多现成的基础组件，比如“闪电数据表”啦，“记录表单”啦，还有叫“LDS”（闪电数据服务）的适配器，它们像拧螺丝的小扳手，能搞定简单的数据读写。但有时候，你需要拧的是异形螺丝，或者你想一次性拧好多螺丝，甚至边拧边唱歌——这些基础工具就不够用了。这时候，Apex就闪亮登场了，它是你工具箱里最灵活的瑞士军刀，能写出任何你想要的复杂业务逻辑，比如跨多个对象计算佣金、集成第三方系统、或者完成一连串有条件的更新。 那么，怎么让LWC调用到Apex呢？有几个规矩得记住。第一，你写的Apex方法必须是静态的，就像班级里公用的拖把，谁都能用，而且它得用public或者global关键字公开出来。第二，必须给它贴上一个“@AuraEnabled”的标签，这就好比在拖把上写“可借出”，不然别人找不到。现在咱们有两种方式去“借”这个拖把。 第一种叫响应式调用，用@wire装饰器。想象一下，你有个自动饮水机，每次你换一桶新水，它自动就加热了。@wire就是这样，你告诉它一个Apex方法，再给它一些参数，只要参数一变，比如当前记录ID变了，它立刻重新跑去后端取最新数据，并填充到一个属性里，整个过程你都不用操心。但要记住，被@wire绑定的Apex方法必须开启缓存，也就是在注解后面加上(cacheable=true)，否则它会闹脾气不工作。这种缓存能把你取回来的数据放在客户端存着，下次再要就不用跑一趟服务器了，速度飞快。 第二种叫命令式调用，像你去餐厅点菜。你喊服务员：“给我来一份宫保鸡丁！”服务员才去下单，你可以完全控制什么时候点、点完怎么做。命令式调用不受cacheable限制，所以特别适合做写入、更新、删除这些会改变数据的操作，我们把这类操作叫“突变”。调用时，你把Apex方法当作一个Promise，然后then、catch地处理结果。 参数怎么传呢？早期Salesforce是用Map传参，容易拼错键名。现在推荐直接用对象属性传，例如 { accountId: '001...', amount: 100 }，这样更直观，编译器还能帮你检查。框架很聪明，它会把短时间内发起的多个Apex调用打包成像火车车厢一样，一次发出去，最多拉2500节车厢，这叫“boxcar请求”，减少了网络来回的次数，效率很高。 刚才说到缓存，如果你通过@wire拿到了数据，然后用户在页面上做了修改，数据变了，怎么让UI刷新呢？有两个贴心的小助手。一个是refreshApex()，专门用于刷新有线数据，你只需要把之前@wire生成的那个响应对象传给它，它就重新请求。另一个叫notifyRecordUpdateAvailable()，当你用命令式调用做完了增删改，LDS缓存里存的老数据就过时了，得喊一声“喂，数据更新啦！”，相关组件就会自动刷新。两者配合使用，界面就能保持最新。 有些Apex操作特别耗时，比如生成一个大报告，可能会超时。这时候可以用“延续”（Continuation），把长时间任务丢给异步处理，然后拿到一个标识，等服务器好了再回来取结果。 安全性方面绝对不能马虎。从API 67.0版本开始，Apex默认以用户模式运行，也就是严格执行当前用户的字段级安全（FLS）和对象级权限（CRUD）。以前经常需要在代码里手动加WITH SECURITY_ENFORCED，现在默认就帮你做了，省心又安全。另外，别忘了组织的共享规则也会自动应用，用户只能看见他能看的数据。 最后，错误处理。别把红通通的系统错误直接甩给用户。在Apex里，你可以用try-catch捕获异常，然后抛出一个特殊的AuraHandledException，把友好的提示信息传回去。LWC这边用catch就能拿到这个消息，温柔地展示给用户，而不是吓人的堆栈跟踪。 总结一下，Apex是LWC最强大的数据后盾，当你觉得基础组件不够用，就放心大胆地用它，记住方法要静态、公开、打注解，调用分有线自动和命令手动，传参用对象，有缓存就配refreshApex，有写入就喊notifyRecordUpdateAvailable，安全默认到位，错误温柔处理。这样，你的组件就能又聪明又强壮了。好，这讲就到这里，大家消化一下。

  查看课程
• 21

  Refresh Component Data with RefreshView API

  各位同学，现在我们来聊聊 ，RefreshView API， 和 ，lightning/refresh， 这个模块。 那它到底是干嘛用的呢？简单来说，就是给你一种标准的方法，，在不重新加载整个页面的情况下，只刷新组件里的数据，。比如你做了一个列表，用户点了一下“刷新”按钮，你肯定不想让整个页面“轰”一下重新加载，那样体验很差。RefreshView 就是专门解决这种局部数据刷新的。 它支持两种刷新场景：一种是，用户主动触发的，，比如按钮点击；另一种是，应用程序自己调用的，，比如重新登录后、下拉刷新这些情况。 那这个机制是怎么运转的呢？它在架构上分三个角色——你可以理解为一个配合默契的小团队： - ，第一个角色：触发者，。任何一个组件都可以通过触发一个叫 `RefreshEvent` 的事件，来发出“我需要刷新”的信号。 - ，第二个角色：容器，。页面上会有一个“大总管”组件，它通过 `registerRefreshContainer` 来注册自己，专门接收刷新事件，然后统一协调整个刷新流程。 - ，第三个角色：参与者，。那些真正拿着数据、需要刷新的组件，会通过 `registerRefreshDeliverManager` 注册一个处理程序。当容器协调下来后，这些处理程序就去执行真正的数据刷新操作。 这样设计的好处是，刷新的逻辑是高度解耦的，不管你页面结构多复杂，都能很优雅地完成局部刷新。 另外，这个 API 是用来，替代过去 Aura 框架里的 force:refreshView， 的。如果你之前在 Aura 里用过，那现在转到 LWC，思想是类似的，但实现更现代。 还要注意一个很重要的点：，Lightning Data Service，也就是 LDS，天然支持 RefreshView API，。如果你用的是 `getRecord` 这类适配器，数据刷新它会自动帮你处理好。但是，如果你用的是自定义 Apex 方法，或者是 GraphQL 查询，那就必须自己动手了——在注册的刷新处理程序里面，要显式地去调用 `refreshApex` 或 `refreshGraphQL`，才能真正把数据拉回来。 最后，今天我们看的这一页只是一个开头。在这一章的后半部分，我们还会深入学习怎么通过，命名凭证从 Apex 调用外部 API，，以及一套完整的错误处理机制，覆盖 JavaScript、LDS 和 Apex 的各种错误。这样你写的组件才能既灵活又健壮。 那好，关于 RefreshView 的基本概念我们就先说到这儿。同学们可以稍微消化一下，想想自己项目里有哪些场景用得到它。有问题随时提，我们停下来聊一聊。

  查看课程
• 22

  Use Components in Salesforce Targets

  好了，今天我们来看一个非常实用的知识点：怎么通过一个简单的配置文件，让你的 Lightning Web 组件在不同的 Salesforce 界面里都能使用。 你开发的每一个 LWC 组件，除了那个 .js 和 .html 文件之外，还有一个名字后面带着 .js-meta.xml 的配置文件。这个文件里的元数据，就像是组件的“身份证”和“许可证”。你告诉 Salesforce：“我这个组件可以放到哪些地方去。” 在这个配置文件里，有一个特别重要的节点，叫 targets，就是目标。你在这里列出你允许这个组件出现的位置。现在可以选的目标还真不少，比如最常见的 Lightning 应用构建器，也就是你拖拖拽拽搭建页面那个工具；还有 Experience Builder，就是建客户社区门户用的。如果你做流程自动化，也可以让组件出现在 Flow Builder 的屏幕流程里。还有 Email Builder 里也能用，这样你就能在邮件内容里插入自定义组件。做数据分析的 CRM Analytics 仪表板、自定义选项卡、控制台应用里的侧边栏、快速操作、甚至在 Outlook 和 Gmail 的集成面板里，都可以通过配置目标来开放。 对了，如果你做的组件要打包放到 AppExchange 上分发，那这个配置文件还会关系到命名空间前缀，以及你是否把组件暴露出去，也就是 isExposed 这个设置。如果 isExposed 没设为 true，哪怕你写了 target，用户在构建器里也搜不到你的组件。此外，假如你想通过 Apex 代码做一些许可控制，也跟这里的设定有关。 还有一点特别好用，就是组件能够感知自己当前所在的环境。你只要在 JS 里用 @api 装饰器声明几个属性，就可以拿到页面上的上下文信息。比如用 @api recordId 就能拿到当前记录页面上那条记录的 ID，用 @api objectApiName 能拿到对象名，比如是 Account 还是 Contact。用 @api flexipageRegionWidth 还能知道当前组件所在区域的宽度，这样你可以做响应式布局。 除了这些常规目标，有两个比较特殊的环境值得注意。一个是在预测页面里，你可以让组件订阅消息通道，实时更新预测数据；另一个是邮件内容构建器，它环境很受限，不能加载外部资源，所以你得确保组件轻量又安全。 其实，我们这一整章的核心，就是让你彻底掌握如何通过 .js-meta.xml 这个配置界面，来控制组件在 Salesforce 里的部署范围和行为。也就是说，写好一个功能组件只是第一步，通过这个配置文件，你才能真正让它出现在正确的地方，给别人用起来。

  查看课程
• 23

  Experience Cloud Sites

  同学们，今天我们来聊聊，怎么给 Experience Builder 网站创建自定义的 Lightning Web 组件。这个内容看起来有点多，别担心，我会慢慢讲清楚，就像讲故事一样，让你一听就懂。 首先，Experience Builder 就是咱们建站的那个拖拽工具。你做的自定义组件，要想能在里面拖来拖去，就得告诉平台：我这个组件能放在哪儿、能干什么。这个秘密就藏在组件的配置文件 `.js-meta.xml` 里。在文件里，你可以配置几个重要的“目标”，也就是 target。比如，你写个组件只想展示在某个页面上，那就用 `lightningCommunity__Page` 这个目标，这样它就能被拖到任意页面里了。如果你想做一个布局组件，用来控制页面的结构，比如左右分栏，那就要指定 `Page_Layout` 目标。要是你想做一套主题皮肤，让站点整体换风格，那就用 `Theme_Layout` 目标。最后还有一个叫 `Default` 的目标，它表示这个组件有一些属性可以在属性面板里直接修改，比如文字颜色、背景图什么的。这四种目标，基本覆盖了你在建站时拖拽组件的所有场景。 接下来，你会发现有些时候，自带的属性编辑界面太简单了。比如你想让用户选颜色用色盘、上传图片有预览，那就要用到“丰富的属性编辑”能力。这就要靠一个叫 `LightningTypeBundle` 的东西。它不是单一的组件，而是一个捆绑包，里面有两个核心文件：`schema.json` 和 `editor.json`。schema 文件用来定义这个属性的数据类型和结构，editor 文件则指定用哪个自定义编辑器来编辑它。自定义编辑器本身也是一个 Lightning Web 组件，只不过它要遵守一套属性编辑器契约，说白了就是实现约定的接口方法，让平台知道你如何收发值。这样，你的组件属性面板就能出现一个漂亮的专用编辑器，用户体验一下子就不一样了。 可能有同学会问，如果我的属性很多，有层级，怎么办？别急，咱们还可以用“标准布局定义”来组织复杂的属性表。就是把属性按分组、分区排列好，让管理员在配置时一目了然。你只需要在组件里引用编辑器属性去指定用哪个自定义编辑器，再用类型属性去绑定你定义的那个自定义属性类型，一切就串联起来了。 还有一点要特别提醒，如果你以前的项目里用过旧版的 `Legacy ExperiencePropertyTypeBundle`，现在必须要迁移到新的 `LightningTypeBundle` 模式。因为老的方式已经不推荐了，未来可能会被移除，所以趁现在赶紧换过来。迁移的原理就是把老的属性定义转成新的 schema 和 editor 组合。 最后，我们再来回顾一下整个开发生命周期：你创建组件，写好 `.js-meta.xml` 设好目标；如果需要增强编辑体验，就创建 `LightningTypeBundle` 做自定义属性类型，并开发编辑器组件；接着用标准布局把属性编排清爽；然后就可以在站点里拖拽使用，调整属性，看效果。整个过程就是设计、开发、配置、部署，一步步来，就像搭积木一样。 好了，今天关于 Experience Builder 自定义组件的核心就讲这么多。记住，关键是配置目标和自定义属性编辑，这样你能做出既强大又好用的站点组件。下节课我们更深入探讨每一步的细节，大家先消化一下这些概念，有问题的随时问我。

  查看课程
• 24

  Flows

  同学们好，今天这一页Slide，我们来聊聊Lightning Web Components怎么跟Flow Builder这个自动化工具集成。Flow Builder呢，就是让管理员不用写代码，拖拖拽拽就能做出业务流程的工具。而当我们写LWC时，经常需要把这些自定义的组件放进流程里去，或者把整个流程嵌入到我们的组件里。集成方式主要有两种，Slide上写得很清楚。 第一种，把你的LWC变成一个，流屏幕组件，。意思就是，流程运行到某个步骤时，屏幕上显示的就是你这个LWC。要这么做，组件的配置文件里必须声明`lightning__FlowScreen`这个目标，并且你要用`@api`装饰器来定义属性，然后给属性配上角色：`inputOnly`表示这个属性只能从流程接收数据，就像流程传参数给你；`outputOnly`表示你处理完数据后，把结果返回给流程。你可以在配置里直接指定哪些是输入、哪些是输出。 第二种呢，是把整个流当成一个子组件，用`lightning-flow`基础组件嵌入到你的LWC里。这样一来，你就可以在自己的页面里放一个流程，让它跑起来。你可以动态指定要跑哪个流程，还能通过`flow-api-name`和`input-variables`这些属性，把当前页面的数据传进去。 当流程跑起来之后，我们经常需要知道它的状态变化。`lightning-flow`组件有个`onstatuschange`事件，能告诉我们流程现在是开始了（STARTED）、暂停了（PAUSED）、完成了（FINISHED），还是出错了（ERROR）。这个对我们控制页面上的其他元素很有用。 Slide里还提到通过Apex来“设置SObject”和收集输入变量。用大白话讲，就是有时候我们需要用服务器端的方法，帮流程准备好需要的变量，比如查出一组客户数据，然后把它们传给流程。我们就可以在LWC里调用Apex方法，拿到数据后，再把这些数据塞给流程的输入变量，或者从流程的输出变量里读出来存到数据库。 关于导航控制呢，是说当流程结束后，我们可以在组件里监听结束状态，然后决定跳转到哪个页面，比如回到列表页或者别的详情页。另外，如果流程暂停了，比如用户在屏幕组件里填了一半离开，后面还可以恢复这个“采访”（Interview就是一次运行实例），让用户继续填下去。 还有一种很牛的用法，就是构建，反应式屏幕组件，。当你的LWC作为流屏幕时，如果组件内部的属性发生了变化，你可以用`FlowAttributeChangeEvent`主动通知流程：“嘿，我这里的值变了，你可能需要更新别的字段。”这样一来，流程可以实时响应，让整个表单更灵活。Slide里叫它FlowCusteChangeEvents，其实指的是这个事件。 最后，记住几条最佳实践。很重要的一条：，永远不要直接修改用@api声明的属性，。因为这些属性是属于流程管理的，你直接改了会破坏流程的数据一致性。正确做法是，先把值存到内部变量，再通过事件通知流程。另外，善用派生属性来展示数据，别乱改来源。导航事件也要小心触发，别在流程还没彻底结束时就跳走。 好啦，这一章的核心就是这些，把LWC和Flow结合好，你就能做出既灵活又强大、还能让管理员动手配置的低代码业务界面。课后大家可以试着搭一个简单的流程，用LWC接收数据再返回结果，亲身体会一下。

  查看课程
• 25

  Create Flow Local Actions using LWC

  同学们，今天我们聊聊在 Flow 里怎么让组件直接在前端“干活”——也就是，本地操作，。你想想，很多场景我们完全不需要跟服务器来回通信，比如调用一个外部的天气 API、打开一个新网页、或者在屏幕右下角弹出一个“操作成功”的 Toast 提示。这些动作，都可以在用户浏览器里秒完成，体验特别流畅。 但要记住，这种本地操作类组件跑在 Lightning 收件箱（Lightning Runtime）里，，只有屏幕流能用，，因为需要浏览器环境，自动化流、记录触发的流那是没有页面的，所以不行。而且组件本身也必须遵守 Lightning 收件箱的一些安全限制，不能为所欲为。 那我们要怎么做一个本地操作的 LWC 呢？整个生命周期大概分这几步—— ，第一步，配置目标。， 在组件的 `*-meta.xml` 文件里，必须把目标设为 `lightning__FlowAction`。只有这样，Flow Builder 才会把它识别成一个“操作”类型的组件。 ，第二步，实现核心方法 invoke()。， Flow 运行时调用我们的组件，就是触发这个 `invoke()` 方法。你可以把它写成一个同步的方法，直接返回结果；但更常见的，我们会返回一个 ，Promise，，比如去发一个 fetch 请求拿第三方数据，然后再告诉 Flow 我完事了。同时，Flow 会传给你一个 `cancelToken`，万一这个操作超时或者被中断了，你可以在 Promise 里检测到，主动中止，避免一直在那傻等。 ，第三步，如果这是个屏幕组件，还要做验证。， 有时候本地操作组件是放在屏幕上的，用户可能输入了一些东西，这时候就需要前端校验。LWC 里可以用 `validate()` 方法做整体检查；如果你想手动标记某个字段出错，可以用 `setCustomValidity('错误信息')`，再用 `reportValidity()` 让浏览器把提示显示出来，跟原生 HTML 校验一样。 ，还有一点很酷，就是自定义属性编辑器。， 你肯定希望管理员在 Flow Builder 里配置这个操作时，看到的不是一堆死板的文本框，而是下拉列表、切换开关之类的。这时候你可以提供一个 ，JavaScript 接口，，里面包括 `inputVariables`、`builderContent`、`elementInfo` 和 `genericTypeMappings` 这些对象，去描述编辑器的长相和逻辑。这样非开发者也能轻松配置你的组件。 最后别忘了，类型映射，——Flow 里的数据类型跟 JavaScript 的类型不是一回事儿。比如 Flow 里的 Text 对应到 LWC 就是字符串，Number 对应数字，Boolean 对应布尔，Date/DateTime 都有对应的对象。你得清楚这些对应关系，避免传值出错。 总结一下，今天讲的本地操作就是给你在 Flow 里打开了一扇“无服务器”的窗：不用 Apex，不用等服务器，直接在用户眼前把事办了。关键记住：目标设对、invoke 实现好、超时要处理、验证别忘、编辑器做好、类型要匹配。这样你就能做出既灵活又可靠的本地操作组件啦。 咱们下次课再见！

  查看课程
• 26

  Lightning App Builder

  同学们，咱们今天这页Slide，内容非常扎实，它把整个Lightning App Builder的生态系统给咱们串起来了。你听我慢慢给你讲。 首先，你到底是怎么把一个组件，放进App Builder那个拖拽的界面里，让人能点来点去配置它的呢？这就要靠一个叫 `.js-meta.xml` 的配置文件。在这个文件里，你可以定义几个非常关键的东西。 第一个是“目标”，也就是Targets。你总得告诉Salesforce，我这个组件能放在哪儿吧？是放在一个记录详情页，就是RecordPage；还是放在一个自定义的应用页，AppPage；或者是放在主页，HomePage。这就像在说，我这个家具，到底是适合客厅、卧室还是书房。 定义了放哪儿之后，管理员或者开发者在配置这个组件时，还能填一些东西，这就是“属性”。这些属性，就写在那个配置文件里。比如一个“欢迎横幅”组件，我可以定义个属性叫“欢迎语”，让配置的人在App Builder里直接打字输入。 有时候，你这个组件是跟特定对象绑定的，比如只跟“客户”或“商机”对象相关，那你就可以在配置文件里加上“对象限制”，把它限制住。另外，为了让你的组件在App Builder的列表里长得好看，别忘了给它配一个“SVG图标”，这样别人一眼就能认出来，这都是在这个配置文件里做的。 好，组件放进页面了，但页面上的组件不能都是哑巴吧？它们得互相说话，进行“动态交互”。比如你点了一个客户列表里的名字，旁边那个客户详情组件就得马上刷新。这种组件到组件的通信，就是通过“事件”来实现的。具体怎么定义呢？就是在那个配置文件里，通过事件/模式元数据来声明，我这个组件能“广播”什么消息，或者能“接收”什么消息。 但有时候，通信的范围更广。比如一个页面里，既有LWC组件，又有老的Aura组件，甚至还有Visualforce页面，它们之间怎么聊天呢？这时候就要请出一个厉害的角色了——Lightning Message Service，简称LMS。它专门负责这种跨技术栈、跨DOM的通信。而且它的通信范围是可以配置的，你既可以让消息在整个应用里传，也可以让它在不同的标签页里传，非常灵活。 聊完通信，最后还得会走路吧？“导航服务”就是带咱们走路的向导。我们通过调用 `lightning/navigation` 这个服务，就能用代码控制页面跳转了。具体的做法，就是创建一个叫 `PageReference` 的对象，然后告诉它你要去哪儿。 你想去什么地方？用一个 `PageReference` 对象全能搞定！想去一条客户记录的详情页？可以；想去某个对象的列表视图，看看所有商机？可以；想直接跳转到某个对象的主页？可以；甚至你想跳一个普通的URL、另一个自定义的LWC组件、弹出一个模态窗口，或者导航到一个文件，统统都可以。 所以你看，这一页虽然东西多，但思路非常清晰。它给你勾勒出了一个完整的画面：从用配置文件让组件在App Builder里“安家落户”，到通过事件和消息服务让组件们“互通有无”，最后通过导航服务带用户在应用里“自由行走”。这就是整个App Builder生态系统的核心玩法。

  查看课程
• 27

  Open Modal Windows and Notifications

  大家好，我是你们的Salesforce老师，今天咱们聊聊Lightning Web Components里模式窗口和通知的用法。这些东西都是用类扩展的方式来创建的，不是直接在HTML里写标签，所以它们是专用的基本组件，用起来很灵活。 先说说LightningModal，它就像个弹出来的对话框，你可以自定义标题、正文和页脚三个部分，轻松做出各种交互窗口。然后是LightningAlert、LightningConfirm和LightningPrompt，它们替换了以前浏览器自带的alert、confirm和prompt，因为那些老方法已经废弃了。现在这些新组件都用Promise来处理，也就是异步的，不会卡住页面，用户体验更好。 接下来是Toast通知，这是个小消息提示，我们推荐用lightning/toast模块来做。它支持内嵌链接，就是消息里能加点击链接，然后由lightning/toastContainer统一管理显示，很方便。至于Outlook和Gmail集成，如果你要把组件嵌到邮件服务里，会用到lightning__RST目标和电子邮件属性，这个咱们后面再细讲。 最后看快速动作，在记录页面上经常用。它通过lightning__RecordAction目标配置，有两种模式：ScreenAction和Action。ScreenAction会弹出带界面的模式窗口，供用户操作；Action是无头的，只跑后台代码，不显示任何界面。大家听懂了吗？有疑问随时提，下一课咱们就动手敲代码试试。

  查看课程
• 28

  Setup with Agentforce

  大家好，今天我们来聊聊 Lightning Web Components 部署时的一些目标配置，尤其是在 AI 辅助建页面这个场景下。 首先，当你根据用户的自然语言描述来创建 Lightning 页面时，安装程序里的 Agentforce 可以智能地分析和推荐你已有的自定义组件。想让你的组件能被 AI 认出来并推荐，你必须在组件的 js-meta 配置文件中，用 `ai` 这个标签集加上一段描述文字，告诉 AI 这个组件是做什么的。这样 Agentforce 才能理解你的组件。 接着，这张幻灯片还带我们复习了其他几种部署目标。比如你可以把组件打包成一个独立的 Aura 应用程序来运行，这个时候要用一个驼峰命名的交付名称，格式是 `命名空间:camelCaseDeliveryName`。如果你希望组件在移动端有特殊的表现，可以通过 `lightning/mobileCapabilities` 来开启移动设备功能。 还有一个常见的场景是把组件放到页面的实用程序栏里，那就要把目标设为 `lightning__UtilityBar`，并且配上一个 SVG 图标，这样在工具栏上就能看到一个漂亮的入口了。 最后，如果你想在 Visualforce 页面里嵌入 Lightning 组件，就得用 Lightning Out 技术。基本方式就是在 Visualforce 中通过 `$Lightning.use()` 初始化一个依赖应用，然后用 `$Lightning.createComponent()` 这类方法把组件动态创建和渲染出来。 好了，这一页的重点就这些，我们理解了组件的不同部署选项之后，可以更灵活地把它们放到各种容器里运行。

  查看课程
• 29

  Debug Lightning Web Components

  同学们，现在我们来聊聊LWC的调试。LWC用的是标准的HTML和JavaScript，所以我们最常用的调试工具就是Chrome的开发者工具，非常方便。 在LWC里，代码有两种执行模式：一种是生产模式，这种模式下代码是压缩过的，而且会用代理对象，想看明白代码得靠“漂亮打印”；另一种是调试模式，代码是未经压缩的、可读的，还能看到EPT和存储指标这些性能信息。 说到调试，你还要注意HTTP缓存。缓存的有效期是5分钟，并且在重新验证时就会停止。也就是说，如果你改了代码，最坏的情况下可能要等差不多10分钟才能看到最新效果。 那怎么绕开这个缓存，直接看到可读的代码呢？你可以在“设置”里为每个用户单独启用“调试模式”，这样就能跳过缓存，拿到的总是最新的、未压缩的代码，调试起来舒服多了。 在调试数据交互的时候，我们经常需要检查电线适配器的状态。这时可以用自定义格式器，还有一些完全免费的控制台实用程序，直接在控制台里就能很方便地查看适配器返回的数据。 另外，如果你的组织启用了Lightning Web Security，也就是LWS，那么调试时可能会有一点点小差别，需要多留意一下。 最后，要调试移动端的效果，很简单，直接用Chrome的设备模式。你可以在里面切换屏幕尺寸、调整方向，还能模拟不同的CPU速度和网络环境，这样不用真机就能做好移动端的测试了。 好了，这些就是LWC调试的核心点，你只要把这些用起来，调试就会变得很顺手。

  查看课程
• 30

  Test Lightning Web Components

  同学们，咱们今天来看LWC开发里一个特别有用的工具——Jest。你把它想象成一位随叫随到的质检员，能帮咱们给组件做一套快速又全面的体检。 这套体检最大的好处就是：根本不用打开浏览器，也不用连到Salesforce服务器，完全在你的电脑本地就能跑。所以速度飞快，几秒钟就能看到结果，特别适合放到持续集成流水线里，每一次代码提交都能自动验证，及时发现毛病。 那咱们能用Jest测些什么呢？简单来说，就是把你写好的组件单独拎出来，跟它周围的东西隔离开，专心测它自己的行为。你可以验证那些带@api装饰器的公开属性和方法，确认事件是不是按预期触发的，模拟用户的点击、输入这些交互，还能检查最终渲染出来的DOM结构是不是你想要的样子。 为了让这套测试能跑起来，Salesforce给我们提供了一个专门的小工具包，名字叫sfdx-lwc-jest。它里面有三个核心装备：第一个是jsdom，它在Node.js环境里模拟出一个浏览器才有的DOM树，这样就不需要真浏览器了；第二个是lightning-stub，它会模拟那些Salesforce平台提供的基础组件，比如lightning-button这些，让你测自己写的组件时，不会因为缺少底层依赖而报错；第三个是专门测试有线服务用的实用工具，方便你模拟apex方法或者LDS数据拉取。 咱们接下来这一整章，就是从零开始，带你走过Jest测试的完整生命周期。先搭好环境，装好依赖，然后一步一步做测试，最后还会学到一些高级的模拟模式，让你能应对各种复杂的测试场景。放心，跟着做，你很快就能写出又稳又准的单元测试了。咱们这就开始吧。

  查看课程
• 31

  Use DX MCP Tools for LWC (Beta)

  同学们，今天咱们聊聊一个特别酷的新东西，就是Salesforce DX HCP服务器。它就像给咱们Lightning Web Components开发装上了一套人工智能工具箱。怎么理解呢？它是通过一个叫模型上下文协议的技术，也就是MCP，把30多个AI工具整合起来，专门帮我们写LWC代码。 这30多个工具分成了三个大的工具集，方便咱们按需取用。第一个叫lwc-experts，里面包括了开发、测试、SDDS数据服务、LDS数据服务、基础组件、甚至还有Figma设计稿转代码、安全检查、代码迁移这些工具。第二个叫Aura-experts，它主要是帮我们从老的Aura框架迁移到LWC，提供蓝图和自动迁移工具。第三个叫专家验证，它会从生产环境就绪的角度给项目打分，范围是0到100分，非常直观。 那怎么配置这些工具呢？很简单，在HCP服务器的JSON配置文件里，我们可以用 --tools set 这个标志来整体启用工具集，我的建议是直接把三个工具集都打开，这样功能最全。如果你只想挑某一个具体工具，也可以用 --tools 标志指定单个工具。注意一点，有些工具还没正式发布，也就是非GA状态，要使用它们的话，记得加上 --allow-non-ga-tools 这个标志，否则调用不了。 使用方式也很灵活。最推荐的是通过Agentforce Vibes这个扩展，它是一个预配置好的环境，开箱即用。当然，如果你习惯在VS Code或者Cursor里写代码，也可以直接配合Copilot来调用这套工具。 最后要提醒一下，目前这个服务还处于测试版阶段，所以使用时会受到测试版服务条款的约束，大家心里有数就好。 总之，这个HCP服务器就像是一个智能开发助手团队，帮我们把LWC开发效率提得高高的，课后可以动手试一试，感受一下AI带来的便捷。

  查看课程