Seperate Component and Componenent SCSS styles from Campaign Styles

[danalexilewis]

Hey team, now that I understand the system a bit better, namely that components still often need .scss to go along with them as their styling API for components is not as replete as stylesheets. I'd like to make a suggestion for a relatively easy short term improvement.

Have a seperate set of .scss files specifically for components that are loaded into every campaign. ie its an organisation level base style file(s)

AND than make sure that campaign styling is loaded with a default higher specificity than these styles - so it overrides them.

Once you have done this than I would update the api so its much clearer that there are different packages you are deploying. Something like what lerna does. That way its very clear your updating different packages.

Out the box a new raisely account would have 1 components package and 1 campaign package.

Generally language wise I like:

• packages
• campaigns (a type of package)
• components (a type of package)

• custom-styles.scss for the file accessible through the ui.

  Alternatively you could make components operate at a per campaign level instead.

  Anyway, food for thought.

[tommaitland]

Thanks Dan! This would require adding API support to Raisely for such a SCSS file, then it would need to be integrated into the CLI. I'll keep the suggestion open here to see if anyone else would find this helpful, then we can see where it fits into our product roadmap.

[f1yn]

@agentlewis another way to get the same results (portable styles across campaigns) would be to use the Emotion framework. https://components.raisely.com/?path=/docs/helper-emotion--page

The specifically is a bit harder to deal with, but in essence Emotion is a single level, and most campaign styles are following BEM practices, so they essentially should cancel out. We also make sure campaign-specific styles are always loaded later in the DOM, so the cascade should go:

(in order of loading - specificity not guaranteed obviously, but order is):

1. core base styles (layouts/grid, BEM) 
2. emotion styles (dynamically loaded/generated, mostly classnames with specificity added only when needed) 
3. campaign theme styles (custom and built-ins, even more BEM, always id=campaignStyles and near the bottom of the DOM)

That said, your comment "as their styling API for components is not as replete as stylesheets," makes me think there's something missing here or isn't working as intended?

[f1yn]

If you're looking for specific font/color codes, these can be accessed on window.campaign.config.theme, which includes dynamically and absolute colours, font names and other style settings you might need.

Not everything, but you can at least apply brand specific styles if you'd like.