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:
- Take all available assets and break out what’s reusable in terms of data structure, look and feel and functionality
- Create Sitecore data structure for the components you need with associated LESS / SASS files and Javascript files
- Use a naming methodology like B.E.M or SMACSS to help your code become more readable and lighten the load on selectors Build things well for the Experience Editor to help yourself (and your customers) in the future
- Beware of the “prototype.js” and protect your $’s with a noConflict
1. Don’t write any code… (Just yet)
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:
- What data and attributes are required for the component’s object creation
- How this should work in page editor and if I’ll need to create custom experience editor buttons
- What the widget should look like in different placeholders such as in different location of the page
- Are there common styles or functionality I can create using a single class or Javascript function
2. See everything as a component (module)
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:
- banner.ascx or banner.cshtml
- _banner.less / .scss
- banner.js
Here’s a brief example of how I’d lay out my solution.
Code snippet:
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:
- Sitecore objects with all component Sitecore dependencies using “items statically” objection
- Component files from the solution using “files statically”
This way we can pretty much install these components like you would a component from the Sitecore Marketplace.
3. Pick a CSS naming methodology
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:
4. Build for page editor experience
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. If you’re not too sure how to do this, check out this blog post by Martina Welander.
With page editor mode detection in place, you can add a simple line of Javascript such as
Code snippet:
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.
5. Beware of Sitecore 8 prototype.js
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”.
Find out more Sitecore tips
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.
