# How do Strapi component fields relate to Croct component schemas?

Asked by Felix Braun on 2025-10-28. Tags: strapi, component-schema, typescript.

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

### Answer from piotr_s (2025-10-28)

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.