Create a Custom Property Editor — Contract & Pattern

嘿，同学们，今天我们聊聊Lightning Web Components里一个特别实用的东西——属性编辑器合同。 你想象一下，你在Experience Builder里拖拽一个自定义组件，右侧属性面板上会显示一些设置项，对吧？那这些设置项怎么和你的代码互动呢？就靠这个“合同”啦。它像一套规则，规定编辑器需要接收什么，该做什么。 具体来说，编辑器会拿到六个属性，全是@api装饰的，都是从外面传进来的。我一个个说：第一个是“值”，就是当前这个属性的实际数据；第二个是“标签”，就是你在面板上看到的字段名字；第三个是“描述”，也就是悬停时显示的帮助文本；第四个是“必需”，一个布尔值，告诉你这个字段是不是必填的；第五个是“模式”，它是一个JSON Schema，用来做验证的；最后是“错误”，如果验证出问题了，错误信息会通过这个属性传回来，你得显示给用户看。 那用户改动了值，编辑器怎么通知外面呢？很简单，触发一个叫“valueChange”的自定义事件。注意，这个事件的detail里要带上一个对象，里面有个“Value”属性，把新值传出去就行。 这时候，属性表就会根据之前定义的模式去验证这个新值。如果没问题，它就帮你存到画布上；要是有问题，它会反过来把错误信息注入回编辑器的“错误”属性里。所以你的编辑器一定要能把回传的错误显示出来，别把用户蒙在鼓里。 举个实际例子——AlignmentCPD这个示例，它做了一个按钮组编辑器。当你点某个按钮时，它先更新自己的内部值，然后立刻触发valueChange事件，整套流程就串起来了。 另外，为了访问网站上下文，咱们还支持三个@salesforce模块。这个合同的存在，就是为了保证你写的自定义编辑器能无缝地跟属性表的验证、持久化系统配合，不会掉链子。 简单说，记住六进一出，外加错误回显，你的编辑器就稳了。这节课就到这里，下回我们看看怎么动手写一个。