When it comes to building websites using a CMS, Sitecore is definitely the way to go! I have been building the frontend of websites in Sitecore for over five years and have not found any other platform yet that gives the flexibility to a frontend developer that Sitecore provides.
For me, building the frontend for Sitecore websites helped me realise the benefits of breaking your frontend code into modular components and smaller chunks, so I thought I would create a blog post to share the knowledge I have gained over the years.
1. Don’t write any code… (Just yet)
Thats right 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, how the Sitecore content is structured, the hierarchy of data, the designs, style guideline, typography and any other assets you have available to you.
With these assets you should be able to get an idea of how to break up your assets into logical functional areas which will ultimately form your Sitecore components.
I find sketching each component helps me decide:
What data and attributes are required informing the component’s object creation
How this should work in Sitecore’s Page Editor aka Experience Editor, do I need to create custom Experience Editor buttons so the component can be edited easily
What the widget should look like in different placeholders i.e in different location of the page
These are just a few of the things that I find useful to help me map out my frontend Sitecore build.
2. Everything is a component. All components are a module.
Everything you build in Sitecore is a component which can be added to placeholders in any location you define.
For example, if I have a Sitecore component I would have:
- banner.ascx or banner.cshtml
- _banner.less / .scss
- Here is a brief example of how I would layout my solution
As you can see from my Gist snippet, everything has a matching file of “example component” or whatever we decide to call our component.
By breaking out our component assets into separate modular files, this makes things easier to manage, update and package to different environments or even add 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”
By doing this we can pretty much install this components like you would a component from the Sitecore Marketplace.
3. Pick a CSS naming methodology
Over the years developing the frontend of many Sitecore websites I have found that sometimes you can get your pre-processor files or stylesheets pretty messy and unorganised.
Unorganised preprocessor 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.
I found that using a CSS naming methodology can help massively.
At my current work place 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. This makes things such as support, enhancements and code readability easier than not having a CSS naming methodology.
4. Build for Page Editor experience
Optimising for Page Editor, renamed to Experience Editor in Sitecore 8, can take some additional time right? Not if you build for Experience Editor first it won’t.
Some simple steps can help to reduce the time it takes to make sure you website works correctly in Experience Editor.
I find the best way to do this is to simplify your workflow and build with “progressive enhancement” in mind. You maybe asking yourself what do I mean by “progressive enhancement”…
For example, If I had a task to creating something as common as “clicking on an element to expand hidden content”
My challenge is not creating the accordion and its features, my challenge is how will the content editor create, update and modify the accordion in Experience Editor as the content is hidden by default.
This is when you add a little bit of backend magic into the mix and detect Experience Editor mode (if your not to sure how to do this there is an excellent blog post by Martina Welander you should check it out).
When the content editor then switches to “page preview mode” they will see the accordion in all its glory.
5. Beware of Sitecore 8 prototype.js
I simply applied the jQuery noConflict mode which resolved majority of the issues for legacy code to a degree, However I had to tinker about with some projects more than others).
Using “self invoking functions” and protecting the “$” in another method that can be used for example:
So let’s recap at some of the stuff you just read (unless you skipped to the summary!)…
First I take all available assets and break out what things are reusable in terms of “data structure”, “look and feel” and “functionality”.
Use a naming methodology like B.E.M or SMACSS or any other preference you have in mind. This will help your code to become more readable and lighten the load on selectors.
Never underestimate the power of Sitecore’s Experience Editor. Building things well for the Experience Editor will go a long way, not only for your customers, but will help you understand the true power of Sitecore and help on your journey to becoming a true Sitecore master!
Beware of the “prototype.js” and protect your $’s with a noConflict, write your code in self invoking patterns and everything will be awesome!
So some very quick bullet points:
- Don’t code, think patterns
- Think modular code
- Do code
- Experience Editor power!
- Beware the prototype (use a noConflict)
Hope you enjoyed the read 🙂