feat: use uischema to define Flow Actions

[yeze322]

Description

closes #2955

Convert Flow Editor's schema to pure JSON format. (builtinSchema.ts)

Tasks

• Integrate with adaptive-expressions
• convert flow schema from TSX to pure JSON format
• inject Flow Actions schema from uischema

Following tasks on other repos

• Update the JSON schema of uischema.
• Move 'flow' uischema from 'ui-plugins/composer' to SDK component schema.

Schema Preview
IfCondition

[SDKKinds.IfCondition]: {
  widget: 'IfConditionWidget',
  nowrap: true,
  judgement: {
    widget: 'ActionCard',
    body: '=coalesce(action.condition, "<condition>")',
  },
}

BeginDialog

[SDKKinds.BeginDialog]: {
  widget: 'ActionCard',
  body: {
    widget: 'DialogRef',
    dialog: '=action.dialog',
  },
  footer: {
    widget: 'PropertyDescription',
    property: '=action.resultProperty',
    description: '= Return value',
  },
  hideFooter: '=!action.resultProperty',
}

SetProperties

[SDKKinds.SetProperties]: {
  widget: 'ActionCard',
  body: {
    widget: 'ListOverview',
    items: '=foreach(action.assignments, x => concat(x.property, " : ", x.value))',
  },
}

SetProperty (string interpolation in LG format)

[SDKKinds.SetProperty]: {
  widget: 'ActionCard',
  body: '${coalesce(action.property, "?")} : ${coalesce(action.value, "?")}',
},

Task Item

Screenshots

Use sdk.override.uischema to demo the scenario.

• Original EditArray node:
  
• Define the overrided Flow schema in sdk.override.uischema:

{
  "$schema": "https://schemas.botframework.com/schemas/ui/v1.0/ui.schema",
  "Microsoft.EditArray": {
    "flow": {
      "widget": "ActionCard",
      "header": {
        "widget": "ActionHeader",
        "title": "Overrided Edit Array",
        "icon": "Edit",
        "colors": {
          "theme": "#168686",
          "color": "white",
          "icon": "white"
        }
      },
      "body": "=concat('Change Type: ', action.changeType, '\nItems Property: ', action.itemsProperty)",
      "footer": "=string(action.value)",
      "hideFooter": "=!action.resultProperty"
    }
  }
}

• With the overrided Flow schema, EditArray will look like this:
  

[coveralls]

Coverage increased (+0.2%) to 55.925% when pulling 589e4d2 on yeze322:visual/flow-schema into b0f2fd8 on microsoft:main.

[cwhitten]

@yeze322 as we discussed last night. I agree that we should allow basic data binding into the uischema, however I don't think we shouldn't promote users to inline HTML like that.

Can you come up with a few example expressions that you need to render the widgets currently so we can think on how to model the expressiveness you are looking for?

[yeze322]

@cwhitten Chris I updated the description with newest example schema

[yeze322]

As I tested in both LG/Expression, we have multiple approaches to write a string interpolation

// 1. LG
'Hello ${user.name}.'

// 2. Expression
'=concat("Hello ", user.name)'

// 3. Expression - with string interpolation
'=`Hello ${user.name}`'

A restriction in Expression is that string interpolation needs to be wrapped in ``.

// Can be evaluated by Expression -> Expression class
'`Hello ${user.name}`'

// Can be evaluated by Expression -> ValueExpression class
'=`Hello ${user.name}`'

// Can be evaluated by LG
'Hello ${user.name}'

@a-b-r-o-w-n Which one would you prefer? I have no strong opinions. We can support both but the default Flow uischema as a sample needs to be in a uniform format.

[a-b-r-o-w-n]

@yeze322 I think matching the sdk properties as closely as possible would be best. So to me that looks like we should use the LG parser for string interpolation.

[yeze322]

@yeze322 I think matching the sdk properties as closely as possible would be best. So to me that looks like we should use the LG parser for string interpolation.

I updated the schema, the Action ‘SetProperty' is an example on how string interpolation be written LG format.

One thing to note is writting string interpolation in LG format can simplify the schema in some case but not all the cases. Expression engine is still required regarding sometimes we want to take the raw value instead of getting a string.

For example, in BeginDialog, dialog field could be a string or a IDialog object. We have to write =action.dialog instead of ${action.dialog} because of the latter one will return a string. This is LG parser's default behavior.

[a-b-r-o-w-n]

That sounds reasonable and is the same as when authoring bots, so hopefully the learning curve will be small.

I think we should consider adding this functionality to the form properties in the ui schema as well.

[a-b-r-o-w-n]

@yeze322 sorry for all the conflicts. I removed the extensions directory 😕

[yeze322]

@a-b-r-o-w-n that's fine Andy, it's just some import conflicts