nice article, where would ideas around utility classes like the system that basscss has created fit into this type of architecture? the main reason is i find that a lot of view-specific styles contain basically minute tweaks and layout adjustments and spacing that could easily be solved with a well-defined utility class system, and how would that be maintained separate from things like patterns? i imagine they might live somewhere between /base and /patterns but would love to hear your thoughts.
also, if at all, would this type of styling architecture change if you're using a more modular front-end system like react?
Utility classes come down to personal preference. I find myself not using them (mostly) because it is hard to work in responsive behaviors without doing things like
If you were to use utility classes, I would imagine they would take the place of
/views. Since you would probably be overiding styles previously established, they would need to be at the end of the chain. That assumes you want your utility classes to overpower a particular component/pattern.
As far as using these with a tool like React, it totally works. Often times you end up with a modular front-end system, you just end up with a loooooot of components in this flat structure, which totally works. Then it's just up to making sure your components have strong naming conventions, and you're good to go.
TL;DR basically ITCSS
Those monkeys look like a penis.
EDIT: But in all seriousness (although I feel like the artist went out of his/her way to make them look like that), I feel like this is a fine structure, but two things stand out to me.
One is including mixins in
/base. This differs greatly from almost all projects I've worked on, where there is a clear differentiation between base styles (i.e. as the author mentioned, the base HTML elements) and mixins. I would recommend having a
/partialsfolder, where the non-rendering SCSS, such as mixins or variables, lives.
The second thing that stood out to me, and this is more minor, is
/patternsdue to both its name and the fact that it could very well be combined with
Let's say I have some fancy
.buttonstyles that I can apply to faux-button
<button>elements. That, as well as its variants (
.button-disabled, etc) should be in some sort of
_buttons.scssfile and I can go in there and learn about all the options.
If I have some fancy styles for a radio button that requires the
<input type='radio'>be wrapped in a
<div>with a specific class, to me, that still belongs in your components, just with some comments at the top of the file being like...
// Usage: // Add 'super-cool-radio' class to containing <div> // // Example: // <div class='super-cool-radio'> // <input type='radio'> // </div>
That way you don't need to have yet another folder (as your project grows, you might need more folders), and whether an elements just needs a class or maybe needs a bit more markup, the documentation will cover it.
Also, document your stuff.