Long gone are the days of “page-centric” design! “What will you put on the “Services” page?”, “How will the "Portfolio" page look like?”, “How many pages will the website have in the end?” etc. It's time you got off this beaten path of “waterfall design” and adopted a more agile way of carrying out challenging, complex web projects. It's time you leveraged the component-based approach to UI design by breaking it down into small, easily identifiable, purpose-carrying puzzle pieces/components (instead of breaking it into key pages)!

And it's pretty ironic:

 

• while this new front-end development style encourages collaborative flow between all teams involved (UX, design, front-end, back-end)
• its key benefits are that it “unchains” front-end developers from the need to get tangled up in the Drupal back-end system, with all its specific “quirks” and its theming language
• and that it “frees” back-end developers, too, from digging into the complexities of a JavaScript front-end system
   

A win-win situation translating into rapid front-end development!

 

But What Are "Components" More Specifically?

Take them as “clusters” of... things on a page. This would be the most rudimentary definition of “components”!

In the traditional waterfall approach to design websites used to be perceived as... infrastructures of pages!

Well, the component-based approach calls for a mind-shift: to think of websites as “systems of components”. Component parts which can be easily found across the entire user interface, and which can be easily put into some front-end templates.

Now if I'm to elaborate my initial basic definition of “components” I'd say that a component is:

 

• a “concept” (a footer, a header, a content listing)
• a “cluster” of similar bits of codes (CSS, JS, HTML) grouped together by a domain language criterion (not by their file extensions)
• a display element isolated from the other “clusters” on the page (which makes it so much easier for developers to create and maintain them)
• a distinct component part on a page named based on the domain language of that specific project; this way a shared language is provided and it gets crystal clear to front-end developers, back-end developers and to clients, as well, which is the purpose that each component should fulfill
   

The Waterfall Model vs The Component-Based Approach to UI Design 

I'm not going to beat around the bush here since the traditional waterfall approach to design is more than familiar to all of us:

 

• each team gets its “slice of the pie/of the project”
• each team gets focused exclusively on its “slice”
• and when they get their work done
• their output is passed on to the next team included in the development cycle and so on
• till it gets to the back-end developers who need to implement the design and... God forbid they should change it in any way!
   

Well, once you implement the component-based approach into your workflow expect to:

 

• invest more time, at the early stages of your project, making sure that all teams gather to understand each component's functionality
• have all your teams working closely throughout the entire development process
   

In short: expect to “inject” agility into your web project's development process from its very early stages.

Note: unlike with the conventional waterfall model, this new agile approach to development enables (and encourages) front-end developers to collaborate with the design team from the very start!

 

The Component-Based Approach: Introducing Living Style Guides

Building an efficient style guide is crucial for your project's success when you're leveraging a component-based approach to UI design!

Practically your living style guide:

 

• is all teams' “meeting point”
   
• is a tool displaying each component part of the interface as a static page
   
• is a tool useful for breaking down your UI into its component parts and for showcasing your front-end team's output both to the other teams and to the client himself
   
• it enables your client to scan through and to see how components, taken separately, would work on several devices
   
• it enables front-end developers to focus on their work without worrying about how their design system will eventually get implemented in Drupal by their back-end co-workers
   
• it creates the proper “context” for an agile, accelerated development process: developers get to use style guides for “detecting” existing patterns and for easily “bundling up” small sized elements to create larger sized ones (instead of creating brand new ones each time the client asks for a new feature)
   
• it makes a great shared resource for all the new developers and new designers who might start working on the same project along the way
   

“But why “living” style guides?" you might ask yourself. Keep on reading...

 

Integrate Your Style Guide Into Your Drupal Theme

This is where Drupal developers' “mission” to connect these two systems comes into play!

1. The Challenge

So now the back-end team has to copy the style guide's code and to paste it inside the Drupal theme. Yet, this will only open a “Pandora's box” since:

 

• duplicated code becomes inevitable
• keeping your style guide “intact” throughout the development process gets so very unlikely
   

Therefore, it's vital that your back-end development team “injects” your style guide and CSS precisely into the right part of your Drupal theme. So that both templates should share the same code!

And this is what sets apart a “style guide” from a “living style guide”: the latter gets referenced right from your Drupal site's theme system! 

2. Two Ways for Integrating Your Living Style Guide Template Into Your Drupal Theme

Back-end developers within your team get two methods to choose from:

 

• the integration via the Drupal's theme function 
• the integration via Twig 
   

Notes:

 

• the component-based approach “bids” on a separation of concerns: since component parts are actually “clusters” of similar bits of code, it gets much easier for developers to reason about them
   
• since all the elements of a specific component get grouped together (JavaScript, CSS, markup tc.) into folders named after the component itself, moving them from the style guide template into the Drupal theme's template turns into a streamlined process!
   

Wrapping Up

 

• a component-based approach accelerates all the development processes (not just the front-end one) by creating the proper context for reusability
   
• this new front-end development style eliminates the risk of ending up with a too heavy load of stylistic elements
   
• front-end developers don't need to invest valuable time into learning key aspects of Drupal and the Drupal theming system first, which would force them to postpone their actual work inside the design system
   
• it allows for teams of highly specialized front-end developers to be welcomed on board and the usage of the latest tools: Yarn, Webpack etc.
   
• front-end developers get to write their front-end code faster and without worrying about its implementation into Drupal (that's strictly the back-end team's aspect to “worry about”)
   
• designers are “freed” from the old constraints, they no longer need to comply with the “designing for a Drupal site” rules
   
• back-end developers get to focus on integrating the style guide templates into Drupal and are freed from getting themselves “tangled” up in JavaScript design complexities
   
• the Drupal theme's template and the style guide's template are the same: whenever the living style guide gets updated, the Drupal site's theme gets automatically updated, as well!
   

So, do you have the courage to move away from the waterfall model? To adopt a new way of developing user interfaces?

---