Property Editor — UI, XML Config & Guidelines

好，同学们，咱们这节课来看一个很实用的知识点——怎么给 Lightning Web Components 构建自定义的属性编辑器，以及设计它的时候必须遵守哪些硬规矩。 首先，在做个属性编辑器的时候，你在 UI 上拥有完全的设计自由度。什么意思呢？就是你可以用任何你觉得合适的 HTML 和 CSS，去打造你想要的编辑体验。比如，咱们例子里面用到了 `lightning-button-group` 和 `lightning-button-icon-stateful` 来做视觉上的对齐选择器，看起来就很直观。只要让构建器（Builder）知道这是个属性编辑器就行，这需要在组件里配置一个叫做 `Lightning__PropertyEditor` 的目标。 链接的时候，只要在属性标签上指定 `editor` 属性，指向你这个编辑器就可以了。 但最关键的是，有五个非常重要的准则，你一定得刻在脑子里，违背了这些，你的编辑器在体验构建器（Experience Builder）里就会翻车。 ，第一条，永远、绝对不要在编辑器里自己做验证。， 这是一个最常见的错误。属性面板自己会根据你定义的类型模式来处理验证的事。如果你自己设了自定义错误，或者试图阻止值的变化，这叫反模式，破坏了契约。简单说，别越权，把验证交给系统。 ，第二条，不要用弹出窗口或模态框。， 为什么？因为它们会打断 Builder 的工作流程。用户正编辑着组件呢，突然弹出个东西，体验非常糟糕。所以，任何需要弹出的交互统统避免。 ，第三条，绝对别用绝对定位。， CSS 里的 `position: absolute` 不能用，因为它会导致布局对不齐，在属性面板里看起来会歪歪扭扭，非常不专业。 ，第四条，别随便设置 CSS 的 `width` 属性。， 属性面板有自己的宽度规则，你强行设置宽度值，比如 `width: 300px`，会直接影响面板的大小，破坏整个统一性。所以，别动宽度。 ，第五条，值的触发时机要控制好。， 不要在每次键盘输入（也就是每按一个键）的时候就触发值的变化。这么做会导致画布剧烈刷新，Builder 性能会直线下降。正确做法是，只在提交事件上触发值改变，比如输入框失去焦点（blur）的时候，或者点击按钮确认的时候。这样既能保证性能，又符合最佳实践。 好了，这五点准则记住了，你就能做出流畅、可靠的自定义属性编辑器。简单总结一下：不验证、不弹窗、不绝对定位、不设宽度、不频繁触发值变化。把它们当成铁律，你的组件在 Experience Builder 里就能工作得很好。 下节课我们接着聊怎么样通过这些编辑器打造更复杂的配置面板，大家有什么问题随时提。