Modern website development has a trend for using fixed position components. When developing the Front-End for this type of component in Sitecore you need to think about how these components will work in the different Page Modes.
In this blog post I’ll take you through the journey and the challenges that I had to overcome.
A brief history of the problem
A few weeks ago I was working on a client project which was in its UAT period and a few bugs came out of this process. The project goals were to create a new set of components and a completely new user interface a from a third party set of designs and wireframes.
We had a Functional Requirements Document (FRD) from the third party which allowed the team I was working with to map out our Sitecore build.
Some of these new components had features such as fixed position where a user would scroll down the page and a component would be fixed to the top of the screen to promote a document download or white paper.
We implemented these features by calculating the scroll position and the component position. If the scroll and component position matched I would update the CSS class to fix it to the top of the browser window.
When the client set up the page in Page Editor and then wanted to see the outcome in Page Preview mode, the fix position component became lost underneath the Sitecore Page Preview Ribbon, which was not ideal; the client could not see how the page functionality worked before submitting the page for review.
This lead me to try and tackle this problem.
First Attempt: Measure the Sitecore Page Preview Ribbon
When I first addressed this problem I thought the best way was to measure the height of the Page Preview Ribbon element and update my scroll trigger point if the user scrolled down the page.
I was able to get the height of the Page Preview Ribbon by using the Sitecore CSS selectors that were available “#scWebEditRibbon” and adjust my scroll trigger point fairly with the additional height of the “#scWebEditRibbon” class.
However as soon as the user clicked on the expand / collapse button in the Page Preview Ribbon this would cause the code to trigger again and update the scroll trigger point.
To cut a long story short, there were too many variables to cater for and I was sending myself into a rabbit hole fairly quickly. The code I was writing became complicated and took far too long to write.
Luckily a colleague of mine Lea Bialachowski asked why I didn’t just hide the Page Preview Ribbon? This was one of those “duh” moments! I thought “Yep you’re absolutely right!” I completely scrapped the approach I was going with and went back to the drawing board, simplifying the whole approach…
Second Attempt: Show / Hide the Sitecore Ribbon
In the second attempt I decided to add markup to the closing body tag to act of a button for the user to click which would initialise my show hide functionality.
I did this by checking if the #scWebEditRibbon selector was in the DOM. If so I would show my custom markup and bind the show / hide functionality. This way I could show the whole page to the user as it would be if it was a live preview without the addition of the Page Preview Ribbon.
So the code…
The custom markup used:
This was styled and by default had a property of display: none;
I then created a small utility function which was initialised in my app.js file
With this I was able to give the client the ability to toggle the Page Preview Ribbon so they could see the page and its functionality without the Page Preview Ribbon in view.
By simplifying, it resulted in no “bloat” in the code base; a specific purpose which only occurred on pages that used a fixed position component when using Page Preview.
This functionality could be improved by Sitecore adding a feature which exposes a publish event that Front-End developers could tap into using a subscribe function to trigger custom functionality. Maybe one to send to Sitecore as a feature request?
Thanks for reading and happy coding.