That's entirely alright just experiment with the modular paradigm presented by 7-1 architecture.You may have heard of pre-processing of CSS and wonder what all the buzz is about. In fact, maybe you'll only need three or four. Depending on the size and scope of the project, you may not need all 7 directories. Moving forward, we'd like you to try organizing your own Sass projects into multiple directories and files, similar to structures seen here. In this case, we'd just omit those directories from the sass folder entirely. For instance, some projects may not use third-party stylesheets. One more thing: despite being called "7-1", note that not all of the 7 directories are always required. You're also encouraged to 'star' this repo on GitHub for future reference.
Each directory has its own README that offers further tips and advice. Hugo Giraudel, the same individual who developed this 7-1 architecture, also has a sample boilerplate repository available to explore this structure here: Sass-Boilerplate. In the 7-1 architecture all styles live in an appropriately-named partial, and are simply imported into the input file. Sass/main.scss 'themes/admin' īut notice there are no styles defined directly in the main.scss input file. An option like this would be represented in its own theme file too.Īll files from all of these subdirectories are then imported into the main.css input file, in the order listed above, like so: Some websites also offer a "night mode", where the background of the site is darker with lighter-colored text for easier reading in low-light environments. Perhaps to better present and accommodate the additional features an Admin has. We can therefore assume this example site is styled entirely differently for logged-in admins. For instance, the example project above includes both admin and default themes. Themes is used whenever a site has multiple themes. For instance, if a project contained several style rules that are only ever used on the "Contact Us" page, they'd live here in a _contact.scss file, as seen above. Pages is where page-specific styles reside. Styles for small, reusable pieces of the site should reside here (think buttons, forms, profile pictures, etc.) Layout contains styles for different aspects of the site's structural layout (think of areas like nav bars, headers, footers, etc.)Ĭomponents are like "mini" layouts. This includes project-wide typography styles, and stylesheets that universally reset or normalize default CSS. For instance, if we wanted to use Bootstrap alongside our own custom Sass in a project, we'd download the Bootstrap stylesheet and place it here.īase contains boilerplate used throughout an entire si te. Vendors contains any third-party stylesheets a project uses. Each of these categories should be placed in their own appropriately-named partial file, as seen above. This includes things like global variables, functions, and mixins. At the top-level of the directory is a single main.scss file (this is the input file) and seven subdirectories:Ībstracts contains no actual styles, just Sass mechanisms that help define styles in other directories (sometimes called "helpers"). | |– _contact.scss # Contact specific stylesĪs we can see, everything is in a big sass directory. Here's an example sass directory from a project structured in 7-1 architecture, as depicted in the Sass Guidelines article mentioned above.
So let's make sure you're familiar with it before moving on! Examples If your internship or eventual place of employment uses Sass, there's a high chance they use some variation of this type of architecture.
One popular and effectively modular way to structure Sass projects is the 7-1 pattern. But organization is crucial in the wild, where we're no longer dealing with single static pages, but large applications comprising many moving parts. Keeping the architecture consistent and meaningful is even harder.Īt first glance it might be difficult to appreciate the usefulness of Sass while coding such small daily projects. As Hugo Giraudel states in Sass Guidelines:Īrchitecting a CSS project is probably one of the most difficult things you will have to do in a project’s life. And sometimes those standards even vary between projects. Different developers, teams, and companies all have their own standards. A natural question at this juncture is: “Okay, if I'm going to start breaking up my styles into multiple files, how do I organize them? What is the proper way to structure my project?” Unfortunately, there are no universal, official-endorsed best practices for this.
0 kommentar(er)
