Content modeling question, which Strapi components should become Croct slots?
Thinking out loud here. Our Strapi has 40+ components. Roughly:
page |- dynamic zone |- hero (marketing changes weekly) |- feature-grid (changes quarterly) |- testimonial (rarely) |- footer-cta (marketing wants to test) |- 36 more...Does every dynamic zone entry need a slot, or only the sections marketing actually wants to vary? Mapping all 40 feels wrong but I cannot articulate why. Also unsure what happens later if we mapped too few and marketing wants more, or if a component schema evolves after mapping
Looking for heuristics from people who did this at scale.
2 answers
A slot is a context-specific placeholder bound to one component schema. It is not a mirror of your content model, it is a declaration of "this spot may vary", which is the articulation you were missing. So the heuristic is simple: map only the sections you plan to personalize or test.
From your list, that is the hero and the footer-cta today. The feature-grid and testimonial keep rendering straight from Strapi like they always have, losing nothing.
On the "mapped too few" worry: adding a slot later is the same mapping step you did for the first two. There is no penalty for starting small, which is why starting small is the standard advice.
On schema evolution: schema changes create a new version and old versions keep serving, so a mapped component evolving does not break anything already published. You migrate the slot to the new version when you are ready. Starting small does not paint you into a corner in either direction.
One modeling detail worth knowing before you map: components on the Croct side can be regular (fixed attributes) or union types. If one placeholder in your dynamic zone must accept several shapes (say a spot that is sometimes a hero and sometimes a promo banner), model it as a union rather than forcing one fat component with optional everything. We learned that the hard way with a 15-optional-field monster that nobody could author content for.