Improve representation of non FEEL languages

[nikku]

Is your feature request related to a problem? Please describe.

As more people adapt element templates for domain-specific configuration we'll see the need to embed non-FEEL going to see more extensions for non FEEL domain specific languages. While I don't necessarily expect full editor tooling I do expect monospace editing and decent sizing of the input.

Example: Embed a GraphQL query / mutation editor in an element template:

Describe the solution you'd like

• Support text editors other than FEEL
  • Display content as monospace font (feat: render Text#language fields using monospace font #869)
  • Ensure editor grows with content (feat(cloud-element-templates): make Text fields auto-resizable #870)

A potential follow-up is #871.

Describe alternatives you've considered

Leave things as is.

Additional context

Brought up in the context of camunda/connectors#202.

---

The following connector can be used to verify the new capabilities: graphql-connector.json.

[nikku]

Dumping my thoughts on a potential solution to this issue.

Sketch

• Allow lang or type to be define on textarea input bindings

  {
    "name": "My special Template
    ...
    "properties: [
      {
        "label": "Query/Mutation",
        "type": "Text",
        "language": "graphql",
        "binding": {
          "type": "zeebe:input",
          "name": "graphql.query"
        }
      }
    ],
    ...
  }

• Allow to plug in editors (with a well defined contract) for a type
• Default to a (reasonable) monospace editor fallback if no editor for defined type is found.

Analysis

• Allows custom editors to be configured and plugged-in (i.e. via an extension)
• Gracefully handles "editor missing"
• Allows us to define a contract for such editors, and potentially move over our feel editor, too

[marstamm]

My Thoughts on this:

• From a user perspective, setting the language would be the best, I agree.
• While the plugin system sounds good, I'm not sure if users will actually use it or if we could just have a lightweight multi-editor in the properties-panel. syntax highlighting for common languages could either be achieved by reusing codemirror or with a light-weight regex based solution

I think we can already move ahead and improve the user experience without a full picture around the plugin API:

• Allow the language property in the JSON schema
• when it is used, set monospace on the default Text area https://github.com/bpmn-io/properties-panel/blob/main/src/components/entries/TextArea.js#L26
• Adjust TextArea behavior to auto-expand

[nikku]

I think we can already move ahead and improve the user experience without a full picture around the plugin API:

Absolutely agreed. 💯

[nikku]

As a first step camunda/element-templates-json-schema#89 introduces a language field for Text areas.

[nikku]

Closing this as fixed:

#871 is a valid follow-up.

[nikku]

Created #872 as a follow up.