[Design Proposal]Editor Service to specify custom editors in V3 designer

[shuktika12163]

Describe the Bug with repro steps

This is a feature request for editor service that existed in V1 but doesn't in V3. This would allow host services to specify custom editors for operations if they need to.

Business need: We have a couple of connectors that want to customize information in parameter panel such as a disclaimer text, or a button if a specific parameter is present. Example: AI Builder connector has a special editor for "Create prompt" button that opens a side panel and helps/guides users in creating a prompt for their parameter.

V1 Editor Service

In V1, we had an editor service to display custom editors for parameters if defined, otherwise fallback to existing editors.

Editor service in V1: https://msazure.visualstudio.com/One/_git/AzureUX-BPMUX?path=/src/core/services/editor.ts&version=GBmaster&line=241&lineEnd=252&lineStartColumn=1&lineEndColumn=2&lineStyle=plain&_a=contents

export interface EditorService {
    getEditorType(connectorId: string, operationId: string, parameterKey: string, schema: Schema): EditorType<any> | undefined;
}

Usage of editor service in V1 to display custom editor: https://msazure.visualstudio.com/One/_git/AzureUX-BPMUX?path=/src/core/components/parameterbasecontainer.tsx&version=GBmaster&line=695&lineEnd=698&lineStartColumn=9&lineEndColumn=10&lineStyle=plain&_a=contents

 protected getParameterEditor(...): JSX.Element {
        const customEditorFromService = this._getCustomEditorFromService(parameterInfo, parameterComponentRefs);
        if (customEditorFromService) {
            return customEditorFromService;
        }
        ...
        <non-custom editors code>
}

Proposed Design for V3 Custom Editors

In V3, we currently have no way of specifying a custom editor, so the parameters in connectors have to use one of the existing LAUX editors as specified in TokenField function of settingTokenField file (https://github.com/Azure/LogicAppsUX/blob/main/libs/designer-ui/src/lib/settings/settingsection/settingTokenField.tsx#L70)

Our proposal is to add an editor service to V3 (similar to V1) as an optional service that can be passed to designer, along with other services (https://github.com/Azure/LogicAppsUX/blob/main/libs/designer/src/lib/core/state/designerOptions/designerOptionsInterfaces.ts#L26):

export interface ServiceOptions {
    <existing services>,
    editorService?: IEditorService
}

export interface IEditorService {
    getEditor(connectorId: string, operationId: string, parameterKey: string, schema: Schema): React.FunctionComponent<BaseEditorProps>;
}

Editor service will be initialized in designer-client-services similar to other services.
The host service can choose to implement EditorService to return custom editors for specific parameters. Custom editors will be react function components that use BaseEditorProps and return JSX.Element.

EditorService will be used to return custom editor if it exists, otherwise fallback to existing editor picker code (rough code):

const TokenField = ({...}: SettingTokenFieldProps & { labelId: string }) => {
  const dropdownOptions = editorOptions?.options?.value ?? editorOptions?.options ?? [];
  if (EditorService()) {
     const customEditor = EditorService().getEditor(connectorId, operationId, parameterKey, schema);
     if (customEditor) {
        return customEditor;
     }
  }
  switch (editor?.toLowerCase()) {

Open questions:

1. We need to find a good way to pass operationInfo (connectorId and operationId), parameterKey to TokenField for use by getEditor function. The computation for customEditor can be done at a higher level outside TokenField and the customEditor value can be passed to this function instead. Looking for LAUX team's expertise on how this part can be done best.

What type of Logic App Is this happening in?

Consumption (Portal)

Are you using Preview Designer or GA Designer

Preview

Did you refer to the TSG before filing this issue? https://aka.ms/lauxtsg

Yes

Workflow JSON

No response

Screenshots or Videos

Current AI Builder connector in V1 designer using custom editor "Create prompt" button and string disclaimer. The button can be clicked to pop up a side panel to help users customize their input:

The same action in V3 designer (missing custom editor):

Browser

All

Additional context

No response

AB#24221306

[preetriti1]

One thing to note here, if a custom editor is added everything for that editor should be implemented by the host, it cannot keep using basic components from designer UI or have some calback hooks to get them.
Now for your open question - We can pass in the props for customEditor in our settingTokenField from parametersTab/index.tsx so when that is set we will render it rather looking for editorType in our current editor list. Passing custom editor from parameterstab will have all details from redux store like operationInfo and parameterSchema... and also a funtion to get token picker if that is needed.

[shuktika12163]

Thanks Priti, that makes sense. We would read some values as part of editor props or similar (like parameterSchema and operationInfo). getTokenPicker would be another function that'll be part of editor props.

For the part it cannot keep using basic components from designer UI or have some calback hooks to get them, do you mean we cannot export and use existing editors such as BaseEditor either? For example, if we create a custom editor in host service that renders some custom elements but also wants to render BaseEditor as part of the custom editor's render function, is it alright to export BaseEditor and use it in host service's custom editor's render function?

[hartra344]

I think I'm fine with custom editors using things such as base editor or common components. But by breaking the glass here, you are signing up to react to breaking changes. it's not an officially supported API so it may break without having a breaking change tag or notification.

[shuktika12163]

@Aleks-gdb brought up a good suggestion where instead of rendering editor based on connectorId, operationId and parameter, we can render editor based on editor type sent as part of operation manifest (in custom editor service implemented in host). This was done for manual trigger floatingactionmenu too.

Editor service interface:

export interface IEditorService {
    getEditor(editor: string, schema: Schema): React.FunctionComponent<BaseEditorProps> | undefined;
}

Host service implementation:

export class EditorService implements IEditorService {
    public getEditor(editor: string, schema: Schema): React.FunctionComponent<BaseEditorProps> | undefined {
         switch (editor?.toLowerCase()) {
              case <xyz>:
                   return <xyzEditor />;
              default:
                   return undefined;
         }
    }
}

Operation Manifest change - add property for input:
{ SwaggerConstants.EditorTypeExtensionPropertyName, "xyz" },

Potential problem: Updating manifest for common shared connectors across orgs might break things

[hartra344]

I don't like the idea of this being complex enough that it would require breaking changes across connectors. Especially since in 99% of cases the point of this is for 1 off editors needed for specific use cases.

[cdgolmar-msft]

I'm opening PR #2996 to implement the design discussed here.