# Contenful Schema Design

## Display title
Always keep separate fields for `title` and `displayTitle`. That way the content editor can share similar `displayTitles` between different pieces of content, but they are able to have different `titles`, which can be useful for searching and navigating through the Contenful interface.

This helps to drastically improve the editor experience.

## Required schema content
For content that will be queried in graphql, always add a boolean field for `shouldRender` defaulted to true.

That way, we as developers can still include a published `schema post` in our build that has all the required fields, even before the client has published any content of this content type.

We ensure this `schema post` remains published, with the`shouldRender` boolean field set to false.

In our graphql queries, we can easily filter out this `schema post` so that it never actually renders to the screen, while our builds will always succeed without gatsby / graphql issues.

## Names vs IDs
Unfortunately by default, `gatsby-source-contentful` uses the `name` of each content type in the content model to build out its graphql schema.

This could have negative effects if we later decide to change the name of a content type, long after starting the development the new content type.

We can guard against this by setting `useNameForId` to false in the settings for `gatsby-source-contentful` at the start of the project.

That way we can easily change the names of the content types in our content model without any need for refactoring the graphql queries in our gatsby site.

As we have learned, the names of features (and thus their related content types) can really evolve from the inital content discovery phase, all the way through to design, development, and delivery phases of a project.