0 Comments
Bob's way - tuning SXA This post is my black and white vision of Sitecore's Experience Accelerator and colorized like Bob Ross would do :-)

What to jump straight to my findings? Click here

TL;DR

Since 2001 I have been developing in SharePoint and last year I made the swith to Sitecore. When I started working with Sitecore my first project was with SXA. This was a somewhat awkward experience as I was used to create markup and bind data to it.

Something I heard a while ago:

After the implementation we give all the small SXA components to the marketing department so they can start building pages. Designs made by the designers are ignored

The Black

Lets jump right in and let me start with my black rigid vision of SXA and start with the info given by Sitecore:

Web development teams use Sitecore Experience Accelerator (SXA) to speed up the production of websites and to reuse components, layouts, and templates across a variety of sites.
SXA separates structure from design, so front-end designers, creative designers, content authors, and developers can work in parallel and you can deploy and maintain multiple sites quickly and cost effectively. Once a basic user experience plan is in place, everyone can get started on the platform. For example: the content author can start entering the content in the wire-frame environment, while the front-end developer works on the theme, and the developer sets up the data templates.

I'm not going to talk about terms like front-end designers and creative designers, no clue what kind of people they are. I know designers. When it comes to designers I know like developers they know what they want. They use their own tooling. Designers need to work in the experience Editor and do the layouting and scaffolding in there.

Supported Grid Systems in SXA

Setting up a site with SXA is simple, you just need to select one of the three supported grid systems: Foundation (I guess from Zurb), Grid 960 and Bootstrap 3. Grid 960 is old and out of the box does not provide a flex layout. A very skilled front end developer once told me that Bootstrap is rubbish, it gives you too much which you do not want to use. And more important, do you want to have all sites look like a Bootstrap site? I'm not familiar with Foundation so no opinion about that. Happy to say that your own grid system is also supported.
Of course the designers can start with a design elsewhere but eventually they are forced to work with these tools. SXA and flexibility in here might be a paradox.

Creative Exchange

Then there's the Creative Exchange: export everything into a Zip-file and set up your environment so you can start styling. The sass-files can be extended with your own styling but you are not allowed to change markup in any way. You wil only be allowed to add CSS-classes on predefined elements. This will render us developers into script kiddies!!

Because there's already a set of CSS-styling for the SXA-controls in place you need to override them frequently with the !important rule. In the past I learned that using this tag is evil and should only be used if all other ways to find a solution fail but you need to be careful.

All above feels rigid to me and ....

The White

At the company I work for we have three different approaches when creating sites in Sitecore:

  • Plain development (MVC)
  • Using a framework (more about that below)
  • SXA

The first one is simple ASP.NET development with MVC views. SXA is a no-brainer: you work with it as it is described in the documentation. The third one is a Framework we created which allows controller renderings using React.NET and render its contents server side. Many client side frameworks like AngularJS, Knockout, ReactJS bind data to your markup. This is done in the browser, therefore it is called client side. This is an issue when it comes to SEO. Some web crawlers (e.g. Google) now are able to index those websites but it will never be an optimal solution. Various solutions will force you into using statically generated pages for the indexes. So what's the use of Sitecore if you start working with static contents... Working with server side rendered React components removes those issues.

Back to SXA. Despite my negative start about SXA I think it is also cool if you use it the right way. SXA heavily relies on Powershell. Creating structures like a tenant or a site will do all the work for you under the hood. This means as a developer you do not need to add modifications to the web.config (through the App_Config/Include folder).
All content is well structured and follows the Helix Design Principles.

Tuning Sitecore SXA - the Bob Ross version


I would like to use best of both worlds. This means that I want to use quick development of a website (and hence quick time to market) as well as the best practices developed over time.

Goals are:

  • Out of context development where designers and front end developers can keep working with the tools they are used to. No need to force them to use other tools.
  • Add your own CSS grid systems
  • Render Markup on the server
  • Use the Experience Editor Toolbox and drap 'n drop components (see image below)

Following several examples on the web I found that I could create SXA components which I could drag and drop from the toolbox. In that example I had to wrap my partial MVC view in an SXA tag. This forces a div around the component. Next I rendered an anonymous object from my controller but here you could also use Glass Mapper. The controller will get data, load the dynamic placeholders, because we want to add other components in the placeholders of our views. Of course the fields in the view needed to be edited inline so we check if we are in the Experience Editor and then render the field into a property rather than getting the field value. This will render additional markup allowing the content editor to change the value of fields.

So, now we're done with the controller we also need to add the view, this calls the Render function for my ReactJS component:

@* Server-side rendering using ReactJS.NET *@ @Html.React((String)ViewBag.Module, Model)
Because the React component accepts an array of attributes we can pass the anonymous view model and it will magically render my component. The name of the React component is exposed through the ViewBag.

Techniques used were:

  • react.net
  • Sass CSS with superpowers
  • Storybook out of context development of React components
  • NextJS blazing-fast static site generator for React
  • controller renderings

Keep in mind that you will need to provide the data structure to the front-end developers so they can render their components in storybook based on the view model output provided by the controller.

At the end we only have to add some configuration to the SXA configuration. In the content structure under the SXA site there's a node under presentation called available renderings. This is the place where you add your controllers renderings.

The Wrap

I think that when it comes to SXA you should use it mixed with other techniques. It's a little weird to create a minimalistic website and then use all the high end marketing gimmicks on top of it. This can be done for the sake of parallel implementation and a faster go to market but in the end the customer wants something special and not something which could be looking like a Wordpress website. Combining SXA with various techniques will eventually give you both the flexibility and the option to use the great functionality of SXA. Time to market will still be short and you will be ready for the next steps in the evolution of the website.

Comments