Understanding the dot notation and import syntax in JavaScript schemas.

9 replies
Last updated: Sep 16, 2022
Hi all. I have a bit of a newbie question, mostly related to JS. I decided to use this snippet https://www.sanity.io/schemas/nested-navigation-structure-757f39ee
I’m just wondering what is the dot notation on the schema name, like in
name: navigation.section
and how do I import those? is it namespacing?
I ask because I can’t find anything about it on the documentation and VSCode is yelling at me when I try to import for example


import navigation.link from './objects/navigationLink';

and


  types: schemaTypes.concat([
    ...
    navigation.link,
    ...
  ])
I know I can just import
link
or
section
, but what is the purpose of it?
AI Update

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.

The dot notation is used for accessing an object keys. If you have an object
var obj = { foo: "bar" }
, you can access the value
bar
as
obj.foo
.
So you can’t import a key from an object. You need to import the whole thing, and then you can read its keys (if it's an object).
import navigation from './objects/navigation'

navigation.link
Ah wait, I’m talking about something else. I just checked the link you shared. 😄
I mean, everything I said is true, but that's not what's relevant here.
So in that article, the names like
navigation.link
are just made this way for clarity. It‘s a convention, if you will. It’s just a name as a string. It could contain anything, and could just as well be
navigationLink
.
So it’s
name: "navigation.link”
, not
name: navigation.link
. That’s an important difference, because the first one is a literal string, while the second one is attempting to read an object
navigation
and its key
link
. Which is not what is happening here.
Regarding the imports, you can name that variable whatever you want. It doens’t have to match the Sanity name. So:
import navLink from './objects/navigationLink'
Indeed, variables can‘t contain dots in JS (because of the whole object thing I explained above), that's why your code is throwing an error.
The quotes around the name and the naming of the import variables whatever I wanted were the key here. Thank you so much! That dot naming convention threw me totally off!
Thank you!
user M
for future reference 👆

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.

Was this answer helpful?