This blog post is the final part of my talk at the Sitecore user group hosted in Kagool’s Manchester office.

JavaScript Frameworks / Libraries and Sitecore

The final part of this three part series will cover JavaScript frameworks / libraries and how front-end developers could use them in Sitecore projects. However before you start reading about this stuff I would like to give you a little background on what lead me to speak about this topic.

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?
  • Can this task be completed without a framework using less code and plain old JavaScript?
  • 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.

This was a challenging problem to solve and at that time it felt like JavaScript frameworks were popping up every month. So I assessed the problem and started investigating the tools that could help me solve the problem.

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

Using JavaScript frameworks and libraries do present some problems for the Experience Editor. Many of the JavaScript frameworks / libraries like React, Angular and Vue have form of HTML templating that’s injected onto the page. This will normally rendering functionality of the Experience Editor unusable, simple functionality such as inline editing of content can no longer be used and a work around has to be put in place. For example, A project I worked  on recently had a 3rd party team which built the whole front-end using React without knowledge of Sitecore which left the Experience Editor with limited functionality.

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.

Sitecore JavaScript Services (JSS)

If you haven’t already heard the news from the Sitecore Symposium in Las Vegas. Sitecore have been working on Sitecore JavaScript Service AKA JSS which I’ve been lucky enough to participate in the alpha and beta versions.

What is JSS?

The official Sitecore statement for JSS is:

“JSS is a complete SDK for JavaScript developers allowing to build full-fledged modern solutions using Sitecore and JavaScript and being completely disconnected during development and deploy to any platform in a headless configuration with full Experience Platform capability preserved.”

https://jss.sitecore.net/

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.

Arnold says to download JSS

Summary

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
  • Can the problem be solved using plain old JavaScript
  • 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.

Whats next?

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.

Advertisements

One thought on “Musings of a Sitecore Frontender – Part Three

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s