DS-GN components own structure, behavior, styling, and accessibility wiring. Your application supplies product copy through props and slots. Use any CMS, API, local content files, or application code that fits your project; DS-GN components do not require a CMS or depend on Sanity.
Your application owns content
Content includes:
- visible copy such as headings, descriptions, badges, status messages, empty/error/success states, button text, and CTA labels;
- accessibility copy such as control names, disclosure labels, image alternatives, and live-region messages;
- destinations and identifiers such as links, anchors, paths, and external URLs;
- content collections such as feature lists, navigation trees, cards, and footer columns.
Supply content-bearing props explicitly rather than relying on sample values as production copy. Validate required content in your chosen content source or application layer, including accessible names and image alternatives.
Structural and behavioral defaults still belong in component code. Examples include a size, surface, visual variant, layout direction, animation duration, or whether an optional region is open. Those values control presentation and interaction rather than editorial content.
Content-to-component flow
Regardless of where content is stored:
- Define the content your application needs and validate required fields.
- Load or author values from your chosen source.
- Map those values onto component props, attributes, or slots in your application’s rendering layer.
The component renders the supplied content. For example, a button label can come from a CMS field, a translation file, an API response, or text authored directly in your application.
DS-GN’s marketing implementation
DS-GN’s own marketing site uses Sanity: schemas define editable fields and validation, seed data supplies initial content, and marketing templates map those values onto components. This is one implementation of the flow above; consumers can use another CMS or supply content without a CMS.