Sitecore tips every Frontend developer needs
I’ve picked up a few Sitecore tips after building Sitecore websites for five years, I’ve realised the benefits of breaking your frontend code into modular components and smaller chunks. And I’ve yet to find another platform that gives the flexibility to a Frontend developer that Sitecore does. (This article is aimed at Frontend developers. If you’re a Marketer, looking for information on Sitecore, here are our recent pieces on Sitecore 9 and Sitecore Experience Cloud or please contact us.)
Here’s a summary of my Sitecore tips for Frontend developers:
Before you start writing a single line of code, take a step back. Look at the available assets you have. Take into account the wireframes, the hierarchy of data, the designs, style guideline and typography. Also consider how Sitecore’s content is structured and any other assets you have.
You should be able to get an idea of how to break up your assets into logical, functional areas. This will ultimately form your Sitecore components.
One of the best Sitecore tips for Frontend developers is to sketch each component. This helps me decide:
Everything you build in Sitecore is a component. These can be added to placeholders in any location you define. When creating a new component in Sitecore I find it easier to break all of my component assets (such as LESS, SASS and Javascript) into modules in my solution.
For example, in my Sitecore component I would have:
Here’s a brief example of how I’d lay out my solution.
As you can see, everything has a matching file of “example component”. Some files have underscores such as “_file-name.ext”. This is a standard way of indicating that it’s a partial file. It will build into my app.less / .scss and bundle into a lightweight CSS file. The same thing would apply to the Javascript files.
Breaking your component assets into separate modular files makes them easier to manage, update and package to different environments. You could even add them to another solution to speed up the development process.
The same can be done with Sitecore packages. We can create our Sitecore package to include:
This way we can pretty much install these components like you would a component from the Sitecore Marketplace.
I’ve developed the Frontend of countless Sitecore websites over the years. And I’ve found that sometimes you can get your pre-processor files or stylesheets pretty messy and unorganised. Unorganised pre-processor files or stylesheets can lead to a world of hurt later on in a website lifecycle. Enhancements, support and maintenance become a nightmare to manage as a website grows.
Another one of my Sitecore tips for Frontend developers is to use a CSS naming methodology. In my experience, this can make a massive difference. Here at Kagool we have adopted B.E.M (Block Element Modifier) naming methodology, this helps us keep our CSS specificity low when building Sitecore components.
Everything is self-contained and easy to maintain. So things such as Sitecore support, enhancements and code readability are easier. If you currently don’t use a naming methodology, I highly recommend trying one out.
There are some great CSS naming methodologies out there. Here are a few of them:
A lot of developers think optimising for page editor will take up more time. But if you build for page editor from the start, it will actually save your customers time down the road. Some simple Sitecore tips can make sure you website works effectively in page editor.
The best way to do this is to simplify your workflow and build with “progressive enhancement” in mind. What do I mean by “progressive enhancement”? Simply put, you should build your component in its simplest form with base HTML and CSS. You then enhance the experience with Javascript if required.
For example, if I had to create something common, like “clicking on an element to expand hidden content”. This is going to be an accordion which needs a show and hide feature. And it will need Javascript to function correctly and fit to any appropriate placeholders. My challenge isn’t creating the accordion and its features. But how the content editor will create, update and modify the accordion in page editor, as the content is hidden by default.
This is when you add a little bit of Backend magic into the mix and detect page editor mode.
With page editor mode detection in place, you can add a simple line of Javascript such as
This lets you disable all accordion Javascript functionality in page editor. You can simply stack all the content and show it to the content editor. When the content editor then switches to page preview mode, they’ll see the accordion in all its glory.
Sitecore 8 uses prototype JavaScript library, which uses the same “$” symbol as jQuery. This can cause quite a few problems with legacy or poor code. I’ve fallen into this trap when upgrading from Sitecore 7 versions to Sitecore 8.1. And it caused much pain and annoyance. But once I figured out the issue it was easy to fix. Which made me think about how I could write my Javascript to tackle this problem.
I simply applied the jQuery noConflict mode which resolved majority of the issues for legacy code. But I had to tinker about with some projects more than others. Using “self-invoking functions” and protecting the “$” is another method.
For example I’ve coupled this with the “Revealing Module Pattern” as outlined by Addy Osmani in his excellent book “Learning Javascript Design Patterns”. And if you want more quick Sitecore tips, checkout Todd Motto’s “Mastering the module pattern”.
At Kagool, we’re all about Sitecore. We’re one of the top UK Sitecore Platinum Partners. And the biggest UK partner to be exclusively Sitecore. So we get to explore what it can really do for enterprise website design.
For more Sitecore tips, or to get a Sitecore demo, drop us a line. We’d love to hear from you. If you’re looking for Sitecore Jobs we’re always looking for talent to join our teams in Cardiff and Manchester.