Reference Types & Editors + Property Attributes

同学们，今天咱们聊一聊怎么把自定义的类型和编辑器挂到组件的属性上。这里有两种连接方式，听我慢慢说。 第一种是通过 ，editor， 属性。如果你只想换个编辑界面，比如让用户在属性面板里看到更漂亮的输入框，但不需要额外的数据验证，那就直接建一个自定义编辑器组件，然后用 `editor` 属性，通过全限定名（就是组件在项目里的完整路径名）去引用它，特别方便。不过有个坑要注意：如果你用的类型本身已经是一个 LightningTypeBundle（也就是类型已经打包了自己的编辑和验证逻辑），就，不要，再用 `editor` 属性了。这时候得去 editor 的 json 配置文件里，用 `componentOverrides` 这个字段去覆盖，这样才不打架。 第二种是通过 ，type， 属性，它更纯粹一些，就是直接指定这个属性的数据类型。可以是 Salesforce 自带的普通类型，比如文本、数字，也可以是你自己封装好的自定义 LightningTypeBundle。两种方式配合起来，就能很灵活地控制属性的行为。 接下来要说说属性标签上的那些设置。你可以在属性的 `label` 和 `description` 里写一些文案，这会，覆盖，掉类型 bundle 里 schema.json 原本定义的标题和描述，让它在界面上显示得更贴切。属性标签一共能设 13 种属性，但记住了，一旦你引用了自定义或 Lightning 类型，像 RST（比如 required、step 这类约束）、max、min 和 placeholder 这些就，不能，在标签上写了。因为这些约束本来就该属于类型自己的 schema，放在那儿统一管，不会乱。 最后是可翻译属性。想让你的属性值支持多语言吗？那就是 `translatable` 打开，但它只对基于字符串的 Lightning 类型有效。如果你把一条文本标记成 `richTextType`，它在导出的翻译文件 .xlf 里就会以富文本格式输出；其他类型的值呢，就老老实实地输出纯文本。这对做国际化的时候很有用，注意区分一下就好。 简单来说，editor 管界面，type 管数据，标签能覆盖显示名，但约束要去类型的 schema 里定，翻译只对字符串生效——这样是不是就清楚多了？