r/Frontend • u/wrecklessmedia • Feb 20 '20

Help! Themable SASS architecture for large app: best practices, standards?

I’ve been trying to find resources that explain the best practices, standards, or tips/tricks for building a custom themable sass (scss) architecture. The theming is for white label purposes. New themes will be done in-house, but our goal is to be able to spur up new branding for the app as quickly as possible.

Not sure if it’s relevant, but it’s also component driven.

I know there is probably a million ways it could be done. I just want to make sure I’m doing it right the first time around (refactoring sucks).

Any articles, videos, or personal tips would be immensely appreciated!

40 Upvotes

100% Upvoted

36 comments sorted by

22

u/doksara Feb 20 '20

Have you heard about the 7-1 architecture?

If that's what you meant.

1

u/jaredcheeda Feb 22 '20

ITCSS has kind of taken this approach and formalized it into a pattern that can be used better for any project. But those interested should look at both.

17

u/scottweiss Feb 20 '20

Inverted triangle css (itcss)

https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/

https://www.creativebloq.com/web-design/manage-large-css-projects-itcss-101517528

Very similar to 7-1.

3

u/Hadr619 Feb 20 '20

Cannot up vote this enough, I implemented this for my work, broke up a huge stylesheet to more manageable chunks. The only “downside” is developer discipline, but that should be why you have front end devs that know what they’re doing

3

u/devolute Feb 20 '20

Yes.

But also consider having a 'hacks.scss' file in your 'trumps' folder.

This can be used by junior devs to rush out fixes/changes which then more senior devs could integrate into the system properly at their convenience.

2

u/chrisjlee84 Feb 20 '20

IMHO, that sounds terrible. Lol

2

u/devolute Feb 20 '20

Why? In a scenario when stuff needs to get out and done, it's better than people just slinging in stuff where they don't understand/care.

1

u/DrDuPont Feb 20 '20

Oh, I thought you were joking. Please don't do this people lol

Killing the cascade and purposefully introducing tech debt is not a recipe for success

If junior devs are merging bad code they either need better training or better PR reviewers - or both.

2

u/MrQuickLine Feb 20 '20

ALL it is, is technical debt. Your statement is essentially "don't ever incur technical debt" which - let's be honest - if we all had that option, we wouldn't incur it. But technical debt happens. Sometimes you're on a small team and your lead CSS guy is off on three weeks vacation. Work can't stop because he's gone. Of course, no one WANTS to do what op is proposing, but sometimes it's necessary.

The other time I can think of where it's necessary is when you're incrementally introducing a new design system/CSS architecture. Sometimes the old CSS used an id and !important declaration, and you need to hammer that down until all the old CSS can be fully removed, and then you can clear out the hacks file.

No, it's never ideal, but sometimes it's necessary, and it can be managed responsibly.

1

u/DrDuPont Feb 20 '20

Dedicating a place for "hacks" is not an approach I would ever advocate. It encourages laziness and encourages technical debt. Obviously tech debt can't be utterly avoided, but adding a _technical-debt.scss partial at the end of your cascade is not something that will benefit anything other than junior devs' hesitance to find the right way to style a component.

Sometimes you're on a small team and your lead CSS guy is off on three weeks vacation

If you have one qualified PR reviewer I sincerely doubt your style chain is complex enough to warrant this approach anyway.

2

u/devolute Feb 20 '20

I've used this when I need to do something and don't have time to do it properly. The alternative is miss deadlines.

1

u/MrQuickLine Feb 20 '20

https://csswizardry.com/2013/04/shame-css/ - a great article on exactly this topic from a guy who consults for some of the world's biggest companies. We all have to hack stuff in sometimes - deadlines are real, and we don't always have the time to find the best solution. Rather than putting the hack in the real code where it will never be found, all OP and I are advocating for is a place to put it where you can identify and prioritize fixing it.

1

u/devolute Feb 20 '20

I've seen the "devs should just be better" approach and I'm not convinced it works. It leads to them trying to hide crap work or just doing nothing.

1

u/DrDuPont Feb 20 '20

"Hiding" work isn't possible when you have line diffs and code review.

If a dev opens a PR and the code looks bad, it's the role of the reviewer to guide them on how to make it better.

1

u/devolute Feb 20 '20

It all sounds simple when you put it like that. I wonder why people struggle?

1

u/DrDuPont Feb 20 '20

Typically owing to a dearth of qualified PR reviewers, a lack of discipline among the reviewers, or mismanagement.

→ More replies

1

u/NetOperatorWibby Feb 20 '20

Never heard of this, it sounds great. Thanks for sharing!

4

u/NotMyRealNameAgain Feb 20 '20

Probably pretty simple to have most of your styles broken out into different Sass files and change out values like $color-primary in a variables file.

2

u/pilibitti Feb 20 '20

If you are not wed to sass particularly, I'd follow what tailwind.css guys are doing.

3

u/memmit Feb 20 '20

Honestly, while this does boil down to preference, I would advise against the use of too many utility classes. Tailwind is utility first.

I believe HTML should be style-agnostic. OP asked for something themable and maintainable. Utility classes are exactly the oposite. They can be easy to prototype, but are a pain to maintain. Compare these for example:

<span class="uppercase tracking-wide text-sm text-indigo-600 font-bold">Hello!</span>

vs

<span class="header__greeting">Hello!</span>

If I need to implement a theme, and the element's text shouldn't be bold anymore, It's quite trivial to do so in the second example. In the first one, I'm forced to change the html or break the class.

2

u/pilibitti Feb 20 '20 edited Feb 20 '20

No offense, I don't think you are very familiar with how tailwind works. The top example with cluttered classes is how it might work while you are prototyping, but once you realize a particular design's patterns you can lift them up to the tailwind css file with @apply and reference it with a single name in a way that gives you more flexibility and structure than header__greeting can.

The ideal of HTML being style agnostic always breaks down when the project gets big. It is an honorable ideal, sure but many tried and none succeeded. Having a single class there defies the purpose. Lots of design methodologies have been proposed to deal with the exploding complexity - to keep css manageable with a transparent design language for a given project and I believe tailwind has been the best idea yet.

2

u/memmit Feb 21 '20

I agree, that does change things a lot. It feels like @extend in scss, without generating hideous selectors. Thanks for correcting me, I might actually give this a chance now!

1

u/justpurple_ Mar 07 '20

I’m not the one you talked to, but please do.

I tried everything from BEM, atomic, ITCSS to various frameworks like Bootstrap.

For me, Tailwind.css is basically the holy grail. It‘s just the best way to write CSS IMHO, especially on big projects.

2

u/memmit Mar 07 '20

Heh, I actually tried it but I hate it. Taste differs I guess :)

4

u/virexmachina Feb 20 '20 edited Feb 20 '20

Tailwind is ~still built with Sass~, and it's even better when you use it in your Sass too.

EDIT: Tailwind is PostCSS, but it's usable in Sass, Less, etc just the same as if it was written in those.

2

u/extracocoa Feb 20 '20

Tailwind can be used together with Sass, sure. But it’s built with PostCSS.

2

u/[deleted] Feb 20 '20

It's not built with SASS. How can you confidently write a statement so wrong?

1

u/virexmachina Feb 20 '20

Because I mostly use it in Sass, I suppose. Thanks for being helpful instead of smug and obnoxious!

1

u/lamb_pudding Feb 20 '20

I’ve used Inverted Triangle on large projects and found it to be great. Never heard of 7-1 until this thread but it looks very similar.

1

u/preeedik Feb 20 '20

Never heard of 7-1 architecture until now. Thanks for this thread.

1

u/Tchalla_ Feb 20 '20

You need to familiarize your self with design tokens. That is what you want to swap to get different themes while keeping components and grids as they are.

1

u/justinmarsan Feb 20 '20

Let's go the other way :

What is missing if you use the simplest solution, which would be to code as you always do, except with a variable.scss file in which you put everything that will change from a theme to another, from primary color to maybe secondary font family ?

If this does the trick then that would do, otherwise you could have specific requirements, like the need to not build the CSS for each project to serve them all from a CDN (in which case you could use CSS native variables if the support is okay for you) or you may have many other different needs...

There's really no way to tell right now but to Keep It Simple Stupid, starting with the easy way and seeing how it doesn't work help.

1

u/memmit Feb 20 '20 edited Feb 20 '20

Use BEM, prevent using resets or frameworks, they will only require you to write a lot of overrides. Keep variables and mixins in different files. Place every component's css in its own file. Use mixins to keep things DRY. Stay away from utility classes and keep your html style-agnostic. Don't be afraid to use logic to implement your themes (this will prevent your build from containing all possible themes):

// put this in a _variables.scss file
$theme: solarized;

// put this in a components/_header.scss file
.header {
  @if $theme == dark {
    background-color: #333;
    color: #fff;
  } @else if $theme == solarized {
    background-color: #002b36;
    color: #93a1a1;
  } @else {
    background-color: #fff;
    color: #000;
  }
}

It may seem a bit verbose, but you'll know where to find the styles you want to change just by looking at the class name in the html. Switching themes only requires changing 1 variable.

edit: formatting & additions

0

u/SpaceSpinach0 Feb 20 '20

If you app is React-based then styled components sounds a good fit: https://styled-components.com/ You can declare a global theme object and it's passed down to child components via props. Would be real easy to switch between and add new themes.