adam/vscode-front-matter
1
0 Fork 0
mirror of https://github.com/estruyf/vscode-front-matter.git synced 2026-11-03 09:02:19 +01:00
Code Issues 77 Packages Projects Releases Wiki Activity

Issue: Content type actions generate half-functioning block fields. #636

New Issue
Closed
opened 2026-10-05 02:57:48 +02:00 by adam · 5 comments
adam commented 2026-10-05 02:57:48 +02:00
Owner
Copy link
Copy source

Describe the bug

I have used the Content type action "Add missing fields" to generate missing fields based on the frontmatter.

It generated structure that is using block type with fields instead of fieldGroup as described in the documentation. And it is almost working.

  1. Records can be correctly removed and swapped,
  2. but editing and adding new records doesn't seem to work.

The generated structure is actually great, and what I would expect. Defining working structures like this without fieldGroup property will be really handy, as it is often unnecessary for creation of working frontmatter schema.

To Reproduce

Steps to reproduce the behavior:

  1. Add missing field to the frontmatter:
---
hero:
  title: |
    Welcome to Starlight
  tagline: Congrats on setting up a new Starlight project!
  image:
    file: ~/assets/houston.webp
  actions:
    - text: Example Guide
      link: /guides/example/
      icon: right-arrow
      variant: primary
    - text: Read the Starlight docs
      link: https://starlight.astro.build
      icon: external
---
  1. Click on 'Add missing fields'
  2. See generated fields.

Expected behavior

It's expected for "Content type actions" to generate valid, working fields. Additionally, editing and adding new records while using fields with block will be valuable addition.

Screenshots

As you can see, each object is properly recognized and swapped, so it seems like any kind of discriminator (like fieldGroup) is not necessary for Front Matter CMS to recognize and handle the objects correctly. But addition is for sure more complex :)

https://github.com/estruyf/vscode-front-matter/assets/33784221/f9fb748c-3947-4fa8-9bcb-d2cd2d5ac9d0

Desktop (please complete the following information):

  • OS: Win11
  • Version: Beta v10.2.9129636

Additional context: Generated part of the config

  {
    "title": "hero",
    "name": "hero",
    "type": "fields",
    "fields": [
      {
        "title": "title",
        "name": "title",
        "type": "string"
      },
      {
        "title": "tagline",
        "name": "tagline",
        "type": "string"
      },
      {
        "title": "image",
        "name": "image",
        "type": "fields",
        "fields": [
          {
            "title": "file",
            "name": "file",
            "type": "string"
          }
        ]
      },
      {
        "title": "actions",
        "name": "actions",
        "type": "block",
        "fields": [
          // Note: It actually generated two objects, for each entry present in the frontmatter
          {
            "title": "0",
            "name": "0",
            "type": "fields",
            "fields": [
              {
                "title": "text",
                "name": "text",
                "type": "string"
              },
              {
                "title": "link",
                "name": "link",
                "type": "string"
              },
              {
                "title": "icon",
                "name": "icon",
                "type": "string"
              },
              {
                "title": "variant",
                "name": "variant",
                "type": "string"
              }
            ]
          },
        ]
      }
    ]
  },
## **Describe the bug** I have used the [Content type action](https://frontmatter.codes/docs/panel#content-type-actions) "Add missing fields" to generate missing fields based on the frontmatter. It generated structure that is using `block` type with `fields` instead of `fieldGroup` [as described in the documentation](https://frontmatter.codes/docs/content-creation/fields#block). And it is _almost_ working. 1. Records can be correctly removed and swapped, 2. but editing and adding new records doesn't seem to work. The generated structure is actually great, and what I would expect. Defining working structures like this without `fieldGroup` property will be really handy, as it is often unnecessary for creation of working frontmatter schema. ## **To Reproduce** Steps to reproduce the behavior: 1. Add missing field to the frontmatter: ```md --- hero: title: | Welcome to Starlight tagline: Congrats on setting up a new Starlight project! image: file: ~/assets/houston.webp actions: - text: Example Guide link: /guides/example/ icon: right-arrow variant: primary - text: Read the Starlight docs link: https://starlight.astro.build icon: external --- ``` 2. Click on 'Add missing fields' 3. See generated fields. ## **Expected behavior** It's expected for "Content type actions" to generate valid, working fields. Additionally, editing and adding new records while using `fields` with `block` will be valuable addition. ## **Screenshots** As you can see, each object is properly recognized and swapped, so it seems like any kind of discriminator (like `fieldGroup`) is not necessary for Front Matter CMS to recognize and handle the objects correctly. But addition is for sure more complex :) https://github.com/estruyf/vscode-front-matter/assets/33784221/f9fb748c-3947-4fa8-9bcb-d2cd2d5ac9d0 --- **Desktop (please complete the following information):** - OS: Win11 - Version: Beta `v10.2.9129636` ## **Additional context:** Generated part of the config ```js { "title": "hero", "name": "hero", "type": "fields", "fields": [ { "title": "title", "name": "title", "type": "string" }, { "title": "tagline", "name": "tagline", "type": "string" }, { "title": "image", "name": "image", "type": "fields", "fields": [ { "title": "file", "name": "file", "type": "string" } ] }, { "title": "actions", "name": "actions", "type": "block", "fields": [ // Note: It actually generated two objects, for each entry present in the frontmatter { "title": "0", "name": "0", "type": "fields", "fields": [ { "title": "text", "name": "text", "type": "string" }, { "title": "link", "name": "link", "type": "string" }, { "title": "icon", "name": "icon", "type": "string" }, { "title": "variant", "name": "variant", "type": "string" } ] }, ] } ] }, ``` <!-- github-sync-id:2303235992 -->
adam closed this issue 2026-10-05 02:57:48 +02:00
adam commented 2026-10-05 02:57:49 +02:00
Author
Owner
Copy link
Copy source

Thanks for opening an issue for this. Some enhancements are required to support more "complicated" structures.

Thanks for opening an issue for this. Some enhancements are required to support more "complicated" structures. <!-- github-comment-id:2123229642 -->
adam commented 2026-10-05 02:57:50 +02:00
Author
Owner
Copy link
Copy source

@theinfinit I have added support for your sample in the latest beta.

The above example should now generate a new field group:

{
  "frontMatter.taxonomy.fieldGroups": [
    {
      "id": "actions_group",
      "fields": [
        {
          "title": "text",
          "name": "text",
          "type": "string"
        },
        {
          "title": "link",
          "name": "link",
          "type": "string"
        },
        {
          "title": "icon",
          "name": "icon",
          "type": "string"
        },
        {
          "title": "variant",
          "name": "variant",
          "type": "string"
        }
      ]
    }
  ]
}

And map this group in for the block field:

{
  "title": "actions",
  "name": "actions",
  "type": "block",
  "fieldGroup": [
    "actions_group"
  ]
}

This allows you to change the values from the UI:

Image

@theinfinit I have added support for your sample in the latest beta. The above example should now generate a new field group: ```json { "frontMatter.taxonomy.fieldGroups": [ { "id": "actions_group", "fields": [ { "title": "text", "name": "text", "type": "string" }, { "title": "link", "name": "link", "type": "string" }, { "title": "icon", "name": "icon", "type": "string" }, { "title": "variant", "name": "variant", "type": "string" } ] } ] } ``` And map this group in for the `block` field: ```json { "title": "actions", "name": "actions", "type": "block", "fieldGroup": [ "actions_group" ] } ``` This allows you to change the values from the UI: ![Image](https://github.com/estruyf/vscode-front-matter/assets/2900833/8a2780a9-992c-4180-b026-f6542c2474e8) <!-- github-comment-id:2126597370 -->
adam commented 2026-10-05 02:57:51 +02:00
Author
Owner
Copy link
Copy source

Thank you Elio for the fast response! I appreciate your dedication.

I tested your example with beta v10.2.9211615. I can edit the fields now. Output of the Content type action improved a lot too.

The only thing that is bothering me, is the added fieldGroup field. For simple cases like this, where we have an array of objects (each with the same schema). And considering the editing capabilities of the current solution — I would advocate for the ability to disable the addition of the fieldGroup.

Why?
Sometimes the frontmatter schema is configured in a strict way and doesn't allow the unknown fields. In such cases, you'll have to extend the schema with dummy fieldGroup field to make things work again.

Also, for more complex cases, and easier integration with existing websites, the ability to rename the fieldGroup discriminator, would help with the adoption of the Front Matter CMS.

What do you think?

Thank you Elio for the fast response! I appreciate your dedication. I tested your example with `beta v10.2.9211615`. I can edit the fields now. Output of the [Content type action](https://frontmatter.codes/docs/panel#content-type-actions) improved a lot too. The only thing that is bothering me, is the added `fieldGroup` field. For simple cases like this, where we have an array of objects (each with the same schema). And considering the editing capabilities of the current solution — I would advocate for the ability to disable the addition of the `fieldGroup`. **Why?** Sometimes the frontmatter schema is configured in a strict way and doesn't allow the unknown fields. In such cases, you'll have to extend the schema with dummy `fieldGroup` field to make things work again. --- Also, for more complex cases, and easier integration with existing websites, the ability to rename the `fieldGroup` discriminator, would help with the adoption of the Front Matter CMS. What do you think? <!-- github-comment-id:2127786417 -->
adam commented 2026-10-05 02:57:51 +02:00
Author
Owner
Copy link
Copy source

The fieldGroup property was introduced because there are situations where multiple types of field groups were added. The fieldGroup property links it with the correct group.

We can look into removing this property when only one group is defined. For that we best create a new issue to track its progress.

The `fieldGroup` property was introduced because there are situations where multiple types of field groups were added. The `fieldGroup` property links it with the correct group. We can look into removing this property when only one group is defined. For that we best create a new issue to track its progress. <!-- github-comment-id:2127809667 -->
adam commented 2026-10-05 02:57:52 +02:00
Author
Owner
Copy link
Copy source

That will be great. It is pretty common case, that discriminator is not used for arrays of objects of the same type.

That will be great. It is pretty common case, that discriminator is not used for arrays of objects of the same type. <!-- github-comment-id:2141932403 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/vscode-front-matter#636