4 comments

  • Win LinWin Lin, over 5 years ago (edited over 5 years ago )

    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?

    1 point
    • Will H McMahan, over 5 years ago

      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 .small-screen-only-padding-left-something-something.

      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.

      0 points
  • Simon EvansSimon Evans, over 5 years ago

    TL;DR basically ITCSS

    0 points
  • Dan CortesDan Cortes, over 5 years ago (edited over 5 years ago )

    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 /partials folder, 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 /patterns due to both its name and the fact that it could very well be combined with /components.

    Let's say I have some fancy .button styles that I can apply to faux-button <div>s, or <button> elements. That, as well as its variants (.button--warn, .button-disabled, etc) should be in some sort of _buttons.scss file 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.

    0 points