Create POC of using Slate for expression editor

twschiller commented 3 years ago

Context

Each brick takes input as determined by it's JSON Schema input schema
PixieBrix automatically renders brick configuration fields based on the schema
PixieBrix supports a couple ways for passing args to a bricks:
- Providing a path to a variable (see here for parsing implementation)). (This implicit form isn't good, as it break when working with optional/conditional values; we'll likely drop support for this naked format in the near future)
- Passing a string with with support for templating engines (Mustache, Handlebars, Nunjucks)
These expressions are plain text, and can be written in the Workshop using YAML. Here's an example of wiring up search

Implementation Sketch

Add the https://www.slatejs.org/ library as a dependency
Create an ExpressionEditor component. (E.g., in this directory)
Add the component to Storybook (see CreateableAutosuggest for an example)

Requirements

Must Have

Decorate 1) naked paths, and 2) must have place holders
On mouse hover, show additional detailed information about the expression

Nice to Have

When focused on a blank text entry, show auto complete for naked paths
When user types {{ show autocomplete

Assumptions

For the POC, you don't have to formally parse the text for Mustache/Template expressions. You can use regexes and grab the index

You can assume:

You can assume the text will be either a naked path or a simple mustache template (i.e., no conditionals, no nunjucks, etc.)
The component takes a JSON Schema that says which data is known to be available in the context.
The top-level of the schema is "object"
The schema only contains object or primitive types

In practice, this input be generated by merging to together provided/inferred JSON Schemas. For example:

{
   type: "object",
   properties: {
     member: {
       type: "object",
       properties: {
         firstName: {
           type: "string",
           source: "JQuery Reader", 
           examples: ["Harry"],
         },
         lastName: {
           type: "string",
           source: "JQuery Reader",
           examples: ["Potter"],
         },
       }
       required: ["firstName"]
     },
     "@flag": {
       type: "boolean",
       source: "Read Form",
       examples: [false]
     }
   }
   required: ["member", "@flag"]
}

References/Related

1022
1020, future work on UX for providing expressions for non-strings
https://jkrsp.com/slate-js-vs-draft-js/: Slate is native TypeScript
Example: mentions in slatejs
Example: implementing decorations in slatejs
Docs: decorations
Mustache JS parser - might be a dead end since it doesn't give characters

FAQs

Is the intent for this component is to be a richtext replacement for what is currently a plain textarea where mustache templates are used to create dynamic HTML templates?

Currently we have either a normal text or textarea import. These aren't just used for HTML templates, they're more generally used to wire up inputs to a brick

How "rich" is it intended to be? Should it be fully WYSIWYG or should it still show the user HTML code, focusing more on enhancing the experience with rich tokens for inserting dynamic content tokens?

The main focus is handling the dynamic content tokens

We won't be using any the rich formatting (e.g., bolding, etc.). (In the future, we might use the for markdown-formatted inputs, though (see #404)

Is there an expected output format for the editor? Should it generate mustache templates? Nunjucks? Or do we want to just use slate's JSON AST format? And should the user be able to switch between a raw source code mode and the rich experience on the fly?

The output format for the editor should be plain text.

For the record, it seems to weigh about 110Kb

If we go this route, we'll async load it into the devtools pane. It shouldn't be a performance problem in practice

Is this a direct solution to #1022? i.e. is it to provide highlighting? Because it looks more like a full text editor than a simple syntax highlighter.

We also want to test the experience for content tokens that show additional context information on hover

fregante commented 3 years ago

Is this a direct solution to https://github.com/pixiebrix/pixiebrix-extension/issues/1022? i.e. is it to provide highlighting? Because it looks more like a full text editor than a simple syntax highlighter.

For the record, it seems to weigh about 110Kb

github-actions[bot] commented 9 months ago

This issue will be closed in 7 days unless the stale label is removed, or a comment is added to the issue.

pixiebrix / pixiebrix-extension