Sitecore-first development workflow

Abstract

Overview of JSS Sitecore-first development

Most Sitecore-first projects begin with at least one code-first app deployment to create the structures for the app in Sitecore, such as app root, rendering root, template root, and so on. After the initial deployment, the app can migrate to Sitecore-first development.

When developing a JSS app using the Sitecore-first workflow, the JSS app consumes data from Sitecore but has no responsibility for defining the structure of that data or what components are registered with Sitecore.

In this workflow, all developers require their own development instance of Sitecore, and the JSS app connects to it to acquire its content and layout data.

We recommend you choose the Sitecore-first workflow when:

  • The project is led by experienced Sitecore developers who prefer to work in Sitecore.

  • The project has complex content or back-end architectural demands.

  • Sitecore developers are also implementing the JavaScript application.

  • JSS apps are to be deployed and versioned using the same deployment process.

Working Sitecore-first in a JSS app is much like building any regular Sitecore site, with a few differences.

Creating renderings

When creating rendering items, use the Json Rendering template instead of View renderings, XSLT, and so on. This rendering template is automatically rendered to JSON when emitted by the Layout Service. The Json Rendering template includes additional fields that allow you to set Rendering Contents Resolvers, set up Integrated GraphQL queries, and configure placeholders.

Also unique to the Json Rendering template, the Component Name field is a string that needs to match with the name of a component registered in the JSS app. For example, if you created a rendering with Foo as the component name, the JSS app would need a Foo.js component that was registered with its component mapping as "Foo" > Foo.js. If a component name cannot be mapped, JSS apps show a placeholder with the name of the missing component received from Sitecore. This can be used to scaffold out a component hierarchy prior to front-end developers actually implementing the view of the components.

When adding a placeholder to a rendering, the placeholder must also be added to the Layout Service Placeholders field on the rendering item. Otherwise, Layout Service does not attempt to render the child placeholder, and you do not receive any renderings added to it in the Layout Service data.

Editing and creating routes

Creating routes Sitecore-first is just like adding pages to a traditional Sitecore site.

Scripted component scaffolding

When working in a Sitecore-first application, the task of adding a new component involves a repetitive set of steps (creating a rendering item, datasource template item, datasource location folders, and linking them together. To keep this simple, there are JSS CLI commands to help scaffold the Sitecore infrastructure of JSS components:

  • jss deploy component deploys a new component. It is similar to the function manifest.addComponent() used in code-first development, but it deploys the new component directly to the Sitecore database.

  • jss deploy template deploys a new Sitecore template for use as a content template, settings item, and so on.

Incremental deployments

In the Sitecore-first development process, new code artifacts are deployed with the JSS CLI command jss deploy files only. Package-based deployment with jss deploy app is only meant for code-first development scenarios after the initial deployment.