Editor-field Output

[OleVik]

Can the Editor-field output processed code, rather than an escaped string? Using a simple initialization:

styles:
  classes: frontmatter
  type: editor
  label: Styles
  autofocus: true
  codemirror:
    mode: 'yaml'
    indentUnit: 2
    indentWithTabs: false
    lineNumbers: false
    styleActiveLine: true
    gutters: ['CodeMirror-lint-markers']
    lint: true

With this in the editor:

- background: beige
  color: cyan
- background: cyan
  color: beige

This outputs:

styles: "- background: \"beige\"\r\n  color: \"cyan\"\r\n- background: cyan\r\n  color: beige"

However, I need it to output the actual input rather than this escaped output for it to be valid YAML that matches the original YAML-file. It feels like I'm overlooking something, but the Editor-field seems the most straightforward way to keep the simplicity of this input.

[flaviocopes]

The editor will always save as a string, escaped as needed.

The best option would be a list with 2 text fields into it for background and color.

[OleVik]

Lists and Arrays are too limiting in this regard, as they complicate the syntax and restrict the available properties to just background and color, whereas the abstract syntax will take any CSS-property and apply the value to it. Like the example above, this is valid YAML:

styles:
  - background: red
    color: red
    padding: 10em
  - background: green
    color: green
    padding: 8em
  - background: blue
    color: blue
    padding: 6em

In the case of duplicate keys, the latest value in each list is effected. This allows a series of simple, or complex, themes to be defined and applied cyclically. Since the syntax is essentially lists of arrays within styles, I tried a list-field with nested array:

styles:
  name: styles
  type: list
  style: vertical
  label: Styles
  fields:
    .items:
      type: list
      label: Style
      fields:
        .item:
          type: array
          label: Styles
          placeholder_key: Property
          placeholder_value: Value
          validate:
            type: array

But this returned some remarkably formatted YAML:

styles:
  0:
    items:
      0:
        item: { background: red }
      1:
        item: { color: red }
      '*':
        item: { padding: 10em }
  1:
    items:
      0:
        item: { background: green, color: green }
      '*':
        item: { padding: 8em }
  '*':
    items:
      0:
        item: { background: blue, color: blue }
      '*':
        item: { padding: 6em }

Currently the most viable solution would be the editor-field, though of course the syntax is unreadable for anything more than a simple background and color. Seemingly, #1135 might be a much more elegant solution.

[paulmassen]

Without array, you could have something close of what you want, something like:

                    header.styles.items:
                      name: styles
                      type: list
                      label: Styles
                      fields:
                        .item:
                          type: list
                          label: add
                          fields:
                            .prop:
                              type: text
                              label: property
                            .val:
                              type: text
                              label: value

[OleVik]

Close, but no cigar. As noted, the virtue of the implementation is its direct relation to CSS: Simply an array of property:value statements, that can be repeated cyclically. Using the new multilevel-field, up to commit ab7583e, I get basically exactly what I'm looking for. The same input as above will output:

styles:
  -
    background: red
    color: red
    padding: 10em
  -
    background: green
    color: green
    padding: 8em
  -
    background: blue
    color: blue
    padding: 6em

Thus, this new field behaves exactly as expected from input to output. I assume you'll document its usage when its done, @flaviocopes? Currently adding new values is not really working, the key disappears from sub-levels and there is no plus-sign to add a new top-level item.

[rhukster]

Please let flavio know any issues on the PR itself, that will keep everything nice and tidy.

[OleVik]

Will do. Closing this as the original question is answered, and the solution lies in that PR.