A collection's schema is rendered in full for every entry in it, so an entry
that uses only some of the fields opens on a column of empty boxes that do
nothing. For a CMS aimed at non-technical editors this is the first thing they
see and it reads as either broken or as work they are supposed to do.
Concretely, on a site with a pages collection: the FAQ and Articles index
entries own only a kicker, headline and standfirst, but the form also offers
Nav Label, Nav Order, Intro Image and Intro Image Alt — none of which affect
those pages, because they are rendered by their own routes.
Current workaround, and why it does not generalise
The homepage had the same problem and was fixed by moving it into its own
single-entry collection, which was the right call there for other reasons too
(a hero instead of a page header, never in the nav, and it made click-to-edit
possible on the hero). But a collection per irregular entry is not a general
answer — it multiplies collections for what is a presentation concern, and the
entries above genuinely belong in pages.
Sketch
Something schema-level and declarative, e.g. a field-level predicate evaluated
against the entry's own data:
navLabel: text.optional().describe('...'), // shown always
introImage: text.optional().when((entry) => entry.slug !== 'faq'),or the inverse — a per-entry list of fields to omit. Either way the schema stays
the single source of truth, which is the project's existing stance.
Related but distinct from #41 (a const is fixed for every entry, so it is
now hidden unconditionally). This is about a field that is real for some entries
and meaningless for others.
A collection's schema is rendered in full for every entry in it, so an entry
that uses only some of the fields opens on a column of empty boxes that do
nothing. For a CMS aimed at non-technical editors this is the first thing they
see and it reads as either broken or as work they are supposed to do.
Concretely, on a site with a
pagescollection: the FAQ and Articles indexentries own only a kicker, headline and standfirst, but the form also offers
Nav Label, Nav Order, Intro Image and Intro Image Alt — none of which affect
those pages, because they are rendered by their own routes.
Current workaround, and why it does not generalise
The homepage had the same problem and was fixed by moving it into its own
single-entry collection, which was the right call there for other reasons too
(a hero instead of a page header, never in the nav, and it made click-to-edit
possible on the hero). But a collection per irregular entry is not a general
answer — it multiplies collections for what is a presentation concern, and the
entries above genuinely belong in
pages.Sketch
Something schema-level and declarative, e.g. a field-level predicate evaluated
against the entry's own data:
or the inverse — a per-entry list of fields to omit. Either way the schema stays
the single source of truth, which is the project's existing stance.
Related but distinct from #41 (a
constis fixed for every entry, so it isnow hidden unconditionally). This is about a field that is real for some entries
and meaningless for others.