How do Strapi component fields relate to Croct component schemas?
Strict TypeScript project, and I care a lot about having one source of truth for types. Our Strapi components are typed end to end today.
If I map a Strapi component to a Croct slot, do I effectively define the schema twice, once in Strapi and once in Croct? And how do the types stay in sync in the frontend, is there codegen or am I hand-writing interfaces that can silently drift? Schema drift between two systems is the thing I want to rule out before adopting this.
1 answer
You do define a component schema on the Croct side, via the UI or JSON schema, and it should mirror the Strapi fields you want to vary. Each slot binds to exactly one component, so the slot's content shape is fully determined by that schema. In practice the Croct schema is usually a subset of the Strapi component, just the fields marketing actually edits.
Sync in the frontend is codegen, not hand-written interfaces. The CLI generates a slots.d.ts file, and SlotContent<'home-hero@1'> gives you the typed content for a slot version. Commit slots.d.ts to the repo so builds do not fetch from the API to resolve types.
Drift is handled by auto-versioning: a schema change creates a new version while old versions keep serving, so code pinned to home-hero@1 keeps compiling and keeps receiving content shaped like version 1 until you deliberately upgrade. That was the property that sold it to me.