XML Escaping, Testing & Migration

大家好，今天咱们来看看Slide上这个知识点，它其实讲了两件事：一个是怎么在属性编辑器里处理那些会让HTML乱套的特殊字符，另一个是从老的ExperiencePropertyTypeBundle迁移到新的LightningTypeBundle要怎么做。咱们慢慢聊。 先说特殊字符这事儿。有时候你在Lightning Web Components的属性默认值里，写了一些字符，比如小于号、大于号，还有JSON里的双引号，这些字符在HTML里是敏感字符，如果不处理，页面解析就会出问题。所以我们要做HTML转义，也就是把这些特殊符号变成安全的实体引用。比如richTextType的默认值里如果含有HTML标签，你就得把小于号换成 `<`，把大于号换成 `>`。而对于那种JSON格式的默认值，比如在objectType里，JSON字符串内部的双引号要记得转义，否则JSON就断裂了。开发完之后，还要测试一下，把组件部署到组织里，拖到Experience Builder的画布上，检查每个属性编辑器是不是能正确显示，能不能正常工作，同时试一下输入有效的值和无效的值，看看报错信息是否友好。 接下来是迁移的部分。以前的ExperiencePropertyTypeBundle现在要迁移到新的LightningTypeBundle。这个过程就像搬家，有六个明确的步骤。 第一步，创建一个新的LightningTypeBundle，注意，它的名字要和旧的不一样，不能重名。 第二步，把旧包里的模式文件，也就是描述属性结构的那些schema，复制到新包里。 第三步，最关键的一步，是把旧的design.json文件转换成新的editor.json文件。这里头有三个映射要记住：原来的“Property sheet”部分对应到新文件的“编辑器”配置里；原来的“Property Renders”相当于现在componentOverrides部分，用来覆盖组件渲染的行为；原来的“视图”配置对应到新文件的“布局”部分。 第四步，更新你组件里的js-meta.xml引用，让它指向新的LightningTypeBundle，而不是旧的。 第五步，部署到环境里。 第六步，确认一切正常后，就可以把旧的ExperiencePropertyTypeBundle删除掉了。 新的LightningTypeBundle有个好处，就是你在更新属性编辑器的时候，不需要中断已有的引用，改起来更顺滑。不过它也有个小限制，就是不支持自定义布局了，咱们得用标准布局来重新设计。所以迁移的时候心里要有数，原来如果做了很花哨的布局，可能得简化一下。 整体看下来，就是处理特殊字符保证安全，然后按照六步稳妥搬家，新家更灵活但布局规矩变了。大家实际操作的时候一步步来，测试仔细些，就没问题啦。 好了，这块内容咱们就讲完了，有什么问题随时问。