This blog post is the final part of my talk at the Sitecore user group hosted in Kagool’s Manchester office.
Over the years I’ve been following a fantastic developer by the name of Mattias P Johansson, otherwise known as @mpjme on Twitter and YouTube. What I’ve written about in this blog post has been inspired by these videos.
If you didn’t watch the videos that’s ok you will get the gist of this blog as it unfolds. I recommend subscribing to MPJ’s YouTube channel FunFunFunction and checkout some of the other programming topics he covers.
When should you use a framework / library?
You’re about to start a shiny new Sitecore project and you want to a “React, Angular, Vue all the things” because they’re cool to use and very popular in the front-end community and for good reason.
Before you delve into picking a framework or library Stop! Don’t pick a framework / library just yet! Why? Because understanding what you’re building and the requirements you need to meet are far more important at the beginning of a Sitecore project.
When I approach a new Sitecore project I try plan out as much of the requirements and how a component is going to work and how the user is going to interact with it in Sitecore. These are a few of my thoughts when I approach a task requirement:
- Will the component use personalisation?
- Is there a lot of state management or interaction?
- How will the user edit content in the Experience Editor?
- Does the component need to be editable in Experience Editor?
- How complex is the component?
- What are the licence issues that could come with using a framework or library?
- What performance impact will there be on page load times adding a framework or library?
With these questions in mind, this has helped me reason about my code and framework / library of choice differently in recent times.
How frameworks can be used with Sitecore?
Frameworks can most definitely be used in Sitecore and be used well. A few years back I was the front-end lead on a project that required sections of the website to be downloaded and used as an offline but still had the functionality of the .NET application.
After many hours of investigation and some hacked together POC’s I found Angular was a framework that could help achieve all the the task goals and deliver a successful project which later on won a Sitecore award!
If you want to find out more about this project be sure to checkout the case study on the Kagool website.
The impact of the Experience Editor
The common way to solve this problem is to create a view or controller rendering, add the same HTML from the React component to the view rendering. This way you can disable React functionality in the Experience Editor and fallback to the rendering resulting in minimal impact to the Experience Editor functionality. Switching to preview mode in Experience Editor will enable the React component and data can be passed to the component from Sitecore.
This approach does come with some drawbacks such as maintaining two lots of HTML for both the React component and the rendering effectively doubling the development effort.
But problems such as this maybe solved in the not so distant future.
What is JSS?
The official Sitecore statement for JSS is:
If you attended SUGCON in Amsterdam or the Symposium in Las Vegas. You might have seen a demo and some of the functionality that comes with JSS. If you haven’t then I recommend downloading the JSS preview for Sitecore 9 and start off with the Basic application until you feel comfortable, you will need to know some basic Sitecore knowledge which I’ve mentioned in my part two (skip to the summary and see the bullet list) of this blog series.
Working with Sitecore as a front-end developer can be challenging for anyone new to the CMS especially if you’re looking to use a framework or library in your project.
- What problem am I trying to solve
- Would a framework or library benefit or help solve the problem
- What impact will the framework or library have on the Experience Editor
The tech preview of JSS is now available for download, this should help ease front-end developers into Sitecore projects whilst maintaining their current workflow and only requiring minimal knowledge of Sitecore.
Hopefully this final post in the series has given you a few key areas you should check out if you’re a front-end developer new to Sitecore.
I hope you enjoyed reading this blog post and found value in some of the things I’ve talked about throughout the series. Thanks for reading and happy coding.