Promote .scss.liquid only for theme editor style overrides

[t-kelly]

Liquid was not designed to be used in SCSS. However, we need it to allow theme styles to be customized by the Theme Editor. As noted in #258, .scss.liquid is hard to work with and can ultimately only be built on our servers. I believe for these reasons we should use it as little as possible.

Traditionally, we have defaulted to using .scss.liquid everywhere. I propose that we start using scss.liquid only for styles that are changed by the Theme Editor, and that these styles override default styles specified in .scss. For example:

theme.scss

$default-background-color: #c6c6c6;

.component {
  display: inline-block;
  width: 33%;
  min-height: 200px;
  background-color: $default-background-color; 
}

theme.scss.liquid

.component {
  background-color: {{ settings.colors.default_background }};
}

How we actually accomplish this with a easy workflow is still a mystery to me... More experimentation to come.

[jonathanmoore]

I feel like there might be a creative solution to use webpack to bring in a theme's live settings_data.json data to be converted into usable Sass variable values during development, and then converted to liquid {{ settings[name] }} values during build. At the same time, eliminate the need for a second asset to overwrite styles.

Currently I'm hitting a road block transitioning to Slate 1.0 due to the challenges and limitations of chaining variables from liquid to CSS to SCSS (issues below). At this point I have to give up local SCSS compiling for blazing fast previews, and switch back to the slow, old-school way of using Slate to upload the asset every time the file is changed.

• CSS Custom Variable - SCSS operations and functions #503
• CSS Custom Variable - Liquid variable or control flow tags #541
• Plumber SASS for vertical rhythm starter-theme#1
• Invalid usages of liquid assigns in css-variables starter-theme#60

JSON to SCSS

Researching webpack, JSON and Sass I came across sass-vars-loader and node-sass-json-importer which could be potential solutions. This webpack loader can import a JSON file to so that the values could be used directly in SCSS.

// settings_data.live.json

{
  "color_accent": "#d93f0f",
  "typography_base_size": "16px"
}

// theme.scss

body {
  font-size: $typography_base_size;
}
h1 {
  font-size: $typography_base_size * 1.75;
}
a {
  color: $color_accent;
}

Then during build the live settings json data could generate SCSS vars with liquid values.

// theme.scss.liquid

// Generated during webpack production build
$color_accent: {{ settings.color_accent }};
$typography_base_size: {{ settings.typography_base_size }};

body {
  font-size: $typography_base_size;
}
h1 {
  font-size: $typography_base_size * 1.75;
}
a {
  color: $color_accent;
}

Advantages

• Eliminate the need to pass liquid to css vars to scss.
• Reduce potential typos and errors since the settings_data.json and settings_schema.json vars would carry over directly to scss.
• 🙌Give developers the choice to build .scss.liquid assets for Shopify's servers to compile (Sass 3.2) or locally compile .css.liquid files.
• Down the road it might be possible to quickly toggle between local presets of settings data for testing.

Challenges

• Figuring out how to quickly sync live settings data, especially while previewing in the Theme Editor and making changes.
• It might be possible to use an API webhook to receive an event when the theme has been updated, but don't think there is a way to isolate events to only theme editor (settings_data).
• If files CSS files are compiled locally during build, the same limitations of using any type of operators or functions on theme settings will not work.

[t-kelly]

I think we have the basics of this covered in https://github.com/Shopify/slate/wiki/Styles-with-Liquid. We're working through the kinks, like those mentioned by @jonathanmoore, one at a time. In general I think we have a decent direction for Liquid styles!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.