Most web pages share pieces that are reused throughout the entire site. While I’ve heard them called different things, I prefer to call them components. Some examples include the header, footer, main navigation, logo, slideshow and so on. Most of these can be broken down into smaller components as well. For example, maybe the header is a specific layout that includes the main navigation and the logo. For more information about component based approaches to web pages check out our blog series on components as well as Brad Frost's Atomic Web Design.
In this approach files are organized by type and finding anything requires a “grep” or a “find in folder”.
Page Based Approach
This is a similar approach to the legacy approach but here we’ve split our styles necessary for different pages out to their own Sass partials. While this helps to some degree, what do we do about styles that are shared across pages? What about that hunking scripts.js file? What can we do differently to better organize our components?
Ian Feather has a fantastic article where he advocates grouping files together by component instead of file type. I also really like this React Boilerplate application structure conversation which discusses a similar approach. In Drupal 7, something similar wasn’t really possible but in Drupal 8, twig and Drupal libraries can get us closer. There are still some gaps *cough forms* but in general centralizing components is much easier.
Component Based Approach
Whoa. A lot just changed. Let’s step through each modification.
Moving files into dist and src directories.
Separating the compiled files from source helps a new front end developer to easily know which files they should modify and where they should add new stuff.
Within our theme root, on the same level as our src and dist directories, we now have our main .yml files:
The theme will not work if these files are within the src directory.
Our src directory contains the global scss and js used on every page of our site. This global folder also contains any Sass variables and configuration that isn't component specific. We also have our template directory which holds all our Drupal twig templates, the same as the previous approaches. Drupal will not find any twig files unless they are within this directory.
Lastly, we have the meat of our src directory, the component folder. Here you find each component within its own folder and any relevant Sass, JS and markup (twig). What’s not shown here is that each component name should be reflected with the CSS classes used to style the component. I.E. if the component is named “Super Slider” the CSS class used should be “.super-slider.” This makes it super easy to find and modify any component. For example: find any component you want to modify within the browser. Right click, inspect element to bring up the web inspector. Check the class name and find that name in the components directory. Everything you need to modify should be there.
Wait didn’t you just say “Drupal will not find find any twig files unless they are within the template directory”? Yes, yes I did. To bridge the gap between the markup within the component and the markup that Drupal is looking for we include one from the other.
This includes the component markup at src/components/teaser/teaser.twig with the variables from node--teaser-full.html.twig. This approach allows us to keep the markup with its respective component and provides a single source of truth for that markup.
Bonus: Check out https://www.drupal.org/project/components if you want to use twig namespaces like “@component_based_theme”. This keeps you from having to type the entire path.
What’s not shown in the above example is how we’re leveraging Drupal libraries to let each component load its own assets. Whenever we add a new component, we add a new library for that component within component_based_theme.libraries.yml. Inside the component’s twig file we use attach_library() to make sure the library is attached whenever the twig file is included. This means by default only the JS and CSS needed to render the loaded page should be loaded. Goodbye all.js and all.css.
Wait, I hear you say, what about caching the requests? Good question, your approach may vary depending on use case. I prefer to trim down the initial page load as much as Drupally possible. Drupal also splits the CSS aggregates into “all” and “dynamic” so at least the “all aggregate” is the same for all pages.
One of my favorite parts of Drupal libraries is being able to declare dependencies on other libraries and letting Drupal sort the loading out. For example, if we have one component that depends on other smaller components we can do something like this:
This would ensure the CSS and JS load order is:
Component organization in Drupal is still in its early days. To read more about the conversation around components in Drupal core check out this issue. That said, while there are still some loose ends we need to tie up to have a true component based approach, Drupal 8 gets us farther than before.