Why You Need a New Components Folder in Your Headless Sitecore Solution

Why You Need a New Components Folder

Long story short, it's about optimizing your JSS solution for Headless Sitecore. I'm going to explain why and how to make this change so you can easily implement this in your current Sitecore project!

How the Sitecore Component Factory Works

What is the Component Factory? Why is this important? Well, the Sitecore Component Factory is a feature in Sitecore that allows us developers to create and manage components dynamically. The Component Factory will first define component templates and then map them to any specific classes or interfaces inside your code. So when Sitecore requests a component, the factory references this mapping to instantiate any corresponding classes or interfaces (similar to a giant hashmap!). This allows us to focus on building that flexible and modular code that we all dream about creating!

We can illustrate this with an example of a TV Show, imagine that each character in the show’s story represents a different component template. When a specific character (component) is needed in a scene (web page), the Component Factory instantiates the corresponding actor (class or interface) to play that character, ensuring that the story (website) is dynamically constructed based on the required components.

If you want to poke around the component factory, you can generally find it inside the tmp folder in your JSS application. src/temp/componentFactory.ts

How to Optimize Your Component Structure for Sitecore

Now we know what the Component Factory is and how it works, you understand that every component you create inside the default src/components folder it directly referenced by the Component Factory. This happens even if the component isn't referenced by a Sitecore rendering (the file is used only as a subcomponent). Since it's very common to split up your code into more maintainable single responsibility components, all these components are going to be added to the Sitecore Component Factory, but never used.

The fix for this is to create a new subdirectory that can store all your sub/child components. You can name the new folder anything you would like, but I recommend using component-<yourNameHere> when naming, this way your new folder is still directly next to the default components/ folder in your object explorer. To me, component-children makes the most sense for the new folder name.

Next.js Example folder structure:

nextjs-solution-root/
├── .next/
├── public/
├── node_modules/
├── scripts/
│
│
├── src/
│   ├── components/ - This is the default sitecore folder, put your renderings here
│   │   ├── Navigation.tsx
│   │   ├── Container.tsx
│   │   └── ...
│   │
│   ├── component-children/ - This is our NEW folder for all shared/sub-components
│   │   ├── shared/
│   │   │   ├── Button.tsx
│   │   │   └── ...
│   │   ├── Banner.tsx
│   │   └── ...
│   │
│   └── ...
│
│
├── .gitignore
├── package.json
├── README.md
└── ...

Final Thoughts on Organizing Your Components

It's important to segregate any components that are not directly related to a Sitecore rendering. The goal is to only allow components that are directly related to a Sitecore item into our Component Factory. You should move all your components that are shared or not top-level tied to a rendering into a new components folder.

---