As Strapi is a headless Content Management System (CMS), creating a content structure for the content is one of the most important aspects of using the software. Models define a representation of the content structure.

There are 2 different types of models in Strapi:

• content-types, which can be collection types or single types, depending on how many entries they manage,
• and components that are content structures re-usable in multiple content-types.

If you are just starting out, it is convenient to generate some models with theContent-type Builder directly in the admin panel. The user interface takes over a lot of validation tasks and showcases all the options available to create the content's content structure. The generated model mappings can then be reviewed at the code level using this documentation.

Model creation​

Content-types and components models are created and stored differently.

Content-types​

Content-types in Strapi can be created:

• with theContent-type Builder in the admin panel,
• or withStrapi's interactive CLIstrapi generate command.

The content-types use the following files:

• schema.json for the model'sschema definition. (generated automatically, when creating content-type with either method)
• lifecycles.js forlifecycle hooks. This file must be created manually.

These models files are stored in./src/api/[api-name]/content-types/[content-type-name]/, and any JavaScript or JSON file found in these folders will be loaded as a content-type's model (seeproject structure).

Components​

Component models can't be created with CLI tools. Use theContent-type Builder or create them manually.

Components models are stored in the./src/components folder. Every component has to be inside a subfolder, named after the category the component belongs to (seeproject structure).

Model schema​

Theschema.json file of a model consists of:

• settings, such as the kind of content-type the model represents or the table name in which the data should be stored,
• information, mostly used to display the model in the admin panel and access it through the REST and GraphQL APIs,
• attributes, which describe the content structure of the model,
• andoptions used to defined specific behaviors on the model.

Model settings​

General settings for the model can be configured with the following parameters:

// ./src/api/[api-name]/content-types/restaurant/schema.json

{
"kind":"collectionType",
"collectionName":"Restaurants_v1",
}

Model information​

Theinfo key in the model's schema describes information used to display the model in the admin panel and access it through the Content API. It includes the following parameters:

"info":{
"displayName":"Restaurant",
"singularName":"restaurant",
"pluralName":"restaurants",
"description":""
},

Model attributes​

The content structure of a model consists of a list of attributes. Each attribute has atype parameter, which describes its nature and defines the attribute as a simple piece of data or a more complex structure used by Strapi.

Many types of attributes are available:

• scalar types (e.g. strings, dates, numbers, booleans, etc.),
• Strapi-specific types, such as:
  • media for files uploaded through theMedia library
  • relation to describe arelation between content-types
  • customField to describecustom fields and their specific keys
  • component to define acomponent (i.e. a content structure usable in multiple content-types)
  • dynamiczone to define adynamic zone (i.e. a flexible space based on a list of components)
  • and thelocale andlocalizations types, only used by theInternationalization (i18n) plugin

Thetype parameter of an attribute should be one of the following values:

Validations​

Basic validations can be applied to attributes using the following parameters:

{
// ...
"attributes":{
"title":{
"type":"string",
"minLength":3,
"maxLength":99,
"unique":true
},
"description":{
"default":"My description",
"type":"text",
"required":true
},
"slug":{
"type":"uid",
"targetField":"title"
}
// ...
}
}

Database validations and settings​

Database validations and settings are custom options passed directly onto thetableBuilder Knex.js function during schema migrations. Database validations allow for an advanced degree of control for setting custom column settings. The following options are set in acolumn: {} object per attribute:

{
// ...
"attributes":{
"title":{
"type":"string",
"minLength":3,
"maxLength":99,
"unique":true,
"column":{
"unique":true// enforce database unique also
}
},
"description":{
"default":"My description",
"type":"text",
"required":true,
"column":{
"defaultTo":"My description",// set database level default
"notNullable":true// enforce required at database level, even for drafts
}
},
"rating":{
"type":"decimal",
"default":0,
"column":{
"defaultTo":0,
"type":"decimal",// using the native decimal type but allowing for custom precision
"args":[
6,1// using custom precision and scale
]
}
}
// ...
}
}

uid type​

Theuid type is used to automatically prefill the field value in the admin panel with a unique identifier (UID) (e.g. slugs for articles) based on 2 optional parameters:

• targetField (string): If used, the value of the field defined as a target is used to auto-generate the UID.
• options (string): If used, the UID is generated based on a set of options passed tothe underlying `uid` generator. The resultinguid must match the following regular expression pattern:/^[A-Za-z0-9-_.~]*$.

Relations​

Relations link content-types together. Relations are explicitly defined in theattributes of a model withtype: 'relation' and accept the following additional parameters:

// …
  attributes:{
    category:{
      type: 'relation',
      relation: 'oneToOne',
      target: 'category',
},
},
// …

// …
  attributes:{
    category:{
      type: 'relation',
      relation: 'oneToOne',
      target: 'category',
      inversedBy: 'article',
},
},
// …

// …
  attributes:{
    article:{
      type: 'relation',
      relation: 'oneToOne',
      target: 'article',
      mappedBy: 'category',
},
},
// …

// …
  attributes:{
    owner:{
      type: 'relation',
      relation: 'manyToOne',
      target: 'api::person.person',
      inversedBy: 'plants',
},
},
// …

// …
  attributes:{
    plants:{
      type: 'relation',
      relation: 'oneToMany',
      target: 'api::plant.plant',
      mappedBy: 'owner',
},
},
// …

// …
  attributes:{
    author:{
      type: 'relation',
      relation: 'manyToOne',
      target: 'author',
},
},
// …

// …
  attributes:{
    author:{
      type: 'relation',
      relation: 'manyToOne',
      target: 'category',
      inversedBy: 'article',
},
},
// …

// …
  attributes:{
    books:{
      type: 'relation',
      relation: 'oneToMany',
      target: 'article',
      mappedBy: 'category',
},
},
// …

// …
  attributes:{
    categories:{
      type: 'relation',
      relation: 'manyToMany',
      target: 'category',
},
},
// …

// …
  attributes:{
    tags:{
      type: 'relation',
      relation: 'manyToMany',
      target: 'tag',
      inversedBy: 'articles',
},
},
// …

// …
  attributes:{
    articles:{
      type: 'relation',
      relation: 'manyToMany',
      target: 'article',
      mappedBy: 'tag',
},
},
// …

Custom fields​

Custom fields extend Strapi’s capabilities by adding new types of fields to content-types. Custom fields are explicitly defined in theattributes of a model withtype: customField.

Custom fields' attributes also show the following specificities:

• acustomField attribute whose value acts as a unique identifier to indicate which registered custom field should be used. Its value follows:
  • either theplugin::plugin-name.field-name format if a plugin created the custom field
  • or theglobal::field-name format for a custom field specific to the current Strapi application
• and additional parameters depending on what has been defined when registering the custom field (seecustom fields documentation).

{
// …
"attributes":{
"attributeName":{// attributeName would be replaced by the actual attribute name
"type":"customField",
"customField":"plugin::color-picker.color",
"options":{
"format":"hex"
}
}
}
// …
}

Components​

Component fields create a relation between a content-type and a component structure. Components are explicitly defined in theattributes of a model withtype: 'component' and accept the following additional parameters:

{
"attributes":{
"openinghours":{
"type":"component",
"repeatable":true,
"component":"restaurant.openinghours"
}
}
}

Dynamic zones​

Dynamic zones create a flexible space in which to compose content, based on a mixed list ofcomponents.

Dynamic zones are explicitly defined in theattributes of a model withtype: 'dynamiczone'. They also accept acomponents array, where each component should be named following this format:<category>.<componentName>.

{
"attributes":{
"body":{
"type":"dynamiczone",
"components":["article.slider","article.content"]
}
}
}

Model options​

Theoptions key is used to define specific behaviors and accepts the following parameter:

{
"options":{
"privateAttributes":["id","createdAt"],
"draftAndPublish":true
}
}

Lifecycle hooks​

Lifecycle hooks are functions that get triggered when Strapi queries are called. They are triggered automatically when managing content through the administration panel or when developing custom code usingqueries·

Lifecycle hooks can be customized declaratively or programmatically.

Available lifecycle events​

The following lifecycle events are available:

• beforeCreate
• beforeCreateMany
• afterCreate
• afterCreateMany
• beforeUpdate
• beforeUpdateMany
• afterUpdate
• afterUpdateMany
• beforeDelete
• beforeDeleteMany
• afterDelete
• afterDeleteMany
• beforeCount
• afterCount
• beforeFindOne
• afterFindOne
• beforeFindMany
• afterFindMany

Hookevent object​

Lifecycle hooks are functions that take anevent parameter, an object with the following keys:

Declarative and programmatic usage​

To configure a content-type lifecycle hook, create alifecycles.js file in the./src/api/[api-name]/content-types/[content-type-name]/ folder.

Each event listener is called sequentially. They can be synchronous or asynchronous.

module.exports={
beforeCreate(event){
const{ data, where, select, populate}= event.params;

// let's do a 20% discount everytime
    event.params.data.price= event.params.data.price*0.8;
},

afterCreate(event){
const{ result, params}= event;

// do something to the result;
},
};

exportdefault{
beforeCreate(event){
const{ data, where, select, populate}= event.params;

// let's do a 20% discount everytime
    event.params.data.price= event.params.data.price*0.8;
},

afterCreate(event){
const{ result, params}= event;

// do something to the result;
},
};

Using the database layer API, it's also possible to register a subscriber and listen to events programmatically:

module.exports={
asyncbootstrap({ strapi}){
// registering a subscriber
    strapi.db.lifecycles.subscribe({
models:[],// optional;

beforeCreate(event){
const{ data, where, select, populate}= event.params;

        event.state='doStuffAfterWards';
},

afterCreate(event){
if(event.state==='doStuffAfterWards'){
}

const{ result, params}= event;

// do something to the result
},
});

// generic subscribe for generic handling
    strapi.db.lifecycles.subscribe((event)=>{
if(event.action==='beforeCreate'){
// do something
}
});
}
}