Closed theinfinit closed 3 months ago
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.
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 withfields
instead offieldGroup
as described in the documentation. And it is almost working.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:
Expected behavior
It's expected for "Content type actions" to generate valid, working fields. Additionally, editing and adding new records while using
fields
withblock
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):
v10.2.9129636
Additional context: Generated part of the config