Structure your frontend the Helix way
This post requires some familiarity with Sitecore's Helix principles, if this is the first you hear about it I recommend you read more about it here. The post will also focus more on the concept than the technical nitty-gritty. Our specific technical solution regarding compilation and bundling is described further down, however not in great technical detail.
The frontend is kind of the last piece of the Helix puzzle, and for obvious reasons. The frontend of our solutions is not as tighly tied to Sitecore as the server code we build. However, the Helix principles are built on sound concepts, and when you've applied them to virtually every part of your solution except the frontend (and you don't have any heavy framework dictating how you structure your code here) there is really no reason not to rub it all over your frontend aswell.
If your mind went toward something other than what I intended with that last sentence, it's on you.
File and code structure
The first task was to break the age-old tradition of having separate source folders for your styles, scripts, templates etc. and step into this new modularized world we live in. Everything that has to do with a specific module should be structured together. Developers should feel confident that all code that pertains to (for example) the top navigation component is contained within a single top navigation structure, not spread out in three different ones; one for markup, one for JS, one for styles. Could even be more depending on your frontend setup.
Additionally, the left structure in the image above is probably kind of a best-case scenario of separated structures, where the paths all follow the same name-convention. It's just as likely, if not more, that the three separate structures are laid up slightly differently, making it even harder to find and logically connect the files your interested in.
Above you can see the structure this blog uses, and the modules in our .NET sitecore solution maps perfectly to our frontend-structure.
You might've noticed in the above image that directly beneath the feature-layer we have two folders, app and vendor. The app folder contain all of our own code, and the vendor folder contain all third-party dependencies. This is just a way to give you a nice three-layer load order without too much configuration. It enables you to put all of your fundamental dependencies, such as jQuery, bootstrap etc., in your foundation layer, making them the first assets to be read into your bundled files, followed by the feature dependencies, which can safely depend on foundation dependencies. Lastly, we load the project dependecies, which of course can rely on any dependency in the other layers.
How this is achieved technically
In our frontend solution Gulp takes care of compiling and bundling for us. Given what we've discussed so far in this post, what we need is to configure our paths so that Gulp looks for specific file-endings in the entire frontend, not in given js-, styles- or template structures. The way we achieve this is simply by defining our paths as below.
As you can see, we can use wildcard very effectively for most things, but if there are any dependencies (or files we've created ourselves for that matter) that require it, we have the option of specifiying the load order specifically as well, as with the bootstrap and jQuery paths in the example above. Now, one might think that "Hey, some of these will be read twice. For instance the bootstrap.css will be included in both of the below lines":
srcDir + 'foundation/vendor/bootstrap/bootstrap.css',
srcDir + 'foundation/vendor/**/*.css',
The good news is, one would be wrong! Gulp takes care of this for us, and makes sure that the file is only loaded the first time.
Making use of our above paths, we can define our gulp-tasks as below.
Get your Helix on!
20 Sep 2018, by Bonny Nilsson |
Sitecore, Frontend, Helix, Gulp