JSS Architecture brief

The JSS is part of the headless development suite of Sitecore products, which allows modern development workflows for producing applications and systems which follow the Jamstack architecture.

Applications developed with JSS consume the content, and personalization, from Sitecore, delivered through Sitecore Headless Services or Sitecore Experience Edge for XM. The JSS also consumes data from Sitecore and other third-party APIs which provide RESTful or GraphQL API endpoints.

Out-of-process Node.js rendering engine, provided by Headless Services, allows developing the server-side rendered applications. Apart from that, we can also use the Sitecore-independent rendering host for a true headless architecture for developing and deploying the JSS applications.

JSS components

JSS comprises the following components:

  • Core SDK functionality allows to retrieving and consumes Sitecore data from various Sitecore services and APIs to facilitate working with Sitecore data and layout in JavaScript
  • SDKs allow building JavaScript applications with some of the most popular JavaScript frameworks, like Next.js, React, and Vue. They help to render Sitecore dynamic placeholders, providing components and helpers for rendering Sitecore fields, while the layout and field values remain editable by content authors.
  • Sample applications for every supported JavaScript framework
  • Developer tools and utilities

Application modes

The Sitecore JavaScript Rendering SDK (JSS) allows developing the applications with several modes depending on the stage you are in the development process and your selected development workflow.

Following are the development modes that we can select during development:

  • Disconnected mode – This mode does not require a Sitecore instance. You host the application in the local environment, and you use local content data. This mode is suitable for the code-first development workflow. You can select this mode when you have no Sitecore expert who can build the templates and content and you do not have a working Sitecore environment. However, the front-end developers need some level of knowledge about how to organize the content in the disconnected mode so that when the application is deployed and items are imported they meet the Sitecore requirements allowing the application to work.
  • Connected mode – This mode requires a running Sitecore instance. You host the application in the local environment and use content data from the Sitecore instance.
  • Integrated mode – This mode requires a running Sitecore instance, which hosts the application, provides content data, and renders your application server-side.

In production, you can run a JSS application using one of the following modes:

  • In the Headless server-side rendering mode, the Node.js server performs the server-side rendering and data retrieved from Sitecore CD. For high-traffic production sites, Sitecore recommends this mode because it provides additional scaling options, better scalability, and lower hosting costs for heavy traffic.
  • In the Integrated mode, the server-side rendering is performed on the Sitecore CD and CM server for integration with Experience Editor.

Sitecore editors and content management

While developing applications using Sitecore JavaScript Rendering SDK (JSS), it can be integrated with Sitecore editors such as Experience Editor.

Applications created with JSS for Next.js support Sitecore Experience Editor for content editing. However, we need some configuration changes to make this work.

The applications created with JSS for React, Angular, and Vue.js also support content editing through Sitecore Experience Editor, which must run the application in integrated mode.

Page composition in JSS apps using Sitecore data

Every page in Sitecore uses a layout. The layout engine works by defining named placeholders. Placeholders host multiple components. On a single page, we can have multiple placeholders to compose a defined layout for the page. JSS leverages the dynamic placeholders feature of Sitecore and extends the author-driven, component-based layout model of Sitecore to front-end applications.

In the JSS application, a layout is a top-level component used by all the pages. Similar to Sitecore layouts we use in MVC implementation, the Layout component in the JSS apps defines at least one placeholder component, also called the root component, which is responsible for rendering the component hierarchy on the page.

In traditional JavaScript applications, the components are known while building the page or route. In contrast, the component hierarchy is unknown in the JSS application because it is defined in the Sitecore layout data dynamically.

The dynamic layout data enables JSS applications to support layouts defined by Content Authors and support data-driven personalization and multivariate testing. However, this also requires a matching structure in the JSS application for the layout composed by Content Authors in Sitecore.

The JSS applications do not use the layout data from Sitecore directly. JSS applications have custom data fetching and route handling functionality to consume the JSON-formatted data from Sitecore endpoints.

Placeholders in JSS apps

JSS includes a unique component named placeholder. This component is responsible for creating a named placeholder key when added to the root level component or any other component.

With Sitecore 10.3 and SXA headless website definitions, one more special component named PartialDesignDynamicPlaceholder is introduced, which is required when you use partial design-based page composition.

Placeholders enable the Sitecore features such as personalization, testing, and editors’ ability to alter the page layout are available when working in connected mode.

For more information, please go through the Sitecore documentation here.

Components in JSS apps

The JSS component is just a regular front-end component in Next.js, React, or Vue. Different than JavaScript components, JSS components have properties to hold the content data. When working in Sitecore, connected for the REST or GraphQL endpoints are responsible for providing the data to the JSS components. In contrast, the mocked content using local YAML or JSON files is responsible for providing content data for JSS components in the disconnected model.

JSS components must not be initialized or rendered directly. JSS infrastructure handles the initialization while rendering the JSS application page or route, and the components are about dynamically to that page or route.

The essential requirement for a working JSS application is every rendering on the Sitecore page that the JSS application rendered must have a corresponding component in the JSS application. The component added to the route must have a matching name available in route data, which enables the JSS to register the component with Sitecore and provide the appropriate infrastructure to render the content.

Each component in the JSS app consumed the fields defined in the data template of the Sitecore rendering or the route context data.

Please refer to the following topics for more information.

The Component Factory

Create a new component in a Sitecore-first JSS app running in connected mode

Scaffolding components in JSS apps