Understanding the dot notation and import syntax in JavaScript schemas.
Great question! The dot notation in schema names like navigation.section and navigation.link is just a naming convention - it's not actual JavaScript object notation or namespacing in the technical sense.
In Sanity schemas, the name field is just a string identifier. You can use dots in that string, and Sanity treats the entire string (including the dot) as the type name. So navigation.section is literally a type called "navigation.section", not a property called section on a navigation object.
Why use dots in schema names?
It's purely organizational - a way to logically group related types together. When you have multiple types that belong to the same feature (like navigation), prefixing them helps you:
- Keep your schema organized
- Quickly identify related types in the Studio
- Avoid naming conflicts
How to import and use them:
You're right that you can't use dot notation in JavaScript imports! You need to import them normally:
// Import the files normally
import navigationSection from './objects/navigationSection'
import navigationLink from './objects/navigationLink'
// Then use them in your schema array
types: schemaTypes.concat([
navigationSection, // This has name: 'navigation.section' inside it
navigationLink, // This has name: 'navigation.link' inside it
])The dot is inside the string in the schema definition's name field, not part of the JavaScript variable name. When you reference these types elsewhere in your schema (like in the of array), you use the full string including the dot:
{
type: 'array',
of: [{ type: 'navigation.link' }] // Reference using the full name string
}So to summarize: dots in schema names are just a naming pattern for organization, not JavaScript syntax. Import your schema files with regular identifiers, but reference them by their full string names (with dots) within schema definitions.
Sanity – Build the way you think, not the way your CMS thinks
Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.