JSS (React) Dynamic Layouts - Part 1.5: Patching a pipeline

JSS adheres to the classic Sitecore architecture pattern of pipelines, but it looks slightly different than normal. Let's see what we're dealing with.

This is a continuation of my previous post about dynamic layout support for JSS. I ended that post by saying that I would look into how to extend the manifest generation next, and my first step towards that is to do a bit of investigation as to how these kinds of processes are implemented in JSS, and what means we have of modifying them. However, this post goes through the general concept of patching a pipeline in JSS. If you just want to get to the actual implementation in order to get dynamic layout support, skip to the next part.

FYI: This post regards client pipelines implemented in JSS. There are "regular" old backend pipelines implemented in Sitecore as well that concerns JSS. We will get to them in a later post. 

Extending a pipeline

First off, I'd like to say that I'm very happy that the minds behind JSS decided to embrace the pipeline-architecture. The extensibility and flexibility this approach offers is in my opinion a major strength in Sitecore. Maybe it was an obvious decision. Even so, I'm glad they went with it.

Now let's get to it. JSS will by convention read pipeline patches from sitecore/pipelines/**/*.patch.js, i.e. all files ending in .patch.js anywhere under sitecore/pipelines/. The pipelines folder does not exist from the get-go in your JSS app, so you have to create this yourself. For this example, I created a folder for the pipeline I wanted to extend (generateManifest) and then created a patch file inside it for the new processor I want to create (generateLayouts.patch.js).

Folder structure for pipeline patches

So that's the first step done: Placing and naming our patch in such a way that JSS pipelines will pick it up. Next step: the actual patch.

JSS will execute the exported config function from your patch module, and inject a pipelines-object as argument. This object is basically a CRUD-object for pipelines; you can get, add, update and delete. For this example we want to get the generateManifest pipeline, and then add a processor to it. This is done as below:

generateLayoutspatch

The result of this is that the array containing the two example layout objects are inserted into a layout-property in the pipelinesResult, which in the case of the generateManifest pipeline is a JSON structure saved to a manifest-file, which Sitecore in turn will use to understand what should be imported from JSS as items when app deployment is being executed. The code above is sort of like a monolithic patch-module, that contains the actual config patch as well as the processor logic. If you want, you can decouple them. See below:

generateLayout-module-example

And then the default function exported from your processor module would be invoked.

This is pretty much it for how to add a processor to a pipeline. If you want to see how to apply this in order to include layouts in the import manifest, take a look at this.

15 Jan 2019, by Bonny Nilsson | 

JSS, Sitecore 9.1, Pipelines, Config patching, Code-first