DEX475

课程介绍

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

课程章节

本课程共有 6 个章节

• 1

  Install a Code Editor & Set Up Linting

  第 13 页

  同学们，今天我们来看看这一页关于开发工具的内容。想要获得最好的 Lightning Web Components 开发体验，官方推荐我们一定要用 Visual Studio Code，并且安装 Salesforce 扩展包。这个扩展包可厉害了，能给我们提供 Apex 代码自动补全、SLDS 样式验证，还有专门针对 LWC 的开发工具，让写代码顺手很多。 除了扩展包，我们最好再装一个 Prettier，用它来做代码格式化，保持整个项目的代码风格整齐划一。注意，LWC 是没办法在开发者控制台里开发的，必须得用 VS Code 这样的本地开发工具才行。 在写代码的过程中，为了避免错误，我们还会用 ESLint 来做静态检查。它能在编译之前就把一些潜在问题揪出来。Salesforce 专门为 LWC 定制了一套 ESLint 规则，帮我们写出更规范的组件代码。 有个重要的提醒：现在官方要求大家把 ESLint 迁移到 v9 版本。因为从 2026 年春季开始，所有新的规则和问题修复，都只会基于 v9 来提供支持了。如果你还在用旧版本，到时候就收不到更新了。ESLint 提供了三种不同严格程度的配置级别，大家可以根据自己项目的需要去选择。 最后，在标准的 Salesforce DX 项目里，linting 工具已经自动帮你包含进去了，不需要额外复杂的配置。你只需要在项目目录下打开终端，先运行 `npm install` 安装依赖，再运行 `npm run lint`，一键就能执行代码检查，特别简单。 好，关于开发环境的搭建和代码检查，这一页的重点就是这些。赶快去配置起来吧。

  ▶ 播放视频 查看详情
• 2

  Set Up a Development Org & Debug Mode

  第 14 页

  同学们，我们来一起看看这张幻灯片上的内容，主要是讲LWC开发环境的几个关键点，我会用最简单的话帮大家理清楚。 首先，你要去 developer.salesforce.com/signup 这个地址注册一个完全免费的开发者版组织。有了它，你就有了一块可以随意折腾 Salesforce 的专属空间。 在开发 Lightning Web Components 的时候，你既可以选 Scratch 组织，也就是常说的临时组织，也可以选非临时的组织，比如刚才注册的开发者版或者沙盒环境。 那它们有什么不同呢？ Scratch 组织需要一个叫 Dev Hub 的设置。Dev Hub 就像是一个总控中心，要先在正式或开发者组织里启用它，才能去创建 Scratch 组织。这种组织最大的好处是支持源跟踪，你改了什么代码，它只推送你改动过的文件，速度特别快，很适合频繁迭代。 而非临时组织可没有这种源跟踪能力，你每次部署的时候，都会把指定的所有元数据一股脑全传上去。 如果你正在积极地写 JavaScript、做调试，强烈建议你打开调试模式。它有两个明显的好处：一是不会压缩框架代码，让你能看懂原始的逻辑；二是会给你更详细的警告和错误提示。不过代价会拉低一些性能，所以只在开发、调试阶段开启就好。 最后还要记住一点：从 2023 年冬季版本开始，新创建的 Scratch 组织默认启用了 LWS，也就是 Lightning Web Security。这会让你的组件运行在一个更安全的沙箱里，但一些老的非标准的写法可能会受影响。如果你碰到莫名其妙的问题，可以检查一下是不是和 LWS 有关。 好了，这就是这一页我们要掌握的内容。打好环境基础，后面写组件才会更顺手。

  ▶ 播放视频 查看详情
• 3

  Develop with Salesforce DX Tools — Overview

  第 15 页

  好，我们来看这一页，它讲的是用 Salesforce DX 工具来做 Lightning Web Components 开发，这是目前最舒服、集成度最高的方式。 你可以把 Salesforce DX 想象成一套专门为开发者准备的工具箱。里面都包括什么呢？首先有 Salesforce CLI，也就是命令行工具；然后有咱们写代码用的 VS Code，配合 Salesforce 专门提供的扩展包，装上之后，很多功能就能直接在编辑器里操作了。还有一个很重要的东西叫 Salesforce DX 项目结构，它把代码、配置都按一种标准方式组织好，方便团队协作。最后，开发环境不是在正式的生产组织里直接搞，而是在 scratch org 或者沙箱里，这样既安全又灵活。 这套工具链带来的好处非常明显。第一个，临时组织（比如 scratch org）里支持源跟踪，也就是说，它知道哪些文件被你改过。那部署的时候呢，就只推送变更过的部分，不用把整个代码库重新上传，速度会快很多。第二，天生就适合跟 Git 这种版本控制系统配合，改了什么都能追溯。第三，它还能自动做 linting，帮你检查代码规范，减少低级错误。最后，所有的工作流程都可以通过 CLI 命令完成，一条命令就能创建环境、推送代码、运行测试等等。 操作起来也很方便，如果你用 VS Code，按 Command + Shift + P，然后输入 sfdx，就会看到各种命令，比如创建项目、授权组织、部署源码等等。当然，你也可以直接打开终端，敲同样的命令来执行。 如果你是第一次接触，我建议从 Trailhead 上的“快速启动”项目开始，它会手把手带你走一遍完整流程，把环境搭好，跑一个简单的例子。这样你就能直观地感受到这套工具是怎么让 LWC 开发变得又快又顺畅的。

  ▶ 播放视频 查看详情
• 4

  Develop in Scratch Orgs — Full Workflow

  第 16 页

  同学们，咱们今天来看看Scratch Org的经典工作流程，这是一个很实用的10步循环，让你在临时组织里高效开发Lightning Web Components。 第一步，我们先创建一个Salesforce DX项目，搭建好基础结构。第二步，用 npm start 命令来安装并启动代码检查工具，也就是Linting，帮咱们保持代码规范。第三步是启用并授权Dev Hub，这个是一次性的操作，Dev Hub相当于管理所有临时组织的中控台，以后就不用再配了。 第四步，咱们创建临时组织，也就是Scratch Org。这时候要用一个定义文件来指定组织的特性，同时给它起一个别名，比如就叫“LWC”，这样后续用命令行时不用记一长串ID，直接用这个别名就可以。 第五步，在项目里的 force-app/main/default/lwc 目录下，生成我们需要的Lightning Web Components组件。第六步，把写好的源代码推送到Scratch Org里，注意这里只会推送变更过的文件，速度非常快。第七步，直接打开这个组织进行功能测试，看看效果怎么样。 如果测试中在组织里做了修改，比如调整了布局或字段，那么第八步就是把这些改动拉回到本地项目里，保持代码同步。之后如果需要继续开发，就重复推送、测试、拉回这个循环，快速迭代。 对了，所有步骤你都可以在VS Code里用命令面板来完成，打开命令面板搜索对应的命令就行，不用死记硬背。另外，从23年冬天开始，Scratch Org默认启用了Lightning Web Security，也就是LWS，安全性有了更好的保障，省去额外配置的麻烦。 记住这个小流程，你就可以很顺手地在临时环境里玩转LWC开发了。下次遇到具体操作时，咱们再逐步细讲。

  ▶ 播放视频 查看详情
• 5

  Hello World in a Scratch Org — Walkthrough

  第 17 页

  同学们，今天我们来看一个经典的入门例子：Hello World 组件。我们会从头开始，一步步搭建一个完整的 Lightning Web Component。 首先，给组件起名字的时候，记得用驼峰命名法，比如 helloWorld。这个名字会自动映射成 HTML 标签，变成小写字母加连字符的形式——c-hello-world。你之后在页面里使用这个组件时，就可以直接用这个标签了。 在这个组件里，我们会用到一个叫 @api 的装饰器，它的作用是把组件里的某个属性标记为公开的。这样一来，你就能在 Lightning App Builder 里直接配置这个属性的值，比如设置名字。这就是我们让组件变得可配置的关键。 接下来看 HTML 模板部分。我们用大括号把属性名括起来，比如 {名称}，这样就能把 JavaScript 里定义的“名称”属性，动态显示在界面上。另外，为了让界面好看，我把内容包在一个 Lightning 基本组件 light-card 里面，这样自带 Salesforce 的样式，看起来整洁又专业。 别忘了组件的配置文件，就是那个 js-meta.xml 文件。它定义了组件能出现在 App Builder 的哪些页面区域，也列出了哪些属性可以被管理员在界面上直接编辑。你不写这个文件，组件就没法拖拽到页面里。 之后就是把代码推送到我们的临时开发环境。推送完成后，打开那个临时组织，进入 Lightning App Builder，新建一个应用页面。在组件列表里找到你的 Hello World 组件，直接拖到页面上，然后在属性面板里就能看到那个名字输入框，填上你想要的文字，保存、激活页面，最后去前台查看，就能看到被 Light Card 包裹的、你亲自命名的 Hello World 欢迎信息了。 整个过程虽然简单，但已经包含了 LWC 开发最核心的几个环节：命名规则、属性暴露、模板绑定、配置文件和 App Builder 集成。大家跟着做一遍，对 LWC 的入门就算完成了。

  ▶ 播放视频 查看详情
• 6

  Develop in Non-Scratch Orgs

  第 18 页

  好，我们来看这一页，讲的是，非划痕组织，。 你先回想一下，我们之前做练习时用的那种临时的、用完就删的环境，那叫 scratch org，也就是划痕组织。它就像一个速写本，随手画完就可以撕掉。但实际项目里，你更多时候面对的是长久存在的环境，比如，沙箱、开发者版组织，甚至是生产环境，，这些就属于非划痕组织。 非划痕组织最大的不同在于，，它没有源跟踪，。 什么叫源跟踪呢？在临时组织里，Salesforce 会自动记录你改了哪些元数据，所以你推送的时候，只需要把变化的部分传上去，效率很高。但在非划痕组织里，这个机制是不存在的。所以，当你执行部署命令时，无论你只改了一个字段还是一整个类，它都会把你，指定的全部元数据，一股脑儿部署上去，而不是只推更新的那几样。这个概念一定要先理解了。 不过，创建的步骤基本是一样的，你依然先建好一个 DX 项目，把 linting 工具装好，然后生成你的组件。 真正动手时的主要区别就在命令上。在临时组织我们习惯用 `push`，但在非划痕组织，我们要改用 ，`sf project deploy start`，。 这个命令后面跟两个重要参数：`-d` 后面跟你的源码路径，比如 `force-app`；`-o` 后面跟目标组织的用户名或者别名，告诉它要把代码部署到哪里。 同样，如果要从非临时组织把代码拉回本地，命令也不是 `pull`，而是 ，`sf project retrieve start`，。 还有一个省心的地方是：你不用事先去创建什么 Dev Hub 或者 scratch org，因为压根就用不到。直接在已有环境上干活儿就行。 日常开发的迭代方式也很直接：你在本地改代码，改完了就运行部署命令把整个项目推到非划痕组织里去，然后记得，对着浏览器做一个硬刷新，，这样你就能看到最新的效果了。就这样循环往复，简单明了。 你只要把临时组织的 `push/pull` 替换成这里的 `deploy/retrieve`，并且记住源轨迹那个概念差异，非划痕组织的开发你就完全能驾驭了。

  ▶ 播放视频 查看详情