DEX475

课程介绍

嘿，同学，今天咱们聊聊 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 给你准备好的趁手工具，直接拿来用，让你的开发又快又稳。咱们下节课继续。

课程章节

本课程共有 14 个章节

• 1

  Static Resources — Create & Upload

  第 203 页

  同学们，我们现在来讲讲静态资源，这可是把外部文件和咱们的Lightning Web组件绑在一起最主要的方法。 你可以把静态资源想象成一个“包裹”，里面可以装很多类型的东西，比如压缩包（像Zip、jar文件），图片，样式表，JavaScript脚本，还有其他各种文件。你把这些东西打包成一个静态资源，然后组件就能很方便地引用它们了。 怎么创建呢？很简单，在Setup里找到静态资源，新建一个。首先得给它起个唯一的名字，名字有规矩：只能用字母、数字和下划线，必须以字母开头，不能有空格，也不能连续用两个下划线。比如“my_logo_png”就是合法的，但“my-logo”不行，因为它有横杠。起好名字之后，你可以加点描述，让人明白这是干啥的。 然后，从本地电脑选个文件上传，文件大小不能超过5MB，一个组织里所有静态资源加起来不能超过250MB。上传时要留意缓存设置，有两种：选“Private”，那资源就是跟每个用户的会话绑定的，每个用户都要重新加载一次，比较安全；选“Public”，资源就能在用户之间共享，而且被缓存之后，甚至没登录的互联网流量都能访问，公开性更强。一般我们放Logo、公共CSS这些就用Public。 在咱们的Salesforce DX项目里，静态资源文件要放到特定目录：force-app/main/default/staticresources。注意，这里是staticresources，一个词。放进去的时候，每个静态资源会有一个本体文件（比如一个zip），还有一个同名的.resource-meta.xml配套文件，描述了它的配置。 有个重要的限制要记住：你不能在静态资源里建子目录，它没有文件夹结构。如果你要模拟目录，得用zip包，把文件按路径打好包，然后通过路径来引用里面的文件。不过在静态资源本身上传的层面，是平铺的。 好了，关于静态资源的基本知识就这些。现在大家明白怎么把图片、样式等外部文件带进组件里了吧？下节课我们来看怎么在组件中引用它们。

  ▶ 播放视频 查看详情
• 2

  Import a Static Resource

  第 204 页

  同学们，我们来一起看看怎么在 Lightning Web Components 里优雅地使用静态资源。 首先，你需要理解一个特殊的模块作用域，叫作 `@salesforce/resourceUrl`。这个模块就是 Salesforce 给你提供的一个快捷方式，让你能直接拿到你上传到静态资源里的文件的网址。 基本语法很简单，你只要在你的 JavaScript 文件顶部写上一句 `import`，后面加上你的静态资源的“设置名称”。这个名字就是在 Salesforce 设置里，你给那个静态资源取的名字。比如说，你上传了一张图片，命名叫 `trailhead_sys`，那你就可以写： ```javascript import TRAILHEAD_SYS from '@salesforce/resourceUrl/trailhead_sys'; ``` 如果是在托管包里，为了防止名字冲突，需要在命名空间前面加上双下划线。比如命名空间是 `myNS`，静态资源叫 `myResource`，那就写成 `import MY_RESOURCE from '@salesforce/resourceUrl/myNS__myResource';` 注意这里的双下划线，是托管包的规范写法。 接下来，在 JavaScript 里你拿到这个导入的 URL 后，需要把它赋值给一个组件的属性，这样模板才能用到它。通常是这么做的： ```javascript export default class MyComponent extends LightningElement { trailheadSysUrl = TRAILHEAD_SYS; } ``` 那静态资源呢，可以是一个单独的文件，比如一张图片、一个 CSS 文件，直接用这个 URL 就能访问了。但还有一种情况，静态资源是一个打包好的压缩文件，里面可能有很多文件和文件夹结构。这个时候，你拿到的 `TRAILHEAD_SYS` URL 其实只是一个基础路径，指向这个压缩包的根目录。如果你想访问压缩包里的某个具体文件，比如里面 `images` 文件夹下的一张 `einstein.png`，你就得把基础 URL 和具体文件的路径拼接起来： ```javascript this.trailheadQualtsUrl = TRAILHEAD_QUALTS + '/images/einstein.png'; ``` 在我们给出的例子里，`TRAILHEAD_SYS` 是直接使用的单个文件，而 `TRAILHEAD_QUALTS` 是一个存档文件，示例里就演示了怎么通过基础路径拼接子路径拿到里面的图片。 最后，在 HTML 模板中，你就可以像平时绑定属性一样，用花括号 `{Property}` 来引用这些 URL 了。比如： ```html <img src={trailheadSysUrl} alt="Trailhead system image" /> ``` 或者针对压缩包里的文件： ```html <img src={trailheadQualtsUrl} alt="Einstein from archive" /> ``` 这样，静态资源就顺利用在你的组件里了。整个过程其实很直白：导入，赋值，必要时拼接路径，然后模板绑定。 好了，关于静态资源的使用就讲到这里。大家有问题随时问哦。

  ▶ 播放视频 查看详情
• 3

  Access Content Asset Files

  第 205 页

  好，我们这节课来讲一个在Lightning Web Components里很有用，但你可能还没用过的功能——内容资产文件，英文叫Content Asset。 你可以把它理解为一种特殊的静态资源。平时我们放图片、CSS，都会用静态资源对吧？内容资产说白了，就是专门为自定义应用和Experience Builder模板设计的一种资源文件。它在使用上跟静态资源很像，但它的定位更明确，就是给应用和模板提供内容用的。 那我们怎么在组件里用呢？很简单，直接从@salesforce/contentAssetUrl这个模块导入就行了。导入后，你会拿到一个资源的URL，可以在组件里用。 接下来，重点讲一下命名规则。你给内容资产起名字的时候，规则完全可以参考静态资源：只能有字母、数字、下划线，必须以字母开头，不能有空格，而且整个组织里面名字不能重复。比如你可以取名叫“hero_banner”，但别叫“hero banner”或者“123hero”。 跟静态资源一样，一个内容资产可以是一个单独的文件，比如一张PNG图片，也可以是一个压缩包，比如zip文件。如果是一个压缩包，你就要用到一个叫做“pathInArchive”的参数，来指定你要访问压缩包里面具体哪个文件的路径。就像从一个文件夹里点开某个文件一样。 接下来说说在Salesforce DX项目里，这些文件放哪儿。你要把内容资产文件放在，force-app/main/default/contentassets， 这个目录下面。注意，这个目录下面不能有子目录，就是直接放文件。而且每个资产文件都要有一个对应的.asset-meta的伴生文件，用来描述这个资产的元数据，比如它是个什么类型的，是图片还是文档。 最后，如果你想看看实际怎么用的，可以去，lwc-recipes，这个示例仓库里找一个叫，miscContentAsset，的组件，它演示了如何在组件中使用内容资产，跟着例子学是最快的。 所以总结一下，内容资产就是专门给应用和Experience Builder模板准备的、方便管理和引用的静态文件，命名规则和静态资源一样，支持压缩包，DX项目有固定存放目录，并且你会有一个伴生的元数据文件。掌握了这个，你的组件内容管理就更灵活了。

  ▶ 播放视频 查看详情
• 4

  Use SVG Resources — Directly in HTML Template

  第 206 页

  今天我们来讲讲在Lightning Web Components里怎么用SVG资源。SVG就是那种可以缩放、保证清晰度的矢量图，咱们在组件里加图标或者图形经常会用到。 在LWC里呢，使用SVG主要有两种方式，第一种叫直接嵌入。很简单，你直接把SVG的标签，比如 rect（矩形）、circle（圆）、path（路径）、text（文字）这些，连同它们的位置、大小、颜色属性，直接写到HTML模板里就行了。比如你写一个 `<svg>` 标签，里面放几个 `<rect>`，就画出了一个小图标。这种方式最适合那些非常小、非常简单，而且不需要重复使用的图标。想画个对勾、一个小圆点，直接写几行代码就搞定了，清晰明了。 第二种方式叫静态资源引用。如果图标比较复杂，或者你是一个完整的SVG文件，好几个地方都要用，那直接写一堆标签就太乱了。这时候你可以把SVG文件上传到静态资源里，注意啊，SVG文件里的根元素 `<svg>` 得有个 `id` 属性，方便我们引用。上传后，在JavaScript里用 `import` 导入这个资源，得到它的资源URL。然后在HTML模板里，用 `<svg>` 标签里面放一个 `<use>` 元素，这个 `<use>` 的 `href` 属性，就拼接成资源的URL加上 `#` 和那个 `id`。比如 `href="/resource/myIcon#my-svg-id"`。这样就能把整个SVG图标复用过来。这种方式非常适合大的SVG、需要复用的图形，还有那种团队成员共享的图标库。 不过要记住一点，无论你用哪种方法，LWC都会做安全清理，就是那个“VAR安全清理”。它会根据一个允许列表，只放行SVG里那些安全的标签。所以即使你直接写标签，也不是什么SVG元素都能用，只能用被支持的。当然常见的 `rect`、`circle`、`path`、`text` 这些都是支持的，所以没什么大问题。 好了，总结一下：简单小图标，直接写SVG标签进去；复杂的、要重复用的图标，上传静态资源，再用 `<use>` 引用。两种方式都很灵活，根据场景选择就好。

  ▶ 播放视频 查看详情
• 5

  Supported SVG Tags in LWC

  第 207 页

  同学们，今天咱们来看一个和安全相关的重要知识点——在 Lightning Web Components 中，SVG 标记的使用是有严格限制的。这主要是为了保护你的应用，避免遭受 XSS 跨站脚本攻击。 先说说为什么要有这个限制。你可能知道，SVG 是一种矢量图形格式，但它不只是画图用的，里面还能嵌入脚本、事件处理程序这类东西。如果攻击者在图片里藏了恶意脚本，你的页面就危险了。所以，LWC 只允许一个安全的 SVG 标签子集，在渲染时会自动过滤掉那些不安全的部分。 那哪些标签是允许的呢？你放心，常见的绘图需求全都覆盖到了。比如容器元素，像 svg、g、defs、symbol、use 这些，都是组织图形结构的基础。基本形状方面，圆、椭圆、直线、路径、多边形、矩形，这些画图最常用的标签都没有问题。文本元素，像 text、tspan、tref、title、desc，还有 altGlyph 这类修饰文字的，也都可以用。渐变和图案，比如 linearGradient、radialGradient、stop、pattern、marker、mask、filter，这些能让画面更丰富。如果你想插入图像或者媒体，image、audio、video、canvas 也都支持。连动画相关的 animateColor、animateMotion、animateTransform、mpath，以及字体相关的 font、glyphRef、hkern、vkern，全在允许的范围内。基本上，你日常开发中能想到的 SVG 用法，这里都为你保留好了。 那到底什么东西被禁止了呢？很简单，所有跟脚本和外部交互有关的高风险标签。比如 script、foreignObject、iframe，还有像 onclick 这样的事件处理程序属性，统统都会被 LWC 的安全引擎识别，并从 SVG 内容中自动删除。这样一来，哪怕有人上传了一份精心构造的恶意图片，里面藏着攻击代码，到了你的组件里，不安全的部分早就被清理干净了，根本没有执行的机会。 你可以把这个机制理解成一道自动安检门，有用的图形部分请进，危险的代码部分直接扔掉。这样你就可以放心地在组件里使用 SVG 图标、插图甚至动画，而不用额外操心安全问题。只要你在 LWC 里写的 SVG 只用这些被允许的标签，一切都会很顺畅。 好了，关于 SVG 安全限制我们就讲这么多，是不是很简单？关键是记住：LWC 帮你把好了安全关，你专心画图就行。

  ▶ 播放视频 查看详情
• 6

  Access Labels

  第 208 页

  同学们，咱们今天来聊聊Lightning Web Components里一个特别实用的小功能：自定义标签。你知道吗？多语言应用的基础，往往就是这些看似不起眼的小标签。它们其实就是存储在Salesforce里的文本值，可以被翻译成任何Salesforce支持的语言。这样一来，咱们的LWC组件就能自动根据用户的母语，显示出正确的内容，省去了手动判断语言、拼凑字符串的麻烦。 那在代码里怎么用呢？很简单，你只需要从 `@salesforce/label` 这个模块导入标签，格式是 `命名空间.标签名称`，注意中间有个点号。这个命名空间的格式跟托管包、Visualforce还有其他Salesforce技术里用的一模一样，保持了一致性，也方便咱们理解。 在组件的HTML模板里，你用这个标签就像使用普通的JavaScript属性一样，直接把它写在花括号里，它就能显示出对应的翻译文本。 那么这些标签文件本身是怎么组织的呢？在DX项目里，标签文件用的是一个特定的XML格式：文件名以 `.labels-meta.xml` 结尾，根元素是 `CustomLabels`，里面包含一个或多个 `labels` 元素，每个标签都有 `fullName`（全称）、`value`（默认值）、`language`（语言）、`protected`（是否受保护）和 `shortDescription`（简短描述）这些字段。你在写的时候，按照这个格式来就没问题。 最后一个贴心的地方：这些标签文件可以放在 `force-app/main/default` 目录下的任何位置，你可以根据自己的项目结构灵活地组织它们，不用拘泥于某个固定文件夹，非常自由。 好了，自定义标签就这么简单，大家理解了吗？自己动手创建几个标签，感受一下多语言支持的便捷吧。

  ▶ 播放视频 查看详情
• 7

  Internationalization Properties — Overview

  第 209 页

  同学们，今天咱们来聊一聊 `@salesforce/i18n` 这个模块。大家在做全球化组件的时候，它特别实用。这个模块提供了一整套国际化属性，能帮你的组件自动适应不同地区的用户。 这些属性主要分成四大类。 第一类是，语言和区域设置，，里面包含了 `lang` 语言代码、`dir` 文字方向，还有 `locale` 地区标识。 第二类是，日历数据，，比如默认的日历类型、编号系统，甚至还支持日本日历、东方的名称样式等等。 第三类是，日期和时间的格式模式，，可以用短、中、长三种格式来展示日期、时间，或者日期时间组合。 第四类是，数字和货币的格式，，这里面东西就多了，像货币代码、货币符号、格式模式，还有小数点、分组分隔符、百分号、正负号、指数、无穷大、NaN，以及千分号这些细节。 不过，要是你用的是 LWR 站点，也就是那种基于 Lightning Web Runtime 搭建的网站，有几个重要区别需要留意：`lang` 和 `locale` 是从站点配置来的，而不是用户的个人设置；时区 `timeZone` 是直接取浏览器的值；而且和货币相关的那些属性是不支持的。另外，假如你改了网站的语言配置，千万记得要重新发布站点，修改才能生效。 最后再给大家一个实用建议：在实际开发的时候，尽量用 `lightning-input`、`lightning-formatted-number` 这类基础组件，它们本身就自动处理好了国际化，咱们就省心多啦。 好，关于 `@salesforce/i18n` 模块，就说这么多。

  ▶ 播放视频 查看详情
• 8

  Internationalization — Date & Currency Formatting

  第 210 页

  同学们，咱们今天来看两个非常实用的例子，展示怎么用浏览器自带的国际化功能，也就是那个 Intl API，来根据用户所在的地区自动设置日期和货币的显示格式。这在我们做 Lightning Web Components 时经常用到，能让界面更符合不同地区用户的使用习惯。 我们先看日期格式。假设你的组件里需要显示一个日期，但不同国家的用户看到的顺序是不一样的。比如美国用户习惯月/日/年，而英国用户习惯日/月/年。那怎么做呢？很简单，从 @salesforce/i18n/locale 这个模块把当前用户的区域设置导入进来，就是一个表示语言和地区的字符串，比如 en-US 或 en-GB。然后直接把它传给 JavaScript 内置的 Intl.DateTimeFormat 构造函数，用它去格式化一个日期对象，出来的结果就会自动适配那个区域。你不需要自己写 if-else 去判断国家，浏览器帮你全搞定了。 再来看货币格式，同样很省心。比如你要显示一笔金额，既要考虑数字的分隔方式逗号还是句点，又要考虑货币符号放前面还是后面。这时候，我们从 @salesforce/i18n/locale 导入区域设置，同时从 @salesforce/i18n/currency 导入用户设定的货币代码，比如美元 USD 或英镑 GBP。接着用 Intl.NumberFormat，指定样式为 currency，并把货币代码传进去。这样一来，符号的位置、千分位分隔符、小数点、数字分组这些细节，全都按当地习惯自动呈现，你完全不用操心。 要记住，这个 Intl API 已经内建在所有现代浏览器里了，不需要额外加载任何外部库，非常轻量。当然，在 Salesforce 生态里，你也可以用现成的闪电组件来替代，比如 lightning-formatted-date-time 和 lightning-formatted-number，它们内部也封装了类似的国际化逻辑，拖拽配置一下就能用。但了解背后的原理，会让你在设计自定义组件时有更多灵活性。好了，这两个小例子就讲到这里，大家下去可以自己动手试试看。

  ▶ 播放视频 查看详情
• 9

  Internationalization — HTML Attributes

  第 211 页

  各位同学，大家好！今天我们来聊聊一个在国际化应用中特别重要，但容易被忽视的细节——就是如何在HTML里正确设置 `lang` 和 `dir` 这两个属性。它们看起来很简单，但对可访问性和页面正确渲染，真的非常关键。 先说说为什么。首先，屏幕阅读器靠什么来正确发音？就是靠 `lang` 属性。假如你的应用是给美国用户用的，那你就得设置 `lang="en-US"`，这样阅读器会用美式英语发声。如果是日本用户，就改成 `"ja"`，阿拉伯语就是 `"ar"`。如果这个属性错了，屏幕阅读器可能会乱读，甚至根本发不出声来，这对视障用户来说体验就非常糟糕。 那 `dir` 是做什么的呢？它负责文字方向。英语、西班牙语、法语这些是从左往右读的，就用 `dir="ltr"`，意思是 left‑to‑right。而阿拉伯语、希伯来语、波斯语这些是从右往左读，就得设为 `dir="rtl"`。如果不设置，文字方向可能乱套，布局也全垮了。 有了这个基础，我们还能在CSS里做一些针对方向的样式微调。比如，你可以用属性选择器 `[dir='rtl']` 来专门给从右到左的语言加样式，比如调整内边距、浮动方向等等，让界面在两种阅读方向下都自然。这样你的组件就真正做到适配多语言了。 那这些属性和它们的值从哪里来呢？在一个工程化的应用里，我们不能自己随便拼字符串，得遵循标准。Unicode 组织定义了一套叫 LDML 的规范，全称是本地数据标记语言（Locale Data Markup Language），里面就规定了语言标签和方向该怎么写。Salesforce 平台也是基于这套规范，所以我们要保持一致。 在 Lightning Web Components 里，实现起来其实有个很清晰的模式。你只需要做三步：第一步，导入相关的国际化属性，比如从 `@salesforce/i18n` 模块里拿到用户的 `lang` 和 `dir`；第二步，在 JavaScript 类里把导入的值赋给两个用来绑定的字段；第三步，在模板的 `<html>` 标签上，直接把 `lang` 和 `dir` 属性绑定上去，像这样 `lang={language}` `dir={direction}`。这样每个用户看到的界面就自动跟着他的语言和方向设好了。 总结一下，要做出真正面向全球用户的 Salesforce 应用，一定不能忘记在根元素设置正确的 `lang` 和 `dir`。它既帮助屏幕阅读器正确工作，也让文字方向自动适配，搭配一点CSS技巧，就能轻松搞定国际化布局。记住这个三步走：导入 → 赋值 → 绑定，你的组件就成功了一大半。 好了，今天就讲到这里，大家可以在自己的组件里试试看，有问题随时问我！

  ▶ 播放视频 查看详情
• 10

  Get Information About the Current User

  第 212 页

  各位同学好，今天我们来聊一个特别实用的小模块：，@salesforce/user，。它就像是你组件里的一个身份感应器，让你在代码编译阶段就能知道当前用户是谁。 这个模块提供了两个非常直接的属性。第一个是 ，Id，，它会返回当前用户那个18个字符长的Salesforce记录ID。你可能会问这有什么用呢？最常见的场景就是，你要把这个ID传给Apex方法做数据过滤，比如“只查我自己创建的记录”；或者在调用外部API时，带上这个唯一标识。而且因为它是在编译时就确定下来的，所以你组件一加载，这个ID就一定可以用，不用担心异步获取的问题。 第二个属性是 ，isGuest，，它是一个布尔值。如果当前用户没有登录，是个访客，它就返回true；登录用户就返回false。这在Experience Builder搭建的站点里特别有用，你可以利用它来有选择地显示或隐藏内容，比如“这段信息只有注册会员才能看到，访客就看不到”。这样就能轻松控制界面，而不用写复杂的判断逻辑。 还有两点需要提一下。首先，因为这个导入是经过编译时验证的，所以你在代码里写 `import userId from '@salesforce/user/Id';` 时，LWC框架会帮你检查，确保它始终有效。其次，如果你在用TypeScript开发，可以通过安装 `@salesforce/lightning-types` 这个npm包来获得类型提示，写代码时会更加顺畅。 所以简单总结：@salesforce/user 让你一眼就能拿到用户的ID和访客状态，用它来驱动权限控制和数据过滤，既安全又方便。下回碰到需要识别用户的场景，直接导入它就对了。

  ▶ 播放视频 查看详情
• 11

  Experience Builder Site — @salesforce/community

  第 213 页

  我们来看一下这一页的内容，讲的是 `@salesforce/community` 这个模块。 在 Lightning Web Components 里，如果你开发的是用在 Experience Builder 网站里的组件——也就是以前说的 Community，现在叫 Experience Cloud 站点——你就可以导入这个模块。它的作用呢，是让组件能访问当前这个网站专属的一些信息。 但有一个重点一定要记住：，这个模块只能在 Experience Builder 页面里用，。如果你把同一个组件放到 Salesforce 内部标准界面，或者手机 App 里，它是跑不起来的。所以它的适用范围非常明确，就是给网站用的。 这个模块会暴露两个属性给我们使用：一个是 `Id`，另一个是 `basePath`。 `Id` 返回的是当前网站的网络 ID。通常在开发的时候，我们会把它传给 Apex 控制器或者 ConnectApi 的方法，用来限定数据范围，让操作只在当前网站内生效，这样就不会跨站点乱拿数据了。 `basePath` 返回的是域名后面跟着的 URL 路径段，比方说你的站点是 `myPartnersite/s`。这个在构建导航链接的时候就非常有用，因为不同网站的路径前缀可能不一样，用了 `basePath` 就能保证生成的链接在所有网站里都正确工作。 最后，页面上的示例展示了一种常见用法：把获取到的网站 Id 作为一个反应变量——也就是那个 `$Id`——传给有线适配器。这样一来，适配器就会根据当前网站的 ID 去抓取跟这个站点相关的 Feed 条目，实现动态地加载当前社区的提要内容。 简单总结一下，`@salesforce/community` 就是给我们打开了通往 Experience Cloud 站点上下文的一扇小窗，让我们能拿到关键的 Id 和路径，方便在组件里做网络范围的查询和导航。但它只存在于网站容器内，这点一定别搞混了。

  ▶ 播放视频 查看详情
• 12

  Experience Builder Site — @salesforce/site

  第 214 页

  同学们，我们来看这个@salesforce/site模块。它其实是@salesforce/community的一个补充，主要就给你两样东西：网站ID和这个网站上配置的活动语言列表。 注意啊，它里面的Id属性返回的是网站组件的ID，可不是那个你常用的网络ID，这两个是不同的，千万别搞混了。 另一个属性叫activeLanguages，它会返回一个语言对象的数组。每个对象呢，有一个code，比如“en-US”，还有一个label，比如“English (US)”。这个数组是按语言的标签首字母顺序排好的，而且只会包含那些你在体验生成器的设置里真正打开了的活动语言。不是所有语言都会出来，没激活的就不会出现。 讲个实际的应用场景吧，我们就拿语言选择器来说。你可以在组件里导入三个东西：活动语言列表、当前语言，还有页面的基本路径。然后用活动语言来填充一个下拉框，当用户从下拉框里选了另一种语言之后，你就可以通过替换掉基本路径里那个代表区域设置的字段，拼出一个新的URL，最后让浏览器重定向到这个新地址就可以了。 这中间有个地方要注意一下，如果你们在用LWR站点，而且用了Lightning收件箱，那全局的window对象很有可能没法访问。这种情况下，刚才说的那种跳转模式就会出问题，你必须把收件箱关掉才行。记住了，这是个小坑。 好了，这个模块的内容就这些，很简单但很实用，以后做多语言站点就靠它了。

  ▶ 播放视频 查看详情
• 13

  Check Permissions

  第 215 页

  同学们，咱们来看一下LWC里面怎么做权限检查。在Aura框架里，我们习惯在运行时去调用API来查权限，但在LWC里，思路完全不一样了。我们用的是编译时静态导入。这有什么好处呢？简单说，就是在页面加载的时候，权限结果就已经确定了，不需要再发起额外的网络请求，速度更快，也更可靠。 具体怎么做呢？如果你想检查一个标准权限，比如查看账户的权限，你就在组件里这样写：import 一个东西，从 '@salesforce/userPermit/查看账户'。注意，这个路径是固定的模式，你把PermissionName换成你要检查的那个权限的API名称就可以了。 那如果是自定义权限呢？分两种情况。如果这个自定义权限跟你的组件在同一个命名空间里，直接用 '@salesforce/customPermit/权限名称' 就行，不需要加命名空间前缀。但如果这个权限是来自一个托管包，命名空间不一样，这个时候就要在权限名称前面加上命名空间，并且用，双下划线，来分隔。比如，命名空间叫 myNS，权限叫 My_Permission，那你导入的路径就是 '@salesforce/customPermit/myNS__My_Permission'。记住，是双下划线。 导入进来之后，这个导入的值是什么？如果当前用户有权限，它就是 true；如果没有权限，它不是 false，而是 ，undefined，。虽然 undefined 在布尔判断里也是 falsy，和 false 一样会走到不成立的逻辑，但你得清楚它是 undefined，不是 false，这样在调试的时候心里有数。 跟Aura的运行时检查相比，LWC这种静态导入最大的优势就是性能。因为权限结果在编译时就确定了，运行时没有网络开销，也不会因为等待权限检查而闪烁界面。那我们怎么用这个值来控制界面呢？通常在 getter 里面用。比如你定义一个 get 方法，里面返回这个权限变量，然后在模板里用 lwc:if 来决定某块UI显不显示，或者用 disabled 属性来控制按钮能不能点。 如果你去看 Salesforce 官方的 lwc-recipes 仓库，里面有一个示例叫 miscPermissionBasedUI，它完整演示了这些模式。建议大家去拉下来看一看，跟着敲一遍，理解会更透彻。 总的来说，LWC的权限检查，就是静态导入、编译时解析、无网络调用，性能更好，代码也更干净。记住这几点，以后做权限控制就游刃有余了。好，这节课就到这里，有什么问题随时提。

  ▶ 播放视频 查看详情
• 14

  Access Client Form Factor

  第 216 页

  好，同学们，我们来看一下这个关于客户端外形规格的概念。你想想，现在大家用的设备各种各样，有台式机大屏幕，平板电脑中屏幕，还有手机小屏幕。我们的Lightning Web Components能不能知道用户正在用哪种设备呢？可以的，这就是客户端外形规格要解决的问题。 简单说，外形规格就是一个属性，它告诉你用户设备是大型、中型还是小型。大型就是桌面电脑，中型是平板，小型是手机。这个属性是从一个专门的模块叫“@salesforce/client/formFactor”导入的。注意，它是个编译时常数，也就是说，在代码编译时就把这个值固定下来了，运行时不会改变。 那用它来做什么呢？一个主要用途是传给像getRecordDeliverDocs这样的有线适配器。这个适配器会根据外形规格返回不同的默认布局。比如桌面用户可能看到全页面布局，内容很丰富；而手机用户就会看到一个紧凑的表单，方便在手机上操作。 我们自己写组件的时候，也可以用外形规格来做条件渲染。比如，在大屏幕上显示详细的数据表，所有信息一目了然；在中型平板上可能空间有限，那就显示一个简化的卡片视图；小手机屏幕上，连卡片都显大，就干脆显示一个简单的列表视图。这样就能保证在不同设备上都有好的用户体验。 另外，如果你是用TypeScript开发，可以通过“@salesforce/lightning-types”获得类型支持，写代码的时候会有更好的提示和校验。 当然，这只是简单的判断屏幕大小。如果你想要更高级的响应式设计，比如不仅能区分手机和桌面，还能根据窗口大小实时调整布局，那就要参考官方文档里“针对不同形状因素配置您的组件”的部分，那里有更详细的内容。 好，这部分内容就讲到这里，我们了解了怎么通过外形规格让组件适配不同设备，大家可以在实际项目中灵活运用。

  ▶ 播放视频 查看详情