Issue: Content type actions generate half-functioning `block` fields.
theinfinit opened this issue · comments
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.
- Records can be correctly removed and swapped,
- 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:
- 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
---
- Click on 'Add missing fields'
- 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 :)
front-matter-block-with-fields.mp4
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"
}
]
},
]
}
]
},
Thanks for opening an issue for this. Some enhancements are required to support more "complicated" structures.
@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:
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?
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.
That will be great. It is pretty common case, that discriminator is not used for arrays of objects of the same type.