How to Build Your Own Framework Implementation for Sitecore JSS?

Anton Tishchenko
Anton Tishchenko
Cover Image for How to Build Your Own Framework Implementation for Sitecore JSS?

Official Sitecore JSS repository has an implementation for the three most popular frontend frameworks: Vue, Angular, React(and Next.Js implementation, which is based on React). It will cover 95% of your needs. But there are much bigger variety of frameworks: Astro, Ember, Preact, Svelte, SolidJS, AlpineJS, Lit, and different WebAssembly implementations. Does it mean that you can’t use them? Let’s figure it out!

First of all, Sitecore is a headless CMS. You can use its API without any restrictions to the frameworks like with other headless content management systems. So, why do we need Sitecore JavaScript Services at all? Sitecore JSS has two main functions: it simplifies work with Sitecore API and adds rich editing for your pages. Sitecore JSS API client implementations are framework-agnostic, you can use it with any framework with no limitations. Or if don’t want to use it, you still can access API directly. The part responsible for WYSIWYG could not be universal for all frameworks as they are quite different. Now, we need to consider the smaller parts that we need.

  1. Layout Service client. You need code that will take from Sitecore layout details for your pages. This part is framework agnostics, you will be able to reuse it from Sitecore JavaScript Rendering SDK. It has an implementation for REST and GraphQL API.
  2. Dictionary Service client. If your site is multilingual, you need to get translations from Sitecore. It is also part of Sitecore JavaScript Rendering SDK and has an implementation for REST and GraphQL API.
  3. Internationalization (i18n). Translations that you will get from Sitecore, you will need to properly use by yourself. And usage could be different from one framework to another.
  4. Components factory and components factory generation. Sitecore Layout Service returns you the composition of components defined on Sitecore side. In order to map them into components in your implementation you need code that goes through your files and creates a factory.
  5. Placeholder. Sitecore JSS takes responsibility for page composition. And the key element to achieve it is a placeholder. It can take presentation definition and render it using a components factory.
  6. Fields implementation. You will need Date, EditFrame, File, Image, Link, Text, and RichText.
  7. Configuration generation. It is an optional part. You always may use environment variables or constants directly. But if you want your code to be nice and maintainable, you will need to implement config generation that may take values from: package.json, scjssconfig.json, and environment variables.
  8. Editing API. When the application works in normal mode, you get the URL from the request and send requests to Sitecore API to get the required info: layout details and dictionary. When your application works in edit mode, Sitecore expects you to have an endpoint that accepts POST requests with layout details and a dictionary in the request body. If simplified, you need to implement the ability to take data for pages from different sources depending on working mode.
  9. Sitemap service. You will need it for two things: sitemap generation and getting all paths if you want to generate a static site.
  10. Tracking functionality. If you use Sitecore XP and want to use goals/events/outcomes/page views/etc. It is a framework agnostics part. You can use it from the main Sitecore JavaScript Redndering SDK npm package.
  11. Sitecore Forms implementation. If you want to use forms fully managed by marketers without any attention from developers then you will need an implementation for form components, implementation for each field, and fields factory. Fields factory allows you to map each field that you get from Sitecore API to a component in your code. As forms differ a lot from project to project, you still will rewrite(even if it is present in Sitecore JSS) fields factory and fields for your project.

Sounds a lot and complex? Yes, when you do it the first time. But when you do it once, it is not scary to repeat it for other frameworks. The minimum list will be simpler:

  1. Components factory
  2. Placeholder
  3. Fields
  4. Editing API