Custom Property Editor — Screen Component & Generic SObject

好的同学，今天我们来讲一讲屏幕组件自定义编辑器这块的内容。别担心，虽然一开始听起来有点复杂，但我会用最简单的话，一步一步带你走完。 首先，屏幕组件都知道吧？就是在Flow里拖出来，让用户交互的那些组件。有时候我们需要给这些组件在Flow设计器里提供一个更友好的编辑界面，好让管理员能方便地配置组件属性。这时候就需要自定义编辑器了。 那怎么让一个屏幕组件知道自己用的是哪个编辑器呢？其实很简单，就在组件的元数据配置文件里，也就是那个xml文件里，有个叫`targetConfig`的配置项，它下面可以指定一个`editor`属性，把自定义编辑器的名字填上，这就注册好了。就像告诉系统：“嘿，我这个组件，配置的时候别用你默认的样子，用我给你的那个编辑器来展示。” 好，我们来看一个典型的例子——音量滑动器组件。这个例子很经典，它展示了一个完整的编辑器长什么样。它里面有个关键的设计模式：通过一个私有字段 `_inputVariables` 来保存所有的输入变量。编辑器怎么读这些变量呢？它定义了一个 `inputVariables` 的 getter/setter。这样当Flow传值进来，它就能存到那个私有字段里。然后为了方便取某个具体值，它还会写一些专门提取属性的 getter，比如要获取最小音量，就写一个 `minVolume` 的 getter，直接从 `_inputVariables` 里把对应值找出来。 接下来是校验问题。编辑器里可能要做一些自定义校验，比如音量滑动器要检查最大值是不是大于最小值。它用了 `validate()` 方法，在这里写校验逻辑。如果发现有问题，就调用滑动器组件自带的 `setCustomValidity` 方法，这个方法能在组件上直接显示一个内联的错误提示，而不需要弹窗，非常直观。 另外，当用户在编辑器里改了配置，需要把这个变化同步出去。这里用的是 `Inbox Change` 调度事件。具体来说，当值发生变化，编辑器会触发一个叫 `_changed` 的事件，并且告诉系统这个值是 `Number` 类型。这样Flow就能收到通知，刷新预览什么的。 好，我们再来看看通用的 `sObserver` 输入怎么处理。有时候组件需要处理任意类型的对象，比如一个Record，我们不想写死具体是哪个对象类型，就要用泛型。在组件的 `.js-meta.xml` 里面，可以定义一个叫 `Property Type` 的子标签，用来声明泛型参数。比如我写一个名字叫 `T`，并且指定它要继承自 `SObject`（这里原意是 extends='SObitch’，应该是笔误，指SObject）。然后在组件的属性类型里，我们就可以用 `{T}` 来表示这个泛型。如果是一个集合，就写 `{T[]}`。这样组件的适用范围一下就大了。 那编辑器里怎么获取和设置这个泛型实际传入的类型呢？这时候就会使用 `genericTypeMappings` 接口。这个接口就像个字典，把泛型符号 `T` 映射到它真实代表的SObject类型名称。通过它，编辑器就能知道用户到底选了Lead还是Account，从而把具体的值取出来或者设进去。 最后说一下“收件箱惯例”的差异。这是一个很容易混淆的点。屏幕组件和可调用操作（比如Apex Action）在处理泛型时的命名规则不一样。屏幕组件很直白，直接用普通的属性类型名称就行了，比如刚才的 `{T}`。但是在可调用操作里，输入泛型要在前面加个特殊前缀，变成 `T__prective`，输出泛型则用 `U__prective`。这个前缀是平台自动给你加上去的，你不需要手动干预，但要知道有这回事，不然在代码里看到会很懵。所以记住：屏幕组件用原样，可调用操作加前后缀。 好了，今天的内容就到这里。我们回顾一下：编辑器注册靠 `targetConfig` 的 `editor` 属性；音量滑动器展示了典型的 getter/setter 模式、属性提取 getter、`validate` + `setCustomValidity` 内联校验，以及 `_changed` 事件调度值；通用输入通过 `Property Type` 定义泛型，用 `{T}` 或 `{T[]}` 引用，编辑器通过 `genericTypeMappings` 获取具体类型；而命名惯例上，屏幕组件不加前缀，可调用操作要加 `__prective`。好，大家消化一下，有问题随时提。