DEX475

课程介绍

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

课程章节

本课程共有 8 个章节

• 1

  Data Guidelines — Choosing the Right Approach

  第 273 页

  嘿，同学们，我们来聊聊 Salesforce 里做数据访问时该怎么选技术。这个决策啊，其实有个很清晰的路径，咱们一步步来。 首先，最优先考虑的，永远是基本组件。比如 lightning-record-form、lightning-record-view-form 这些，它们是最简单的，能自动帮你处理元数据、页面布局、字段验证还有错误提示。你几乎不用写什么代码，就能搞定增删改查，性能也最好。所以，能用基本组件解决的需求，就别往下走了。 如果你需要多一点自定义，比如要自己控制 UI，但又想要数据自动更新，那就可以用 LDS 线适配器。线适配器是响应式的，数据变了 UI 自动刷新。这里面啊，要记住两点：一个是你如果需要一次查询多个不相关的记录，可以用 GraphQL 线适配器，它能把多个请求合并成一个，减少网络开销。另一个是如果你只是要取单条记录，而且希望它是响应式的，用 getRecord 适配器就好，它会自动缓存，反应很快。 接着，假设你只是想做一次性的操作，比如创建一条记录，然后拿到结果就完了，不需要响应式监听后续变化，那就用强制性函数，像是 createRecord、updateRecord、deleteRecord。这些是命令式的，你调用它们，它们就执行，不会自动响应数据变化。适合在按钮点击等明确动作里使用。 如果以上这些都不满足，比如你要访问的对象 LDS 根本不支持（像 Task、Event 这种），或者你需要写一个很复杂的 SOQL 查询，再或者你要在同一个事务里操作多条记录，做事务性控制，那才轮到 Apex。它是最灵活的最后手段，但也要你手动管理缓存、错误和性能，所以别轻易用。 最后给你几条性能指导，记在心里：能用 GraphQL 合并多个请求的，一定合并；在适配器里，能指定具体字段就不要返回整个布局，数据越少越快；还有，尽量选那个返回数据量最小的合适适配器。另外，LDS 的调用是不计入 API 使用次数的，但它们会受到一般的记录数量限制，所以设计的时候也要注意数据量。 总结一下，决策顺序就是：基本组件 -> LDS 线适配器（GraphQL 或 getRecord）-> 强制性函数 -> Apex。按这个来，你的代码会又简洁又好维护。

  ▶ 播放视频 查看详情
• 2

  Lightning Data Service — Shared Caching & Change Detection

  第 274 页

  各位同学，今天我们来聊聊 Lightning Data Service，简称 LDS。你可以把它想象成 Salesforce 里一个聪明又体贴的数据管家，专门帮我们管缓存和同步数据。 LDS 最核心的能力，就是它那个“共享缓存”。什么意思呢？假设你页面上有三个不同的组件，都在展示同一个客户记录，比如张三的信息。如果没有 LDS，这三个组件可能各自去服务器问一遍，不仅浪费请求，还可能因为返回时间不同，显示的数据不一样。但有了 LDS，这条张三的记录只会被请求一次，然后放在共享缓存里，所有组件都从同一个地方拿数据，看到的版本保证是一模一样的。这就保证了数据的一致性，而且毫不费力。 那要是有组件修改了这条记录怎么办？别担心，LDS 会自动检测到改动。一旦记录发生变化，或者缓存自然过期了，它就会通过我们熟悉的 @wire 装饰器，自动把最新的数据推送给所有订阅了这条记录的组件。你完全不用手动去刷新，页面自己就更新了，就好像有个后台播放器，一直在帮你同步最新画面。 在性能优化方面，LDS 也做了很多贴心设计。比如渐进加载，数据可以一块一块的出来，不用等全部就绪；客户端缓存让数据就近存放，速度飞快；当数据更改时，缓存会自动失效，不会给你旧的数据；而且它还会把多个服务器请求打包到一起发送，再把重复的请求合并掉，这个叫做请求批量化与重复数据删除，能帮我们节省很多服务器资源。 说到布局元数据，它比较特殊。LDS 给页面布局也开了一个独立的持久缓存，这个缓存有自己单独的超时时间。但有一点要注意：如果管理员修改了页面布局，很可能需要你注销再重新登录，变化才会立刻体现出来，因为那是持久化的，不会频繁去检查。 讲到底层，LDS 实际上是建立在 UI API 之上的。UI API 非常强大，它能在一次请求里就把数据和相关的元数据一起给到你。而且它完全遵从 Salesforce 的安全设置，什么对象权限、字段级安全、共享规则，它都会自动替你遵守，不用担心泄露不该看的数据。 那么，是不是所有数据 LDS 都能管呢？并不是。记住，Apex 方法拿回来的数据，LDS 可不插手。如果你用了 Apex 控制器去查数据，抱歉，没有这种自动缓存、自动推送的好事了，你必须自己写代码来手动刷新缓存。所以一般能用 LDS 的地方，我们尽量用，因为它省心又安全。 好了，这就是 Lightning Data Service 的简要介绍。用好它，你的组件数据就能又准又快，还天生遵规守矩。大家课后可以找个小例子感受一下，下节课见！

  ▶ 播放视频 查看详情
• 3

  Compare Base Components — Record Forms

  第 275 页

  同学，咱们今天来讲讲这三个记录表格组件，它们有些像菜单上的不同选择，灵活程度不太一样。 先看 ，lightning-record-form，，它就像一个全自动的厨房，从创建、编辑到查看模式，全帮你搞定。你不需要自己写很多逻辑，它会自动切换模式，还支持管理员通过字段集来控制布局显示哪些字段。但缺点就是有点“大而全”，如果只想读个数据，它也会带很多可能用不上的东西。 再看 ，lightning-record-view-form，，它就像一张精美的菜单展示页。它专注于只读显示，你可以搭配 ，lightning-output-field， 自定义布局，想放几个字段、怎么排都行，很灵活。这就适合你只想展示数据、不让人修改的场景。 然后 ，lightning-record-edit-form， 就更进一步了，它像一个可编辑的空白表单，配合 ，lightning-input-field， 使用，你可以自己设计表单的布局，字段怎么摆、分几列，统统由你决定。非常适合自定义的编辑页面。 它们都支持通过 SLDS 网格类做多列布局，排版上很方便。 这里有个重点，性能和编译时验证。我们强烈建议你，指定单个字段，，而不是使用那个“布局类型”让管理员控制显示哪些字段。因为当你通过 `@salesforce/schema` 导入字段时，Salesforce 可以在编译时就检查字段是否存在，避免运行时出错。更关键的是，底层的 Lightning Data Service 只会加载你明确请求的那些字段，这样数据抓取更快、更轻量。如果用了布局类型，它可能一股脑把很多字段都拉下来，影响性能。 简单说，虽然 record-form 开箱即用很方便，但如果你追求性能和编译安全，尽量用后面两种组件，并且手动指定字段。这样你的组件会跑得更轻盈。 好了，这一块就讲这么多，咱们下次见。

  ▶ 播放视频 查看详情
• 4

  Load a Record — lightning-record-form & view-form

  第 276 页

  同学们，今天我们来聊聊在 Lightning Web Components 中加载记录的三种方法。这三种方式从简单到灵活，我们依次来看。 第一种，叫做 ，lightning-record-form，。这是最偷懒、也最快上手的方法，你只需要给它三个东西：`record-id` 记录ID、`object-api-name` 对象名，还有你想要展示的 `fields` 字段列表。它特别聪明，会自动帮你处理查看模式和编辑模式的切换，你连表单的界面都不用自己拼，直接就能用了。如果你的需求就是快速展示一条记录，并且让用户能就地编辑，选它准没错。 第二种，，lightning-record-view-form，，它给了你更多的控制权。当你想自己来摆放字段的位置、调整布局的时候就用它。它是怎么做到的呢？你可以在它的里面使用 `lightning-output-field` 组件，然后配合 Salesforce 设计系统里面的网格类，像 `slds-grid` 啊，`slds-col` 这些，把字段一个个摆得整整齐齐。这样，你就能做出符合自己设计要求的只读表单布局，但还是依托于标准表单的渲染，不用自己处理数据格式。 最后一种，是最灵活、也是开发中最常用的——，使用 `getRecord` 这个线绳适配器，搭配 `getFieldValue` 方法，。线绳适配器的好处是反应式的，什么意思呢？就是当记录的数据发生变化时，你拿到的数据会自动更新，UI 也会跟着刷新。你首先要导入一个 schema 里面的字段引用，比如 `import ACCOUNT_NAME from '@salesforce/schema/Account.Name'`，然后用 `getRecord` 拉数据，再用 `getFieldValue` 从返回结果里取出你要的具体字段值。拿到值之后，你完全可以用任意的标准组件去渲染，比如用 `lightning-formatted-text` 显示普通文本，用 `lightning-formatted-email` 显示邮箱链接，等等。这样你就拥有了完全的 UI 自由。 如果你需要访问父记录上的字段，也很简单，在 schema 导入里用点号连接就行，比如 `import OWNER_EMAIL from '@salesforce/schema/Account.Owner.Email'`，然后用同样的方法取值就好了。这样一来，你就能轻松在组件里展示关联对象的信息了。 简单总结一下：如果你追求快速省事，选第一种；如果要在标准布局上做点定制，选第二种；如果你需要拿到数据后随意拼接界面，或者要访问父记录、做复杂逻辑，第三种线绳适配器模式就是你的最佳拍档。 好了，今天这页的内容就是这些，同学们可以动手去试试，感受一下三者的区别。有什么问题随时提问哦！

  ▶ 播放视频 查看详情
• 5

  Edit a Record — lightning-record-form

  第 277 页

  同学们，咱们今天来看一看在LWC里怎么优雅地处理记录编辑。很多场景下，我们需要让用户编辑一条记录，比如一个客户或者一个商机。最方便的做法，就是从，闪电记录表单，（也就是 `lightning-record-form`）的，编辑模式，开始。这个组件很智能，它内置了查看和编辑两种模式，点击编辑按钮就能切换到编辑状态，省去我们从头搭建表单的麻烦。 那表单里该显示哪些字段呢？你有两种选择。一种是用 `layout-type="Full"` 或者 `Compact`，让管理员通过页面布局来控制字段的可见性和顺序。这样维护起来很灵活，管理员在后台拖拖拽拽就能改。另一种是直接，指定具体字段数组，，这种方式性能更好，而且在编译阶段就能提前验证字段是否存在。在生产环境里，我们，强烈建议用第二种方式，。 具体怎么指定字段呢？千万别用字符串去写字段的 API 名字，比如 `'Account.Name'`。我们应该，从 `@salesforce/schema` 导入字段，。像这样： ```javascript import ACCOUNT_NAME_FIELD from '@salesforce/schema/Account.Name'; ``` 然后在组件里用这个导入的常量。这样做最大的好处是，编译时验证，。如果你字段名拼错，或者那个字段在组织里被删除了，代码在部署之前就会直接报错，根本不会等到运行时才崩掉。这相当于给我们的代码加了一层安全网。 组件本身提供了，很完善的默认行为，：提交时会自动调用后台，失败时也会给出默认提示。但如果你想加入一些自定义逻辑，比如提交前校验、成功后的跳转、或者自定义错误处理，你可以，用事件处理器来覆盖默认行为，。对应的事件有 `onsubmit`、`onsuccess`、`onerror` 和 `onload`。比如，在 `onsubmit` 里你可以阻止默认提交，先做一些额外校验，再通过 `event.detail.fields` 去修改数据，然后手动继续。 想在成功或失败时弹出漂亮的提示吗？别忘了用 `ShowToastEvent`。在 `onsuccess` 里派发一个成功的 toast，或者在 `onerror` 里派发一个错误 toast，用户体验一下子就专业了。 最后提一个贴心的默认功能：，当记录提交成功之后，表单会自动从编辑模式切换回查看模式，，不需要你写任何代码来切换 UI。用户编辑完保存，立刻就回到只读视图，整个流程非常自然。 总结一下今天的关键点：用 `lightning-record-form` 开编辑模式，用 `@salesforce/schema` 导入字段保安全，通过事件定制流程，再加个 toast 给用户反馈。这样一来，既高效又健壮，你学会了么？

  ▶ 播放视频 查看详情
• 6

  Edit a Record — Custom Layout & Validation

  第 278 页

  同学们，今天我们来聊聊当你用 Lightning Web Components 做自定义表单布局时，一个非常得力的小帮手——`lightning-record-edit-form`。听名字就知道，它是让你编辑记录的，但和全自动的`lightning-record-form`不同，这个组件给了你更大的控制权。 你可以自己安排字段的位置，比如把几个输入框并排放，加一些分隔线，或者插入自定义的逻辑。它里面用`lightning-input-field`直接根据字段的元数据类型，自动渲染出合适的输入控件，日期字段就显示日期选择器，下拉列表就显示下拉菜单，不用你操心。 但要注意，`lightning-record-edit-form`可不会像`lightning-record-form`那样自带保存和取消按钮，你得自己设计按钮并添加逻辑。如果你想做一个“重置”按钮，清空所有修改，就不能简单地调用表单自带的`reset`方法。你需要用`this.template.querySelectorAll`找到表单里面所有的`lightning-input-field`，然后一个一个调用它们的`reset()`方法。这是因为框架需要逐个字段去通知它们恢复原值。 那如果保存时出错了怎么办？比如后端的验证规则没通过，或者重复记录。`lightning-record-edit-form`会触发一个`error`事件，你可以在这个事件里获取非常详细的错误信息。它的结构是`event.details.outcome.fields`，那是一个按字段名索引的对象。比如你一个叫“Name”的复合字段包含了“FirstName”和“LastName”，如果姓氏有问题，错误信息就在`fields.Name`这个对象里，它内部还有一个`constituentFields`，专门告诉你具体是哪个子字段报错，很贴心。 除了后端的验证，你可能还想在浏览器里做自定义的验证。比如“金额必须大于零，不能只靠后端”。这时候，你可以用`lightning-input-field`的`setCustomValidity`方法，如果发现不合规就设置一个错误消息，然后用`reportValidity()`让界面立刻显示错误提示。这个操作要放在提交处理函数里。当你点击自己的保存按钮时，一定先调用`event.preventDefault()`阻止表单自动提交，你自己跑一遍验证逻辑，确认所有字段都合规后，再手动用`this.template.querySelector('lightning-record-edit-form').submit(fields)`把数据送出去。这里的`fields`参数是可选的，如果某个字段有特别修正的值，你可以传进去覆盖。 这样就完成了一个完整自定义布局、带前后端双重验证的表单。是不是觉得这个组件既灵活又强大呢？自己试试看，一步一步来，你很快就能掌握。

  ▶ 播放视频 查看详情
• 7

  Create a Record — Base Components & Prepopulation

  第 279 页

  好，今天我们来看看怎么用 Lightning Web Components 来创建新记录。其实它和编辑记录的模式几乎一模一样，你只要记住一个关键的区别就行。 创建记录的时候，你不需要那个 `record-id` 属性。对，直接把它省掉。`lightning-record-form` 这个基本组件很聪明，一旦发现你没有传记录 ID，它就会自动从编辑模式切换到创建模式。你什么都不用额外设置。 如果你想用更灵活的自定义布局，那就用 `lightning-record-edit-form`。它在创建模式下，用起来也和编辑时完全一样，只是不绑定某个具体记录而已。 有时候我们需要预填充一些字段。这可以怎么做呢？有两种方式：一种是在标签里直接写死，比如给某个字段一个默认值；另一种是通过 JavaScript 属性来动态赋值——这样做的好处是，字段值可以通过代码随意改，比如根据用户的选择或者前面的操作来自动填充。 事件处理也是老面孔。创建记录一样会触发那四个自定义事件：`error`、`load`、`submit` 和 `success`。你只要像编辑时那样监听就好，不用学新东西。 有个小惊喜是，当你通过 `lightning-record-form` 成功创建一条记录后，表单会自动变成查看模式，并且在右上角出现那个小铅笔图标——也就是内联编辑直接可用了。用户点一下就能改，非常方便。 那取消按钮呢？它的重置逻辑和编辑时一样：你需要用 `querySelectorAll` 找到所有输入字段组件，然后挨个调用它们的 `reset()` 方法，让表单回到初始状态。这个操作没变，你以前怎么写，现在还怎么写。 总结下来，创建新记录就是把编辑的那套东西拿过来，去掉记录 ID，其他该咋用还咋用。这样学起来是不是轻松多了？

  ▶ 播放视频 查看详情
• 8

  Build Custom UI — Imperative createRecord

  第 280 页

  同学们，我们来看这一段内容。当你在用基本组件感觉有点不够灵活的时候，咱们就可以改用命令式调用，它能让你完全控制界面和数据怎么走。 在 `lightning/uiRecordApi` 这个模块里，有一个 `createRecord` 函数。它需要你传一个记录输入对象，这个对象里有两个东西：一个是 `apiName`，就是你要创建哪个对象的 API 名称，比如 `Account`；另一个是 `fields`，它是一个对象，键就是字段的 API 名字，值就是你要填进去的值。调用这个函数后，它会返回一个 Promise，当创建成功时，这个 Promise 就会解析出那个新记录的 ID。 那咱们一般会这样用：先拼好 `recordInput` 这个对象，然后用 `await createRecord(recordInput)` 去调用它。成功之后呢，我们通常会用 toast 通知给用户一个友好的提示，比如“记录创建成功”。为了安全，整个操作要包在 `try/catch` 里，这样万一出了错，咱们就能抓住错误并处理。 `updateRecord` 和 `deleteRecord` 的用法也差不多，都是一样的模式：拼好输入，等待结果，toast 提示成功，`catch` 处理错误。 这里要特别注意的是，每一个命令操作都是一个独立的事务。也就是说，如果你想要在一个事务里一次性处理多条记录，比如创建一个订单同时创建三条订单行项目，那这些命令式操作是没法放在同一个事务里的，你必须得写 Apex 来保证数据一致性。 最后，如果你们想参考完整代码，可以去看 GitHub 上的 `lwc-recipes` 仓库，里面有一个写得很清楚的示例，它通过一个叫 `reduceErrors` 的工具函数，演示了怎么从错误里提取有用的信息并显示给用户。这样错误处理就特别清晰。 好，这段内容就讲到这里。记住这种命令式创建、更新、删除记录的模式，以后你会经常用到。

  ▶ 播放视频 查看详情