Thinkmill
Image component causing Astro to crash
When you use fields.image and save item without image selected the image component is removing the key from mdoc frontmatter, which in turn i causing Astro to crash as the field is missing from schema... I think instead empty string should be saved as value
I see how this can create problems. Not sure about storing an empty string though, because the image field stores a reference to an image it stores on your file system.
If your schema is expecting an image in all cases, you should probably make the image field required with validation: { isRequired: true }, to make sure an image is always uploaded.
Or, alternatively, make the image .optional() in your Astro content collection Zod schema.
Thanks for the advice, will do that. It looks like it applies to other fields too, when no value is provided the key is removed. Not sure about the image but empty string for other fields would be just better DX... But overall great work, Thank you!
What do you mean by "safe[ to close]"?
It means a few things, I suppose:
- is this still relevant?
- is this a genuine issue or invalid/unexpected configuration, and should that be documented?
- is there a known workaround, and should that be documented?
- can this be fixed given the current architecture?
Ultimately, "what context do you have such that I can better diagnose the problem and/or attribute the issue?"
So you cannot replicate the bug? Is something unclear in the description? What?
The issue is that keystatic is modifying user's data without permission or notification. In what universe is it "save" to ignore???
Sensing some hostility. Sorry mate, was just trying to do some triage after work before dinner.
So you cannot replicate the bug? Is something unclear in the description? What?
In case it wasn't clear from the mention: I'm asking Simon for more information.
I tend to agree that text fields, if empty, should store an empty string instead of removing the key (unless there's a good reason not to).
Let's keep this issue open for now — but once again, a workaround until this possibly changes is to make the field required via the validation options at the field level 👍
Will revert back re: other fields.