Enabling drafts causes required GraphQL fields to be nullable
Hey there! I noticed that enabling drafts on a collection seems to cause the required fields in the collection to become nullable. I know that the logic to determine nullability in the GraphQL schema is much more complex than to check if
isRequiredis true on the field, but I'm curious if this particular interaction is expected. I'm on Payload version 1.3.0. Thanks!
@mattddean The thinking here is that drafts can be saved as an incomplete document so no fields are required.
Got it, so it's expected, that makes sense. Only way I could think of solving this is to have an entirely different set of types for draft collections compared to regular collections, but not sure the effort and schema "pollution" would be worth it.
yep
@mattddean I agree
@jmikrut sorry to dredge up an old thread, but I'm curious if there's an opportunity to simplify here in the 2.0 release.
I'd propose that a draft document can't be saved until all of its required fields are filled out.
I think this maps well to a SQL table; you can create as many versions of a document (presumably each as its own row) as you want, but in order for a row to be created in the first place, all of the required columns have to be filled out.
This would also do the following:
1. If I make a collection's field required, it'll be required in the schema, regardless of whether or not drafts are turned on for the collection. It feels more consistent; this was pretty unexpected when I first encountered it.
2. Simplify internal code: no longer have to maintain a different required checker for draft vs non-draft collections.
I'm not sure what the original intent of the draft system is, and whether or not this conflicts with it, but IMO the real value of the draft system is the ability for editors to create a "draft" version of a published document (something that's fairly unique to Payload) and then preview it in a staging environment, not in the ability to create a partial document.
I think the right way to add this functionality would be to add an opt-in flag that
requires all fields for creating draftsthis would be pretty simple to do honestly
what do you think about that?
i see the value in what you're saying, but it could be a case-by-case preference - - some projects might want to allow partial drafts, others might not
That would work great for me, but just speaking from the outside, it feels like extra burden to maintain in the Payload core code. Partial drafts could still be created, they'd only have to have their required fields filled out
How are you thinking it'll map to SQL tables? Maybe my assumption is incorrect that required fields in Payload will be required in the db table?
Continue the discussion in Discord
Star
Discord
online
Get help straight from the Payload team with an Enterprise License.