3

We are planning to start a new Helix principles compliant project.

We got pretty good idea on backend Sitecore solution setup by looking at Habitat implementation.

Keen to get your advice based on your Helix project on:

  1. How to set up the front end assets (css/jss) that match with backend Helix setup e.g. feature with css/js ?

  2. How does front end team integrate with backend ?

Thanks.

  • Do you plan to use SXA on this project? – monkey.dsc Sep 4 '18 at 8:53
  • No sxa for this – Nil Pun Sep 4 '18 at 11:47
3

For Point 1 have a closer look at the Foundation projects "Sitecore.Foundation.Assets" and "Sitecore.Foundation.Theming" in the Habitat solution.

Sitecore.Foundation.Assets makes it possible to add assets by theme, page or rendering. The Theming project allows you to add different themes to a site.

Point 2 is very based on your organisational structure, front-end-team should work in .less files which are compiled to .css file by Web Compiler and Bundler & Minifier (both VS extensions).

  • FED works ok n same VS solution as BED? How is your setup – Nil Pun Sep 4 '18 at 20:38
  • Best option for that is SXA, you can import and export themes as you want, FED gets the exported files and manipulate them as they want... Later we just import the modified files and everything is in place. Without SXA I would have a Frontend-Project in my Solution where FEDs can working in. – monkey.dsc Sep 5 '18 at 9:41
  • FE can work on separate project. out of VS using any IDE and repo. Once done they can copy the Styles and markup in the VS solution. This way it saves merging issue and only the working and tested code is available for BD. – Sitecore Sam Sep 10 '18 at 12:09
1

Our front end team works separately in Pattern Lab, and we don't require them to have Sitecore running to do their work. It's just not efficient for them to have to learn Sitecore or manage a local Sitecore environment.

We typically take their compiled FE assets and put them at the Project level, this is done with a gulp task when we run a build/deploy. This way you can have some common base assets that are shared by all sites, then specific Project files for site specific overrides or themes. You can organize your FE assets by tenant/site according to the Helix principles this way, at the Project level.

Habitat advocates keeping FE assets alongside the features, and that's great for full stack teams, but it's not practical for our team's workflow.

  • I think this is an important point: team and project structure really should dictate how you handle this. – techphoria414 Mar 11 at 13:14
1

The question might be a little too broad for StackExchange, since it invites discussion, but, what we do is as follows:

Our design team works within their own space, using Jekyll to generate a static site on pages and modules. While creating modules they determine the CSS/SASS (and JS/hopefully TypeScript one day) necessary for those individual modules to work.

They have a build process (currently Grunt) that compiles minified CSS and JS for the entire site (collection of almost all modules). Those assets are deployed to Azure as a versioned (/yyyy/mm.dd/...) release, and they let the dev team know.

We have a project layer module (Xxx.Project.Common, since our websites share the outer wrapper) that defines the main layout(s) and adds the base CSS/JS includes within those layouts.

We then have a Xxx.Feature.Yyy module for each individual component that the designers develop. We take advantage of the Sitecore.Foundation.Assets module from the Habitat project in cases where we want specific JS (and eventually CSS) to be included when the module is added to the page. These are tied to the module in Sitecore, with the path to the asset on Azure/CDN entered into the corresponding field in Sitecore.

This allows our designers to work with HTML, CSS, and JS, without having to get deep into the code itself. The modular approach they're taking also makes it easier to create these as Helix-based modules.

Another big benefit of starting with flat HTML components is that it makes it easier for these to be ported over to WordPress as well as static sites.

0

Check out the yeoman generator for Sitecore helix by Anastasiya Flynn. It gives a great scaffold for using TypeScript, Babel, Webpack, SCSS in a helix project.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.