If you've worked with SxA you probably are familiar with Creative Exchange. It's deceptively simple: click a button, get a zip file, edit the styles, reimport and you're good to go. When you try to leverage it in a typical project that includes both Front and Backend developers, you quickly run into issues.
Problem #1: Base Themes and Helix
If you're committed to following Helix (and you should be), you're thinking beyond just creating sites, and creating reusable features that can be activated in Tenants and Sites. If you are, you'll need to create a base theme for each feature that includes the base scripts and styles that allow the components in that feature to function. Creative Exchange doesn't fit this module well as each site just gets a giant zip file and doesn't encourage editing base themes. Though you can enable it, you'd still be left with issues if you're trying to style more than one site that has the same base theme.
Solution: Media Library Watcher and Gulp Tasks
To make it easier to work with base themes I've created a Sitecore File Watcher that looks for a "mediaLibrary" folder in the root of the site. Any thing added or edited in that file will automatically be created or updated in the same path in the media library itself. This allows you to create a folder structure in your features that will mimic their destination in the media library. To Sync to Sitecore, I've added two targets to our gulp file: Publish-Media-Library-Folder-Files to copy all resources under folders in your solution to your sitecore instance and Auto-Publish-MediaLibrary which will create a watcher and automatically update any files that are change in your solution. (Auto Publish doesn't see new files, as the gulp watch command only handles updates. Will eventually try to pull in another watch command to fix this).
Problem #2 Variants and Component Markup Flexibility
Creative Exchange allows front end developers to only edit the styles, scripts and images that are exported. While they can add classes to components, they cannot change any of the markup itself. The idea that Sitecore Developers can create a bunch of components throw it over the wall and a front end team can get everything to look perfect is naïve. Markup a dev team creates without consulting with front end developers may not lend itself to styling without changes leading to either a bunch of back and forth between front and back end teams or worse yet: front end developers hacking away with JavaScript and CSS creating crappy code.
Solution: Handlebar Variants and a Custom File Watcher
If you haven't looked into Handlebar Variants, I can't recommend them enough. Basically they allow you to define your variant markup in a single Variant Field and give you all sorts of ability to do things that aren't possible with the out of the box variant fields. The one drawback is that they require the templates themselves to be defined in Sitecore Items. After I created the media library watcher, I built a similar Template Watcher that allows you to create a "templates" folder in your project, and create a path that maps to the same location in the content tree and define html files with the same name of the variant field, and when updated will automatically update the content of variant field template. I also added gulp targets Publish-Templates and Auto-Publish-Templates to sync your project with Sitecore. This combined with Publish-All-Views and Auto-Publish-Views will give Front End Devs everything they need to control markup without having to deal with Sitecore and deployments.
Problem #3 Source Control and Deployment
So even if creative exchange worked perfectly for your needs, you still need to think through source control and deployment. If you export your site using creative exchange, you can unzip the source and check it into source control and have your team work on it there. But in order to get it back into Sitecore, and deploy it into any environments for testing, you'll need to get someone to import it, then sync with TDS or Unicorn so that it can be packaged and deployed. If you have parallel front end and back end development, you'll almost need an additional person to manage the exports, imports and deployments of front end code. Not ideal to say the least.
Solution: Automated Creative Exchange Imports
When you export or import using creative exchange, you have the option to use a folder on the server instead of a zip file. By default, this folder exists under
\App_Data\packages\CreativeExchange\FileStorage\SiteName.
Instead of dealing with unicorn or tds, if you deploy your static creative exchange folder to that same location, you can just run a folder import and have everything deployed in your environment. Sounds good? Not so fast, as apparently creative exchange was not built to be integrated with a build process. Leveraging JustDecompile and going through the code, I was surprise at how painful it was to make Creative Exchange do what I wanted. The existing code was meant to be run as a Sitecore Command Dialog, was dependent on HttpContext and the Request object, making it really hard to run as part of a build. In the end, I ended up creating a new api that can be invoked from build to run the import.
To call it make a "Get" request to http://SitecoreInstanceName/api/sf/1.0/creativeExchange/import/XXX_GUID_OF_HOMEPAGE_OF_SITE_XXX and the import will be run.
I warn you the code is not pretty but it works. The CreativeExchangeController calls two SxA pipelines, hacks the Http Request object (apparently you can do that) and the Sitecore Context Database.
As mentioned all code is in the SXA branch in github.
