Adding Manifest definitions in code-first JSS apps
When scaffolding components, if you have not modified the script to remove the functionality, JSS creates Manifest definitions for your new components automatically. However, if you simply create component files, you can add them to the Manifest items using Manifest API instance methods. You can also use Manifest API instance methods to register new route types or other types of items.
You use these methods in manifest definition files located in the sitecore/definitions/ directory. The file name must follow the convention *.sitecore.[js|ts], where the asterisk stands for a component name, such as SearchBox.sitecore.js , or an item type, such as placeholders.sitecore.js.
Manifest API instance methods
The Manifest API provides the following instance methods for registering :
-
addComponent(...components: component[])- registers a JSS app component definition. -
addContent(...contents: content[]). -
addRoute(...routes: route[])- adds an app route data definition. -
addRouteType(...routeTypes: template[])- adds a Sitecore template type for a route. -
addTemplate(...templates: template[]). -
addPlaceholder(...templates: template[])- adds a placeholder definition to the manifest.
Manifest objects
When using Manifest API instance methods to add manifest definitions, your definitions must match the following schemas:
Using an editor that understands JS typings (such as VS Code) accesses type information within the editor including helpful annotations.
component
The displayFieldEditorButton and fieldEditorFields properties allow you to control the behavior of the Field Editor button that is automatically added to the component in the Sitecore Experience Editor. This button allows editing all the component data in a pop-up form interface. By default, all components display the button, and all component fields are editable. You do not have to supply these properties if this is the desired behavior.
content
Content data uses the same schema as route data, except that the placeholders property is generally not used as it would have no effect.
field
For the type property, we recommend you use one of the available CommonFieldTypes values.
CommonFieldTypes
For custom Sitecore field types or other types not in the CommonFieldTypes enumeration, the string of their field type name in Sitecore (that is, Single-Line Text) can be passed. Editors that support type annotations, like VS Code, provide auto-completion on this enum.
param
placeholder
placeholders
route
template
fields
params
imageFieldValue
The image field value is used when a field is an image type. It has additional properties compared to a normal field.
linkFieldValue
The link field value is used when a field is a link type. It has additional properties compared to a normal field.
multilistFieldValue
You can define Sitecore multi-list fields by specifying the item definitions that are selected in the multi-list (as an array), or by using ID references to pull in items defined in a shared content area (or explicit GUIDs to refer to non-app items in Sitecore)
Handling date field values
Date fields' values in the manifest are formatted using ISO 8601 formatted strings, for example, 2012-04-23T18:25:43.511Z.
This is a JavaScript date format and is different from how Sitecore stores date field values internally. Sitecore-formatted dates do not work.
Examples of manifest definitions
When you create JSS applications, the apps already have some manifest definitions. The most common manifest definitions are for registering placeholders and components with Sitecore during app import, but you can also use manifest definitions for other use cases, such as adding fields to routes.
Placeholders
Defining placeholders explicitly in the manifest is optional. Any placeholder name referred to by a route is automatically known by the manifest. However, explicitly registering a placeholder lets you set a placeholder display name for it so that content editors can see something friendlier than appname-content-leftside-upsidedown-2.
An explicit placeholder definition is a line in the /sitecore/definitions/placeholders.sitecore.js file. The .sitecore in the name is mandatory.
For example:
Components
You must define each front-end component added to a route so that JSS can register the component within Sitecore and provide the appropriate infrastructure to give it the necessary content.
Component definitions are conventionally stored in /sitecore/definitions/components/<ComponentName>.sitecore.{js|ts}. For example:
The .sitecore in the name is mandatory.
When you create components with the CLI command jss scaffold <ComponentName>, the scaffolding script, if available in your sample application, generates the component and the manifest definition for you.