At DrupalCon, I held a session about the organization of partials. @johnalbin and @sungug were kind enough to make an appearance and impart some of their wisdom with the Drupal Community of how they do partials. In this article I will discuss their methods, as well as mine, for doing partial layouts in the Drupal sphere.
What are partials?
Partials are SCSS files. That is it. But when done right, partials can also be self contained bits of code that pertain to the overall design of a site. The point of partials is to break apart a design into maintainable sections of code that help future proof your SCSS from 135,000 overrides by people who are not aware of the system or do not care to ctrl+f a big f-ing stylesheet.
Breaking up Partials
During the discussion, it seemed that all 3 of us, and the community agreed that a partial file should be named after the top level selector. For example if you are calling .messages, your file would be _messages.scss. This allows for people to quickly find files based on the selector that was used, and does not require the use of the dirty output of debugging. This if further critical in production when debugging can bloat a file to 3x the aggregated single line.
However, that was about where the agreement dropped off to some level with the organization of partials.
Partial Organization
Below I will discuss the organization of partials as I understand them through the discussion that was held at the BoF.
Snugug’s approach
Sam Richards, @snugug, is the maintainer of the standards document North the document helps to create a standard
for the frontend. His approach in North, and in working practice is to create a “design” folder and from there, he creates static html to match the comps and design. Using this static html, he will generate a folder called “messages” in the folder and a file at that same level called _messages.scss. And inside messages he would have a, _variables.scss, _mixins.scss, and _extends.scss. _extends would house the design for the component and any extendables/silent placeholders.
Snugug’s Folder Structure:
Layout
|_ _layout.scss
Global
|_ _global.scss
|_ _functions.scss
|_ _mixins.scss
|_ _variables.scss
|_ _extends.scss
Design
|_ _design.scss
|_ _messages.scss
|_ messages
|_ _extends.scss
|_ _mixins.scss
|_ _variables.scss
|_ and so on ...
The benefit of a system like this is that all the parts of the partials are contained to a folder with the parts. This system also allows for the html to be honed specifically to your desires and the needs of the system. This means that your system and theme can almost be Drupal agnostic. Allowing for portable designs/themes.
John Albin’s Approach
John Albin is the creator of Zen and the lead of the Drupal 8 mobile initiative. John Albin while at DrupalCon did a session that discussed the use of design components. Using these methods, he discusses how to breakout a website into simplified maintainable parts. Then from what he said in the BoF, it would seem that his folder structure would be similar to this:
JohnAlbin’s Folder Structure:
Layout
|_ _layout.scss
Global
|_ _global.scss
|_ _functions.scss
|_ _mixins.scss
|_ _variables.scss
|_ _extends.scss
Components
|_ _components.scss
|_ _component_0.scss
|_ _component_1.scss
|_ _component_2.scss
|_ and so on ...
While this could keep the number of folders light and the nesting shallow, it would seem to lead to a very bloated components folder that would be hard to search though visually. Also, depending on naming convention, it could also be
difficult to on-board someone onto a project (frontend, backend, sitebuilder), while having them understand the flow of the components. However, this is a good structure in the sense that it would ideally keep the SCSS maintainable and reusable across different systems.
NEWMEDIA’s/My Approach
Here at NEWMEDIA we have a more similar approach to that of Sam Richard where there is a nesting of folders, but we believe in the semantics of the Drupal system and origination of the content and markup on the page. This ties our themes intimately with Drupal because our theme is now dependent on Drupal but it also helps our system maintainers understand where the components are in the structure of partials and the site since they can be one in the same.
Our partial structure is as follows:
Layout
|_ _layout.scss
Global
|_ _global.scss
|_ _functions.scss
|_ _mixins.scss
|_ _variables.scss
|_ _extends.scss
Styleguide (This folder is based of the styleguide module and sections)
|_ _styleguide.scss
|_ _text.scss
|_ _forms.scss
|_ and so on... (see http://github.com/timodwhit/bare for full breakdown)
Design
|_ _design.scss
|_ blocks
|_ _blocks.scss
|_ views
|_ _views.scss
|_ view_name
|_ _view_name.scss
|_ _view_id.scss
|_ _view_id_1.scss
|_ user
|_ _user.scss
|_ _user_login.scss
|_ and so on...
|_ node
|_ _node.scss
|_ node_type
|_ _node_type.scss
|_ field
|
|_ _field_id.scss
|_ and so on...
Now, at first glance, our tree is evidently more complex and can seem more convoluted, there is also the issue that what if you have a field on a node which is being output by a view in a certain region, etc. The complexity of the structure, should not be a barrier since Drupal is a complex system that generates complex information, with this is mind, we are imparting the same logic that Drupal uses (for better or worse) and applying it to our theme. The generation of content through
different systems is a valid concern, however if we think of the content as reusable pieces of information, i.e., a field, we begin to see that we have design components already laid out in-front of us.
Overall
The large difference between systems is whether or not the design and the partials can be used outside of Drupal. JohnAlbin and Snugug’s approach can almost be used outside of Drupal, while our approach is very tied into Drupal. There are benefits and drawbacks of each system.
I believe that each system has its merits and its draw backs. However, I think it boils down to two different camps are present in the community: web purists and drupal purists. Web purists want very specific markup that deuglifys the Drupal Dom, while Drupal Purists don’t mind (and possibly enjoy) the Drupal Dom. If you are in the first camp, write custom markup, bend the Drupal system to your will and override everything for your precious markup. And if you are in the second camp, build your site logically so that you design components are stable and reusable in the system, it will help in the long run. Idealistically, both camps can merge in D8 and have a pretty frontend and a beautiful simple backend that doesn’t require umpteen overrides.
I think every camp can take away things and always keep learning. So feel free to post your structure and discuss in the comments!