What do devs need to know before they get started on a Sitecore XM Cloud project?
✅ DO focus on “just the essentials” during dev onboarding.
Learn just a small subset of Sitecore technologies; don’t try to learn everything.
Front-end devs who are new to Sitecore are saying that the quantity of Sitecore-specific terminology and product names (XM Cloud, Edge, JSS, SXA) can feel overwhelming. This is normal.
Recommended learning path for devs new to XM Cloud: XM Cloud Introduction
✅ DO master key Content Authoring concepts before starting work in a Sitecore XM Cloud project
Many devs coming to the Sitecore world are used to building components for webpages. But Sitecore is a CMS for marketers, so in Sitecore you are not building for webpages directly; you are building for the authoring interface, and this requires extra considerations.
Content authoring concepts for developers new to Sitecore - It is critical to understand these key concepts before designing or building front-end components for a Sitecore XM Cloud backend.
✅ DO acquire access to your XM Cloud instance and try out the authoring workflow yourself before building components.
Don’t ignore the authoring interface and don’t hardcode the layout of the components. Many front-end devs are used to working with static websites, meaning that once the layout requirements are defined in the design, these requirements remain static. (For example, the number of columns). Even front-end devs who have experience working with other headless CMSs may be expecting that only the text or images change - the fact that Content Authors can edit the layout of the page and change how components are ordered or nested is a very significant and differentiating concept. Taking the time to learn the full extent of editing power that Content Authors have over pages (by trying it themselves) is the single best thing front-end devs can do to set themselves up for working on a Sitecore project.
✅ DO regularly test components and functionality in the authoring interface during development.
✅ DO keep Content Authors in control of page layout by avoiding hardcoding layout in code.
Teams who are not used to building for a CMS and who did not take the time to master these concepts struggled when it was time to hand the system over to Content Authors because they ignored the authoring interface during development and pushed off the task of testing their components in the authoring interface to the end of the project. Remember that it doesn’t matter how great your components are if Content Authors can’t add them to pages - all components must work in the authoring interface, so they must be tested in the authoring interface. If front-end devs are following our recommended workflow of building against an XM Cloud endpoint instead of running local Sitecore containers, then they must plan for a little extra testing time since they will not be able to test all authoring interfaces (e.g. Pages) locally.
✅ DO use functions provided by JSS to fetch data from Sitecore’s GraphQL API rather than using the API directly.
JSS helpers abstract away the specifics of the API. This means that you won’t have to change your components as much if you change Sitecore or JSS versions. When your front-end and back-end communicate through an interface, they are abstracted from each other’s changes.
Additionally, using JSS helpers ensures that all content displayed in components is editable by Content Authors in the WYSIWYG authoring interface.
❌ DON’T define the nesting structure of components through code. Instead, use the Placeholder component provided by JSS.
❌ DON’T hardcode any text or images into components. Instead, use the Field components provided by JSS.
✅ DO use features provided by Headless SXA to deliver best authoring experiences but also save time on common reoccuring features.
SXA used to be an add-on to Sitecore and is now part of XM Cloud. It provides multisite and multitenancy features, improved page layouting concepts using page designs, partial designs and page branches and the capability to build components easily and in a flexible way utilizing rendering variants (UI variations of components) and rendering parameters (configurable UI variations). Additionally it provides a list of features that can be easily utilized such as sitemaps, robots.txt. Following the XM Cloud starter template headless SXA out of the box components provide great implementation examples. SXA reduces the amount of code a lot makes configuration much more accessible.
✅ Define Page- and Partial Designs using Headless SXA Components over creating static coded layouts.
✅ DO use Headless SXA together with JSS to utilize the benefits of both worlds.
Recommended learning path for devs new to SXA: SXA Best Practices Guide
✅ DO chose GitHub for your source control needs to take advantage of the built-in integrations with XM Cloud.
Teams who use other source control tools say it’s not worth the effort.
Content search is not available on Edge. Very complex search methodologies need to be reconsidered in a headless world / XM Cloud world.