Strapi best practices

Creating content types - naming

Strapi does some magic with the name, so it's best to start with a clean name.

After the content type is created, change the display name to something readable also for the clients.

✅ Use plural where suitable, start with big letter, use spaces, use diacritics in slovak language.

This way, we can be sure that the content type has a well formatted name in code and also in admin UI.

✅ Make all fields you rely on required.
✅ Always try to make at least one field required (usually title field) so in frontend, we have at least something to display, and we don't end up with empty entities.
💡 It is always recommended to have title field as required field of type Short string. It is used also for displaying the entity in admin UI (Strapi cannot display long string as main fields, or it is not able to search in them)
💡 If you need the title accepting new lines, create an optional field of type Long text and use it in frontend along with title. Use correct css class, usually whitespace-pre-wrap:

<h2 className="whitespace-pre-wrap">{titleToDisplay ?? title}</h2>

✅ Setup slug as UID field connected to title - this way it will be autogenerated from title, and it will check uniqueness.
✅ We recommend to always setup slug as required field.
💡 Slugs should be set up for those content types that are meant to be accessed directly via URL. For example, Article content type should have slug. It is also recommended to have slug for content type that can be used in filters (e.g. Category - when we want to filter articles by category). We may want to use category slug in URL query parameter as well:

www.our-website.com/articles?category={category-slug}

✅ Write field names in English.
✅ Use camelCase with small starting letter.
✅ Respect singular/plural in names (e.g. plural for repeatable components).
✅ When naming boolean fields, use is or other verb prefix (e.g. isActive, hasBorder, inheritColor).
❌ Do not use underscores, dashes, spaces or special characters.

💡 Identify which fields should be required and which not.
💡 Identify which fields should NOT be localized, so admins do not have to fill them twice for both locals (e.g. cover image, date of event, etc.)
💡 For enums, it is usually good idea to choose default value and to make the field required.
💡 For repeatable components, you can set up min and max number of items, so we don't end up with empty components, or we can rely on max columns in grid etc.

Very long names: Sometimes, creating a new field may lead to an error: create index ... already exists. This happens mostly for relational fields and it is probably caused by a limitation of Postgres. The solution is to shorten the name of the field, component or component group, because all these names are joined to create the database index. Learn more in this thread (opens in a new tab).