< Return to Feed
Aaron Smith

Thinking in Components - Better from Front to Back

With the advent of large-scale, component-based CMSs like Sitecore and Adobe AEM, back-end development teams have had to adapt to developing with the idea of reuse in future development cycles in mind. Likewise, the front-end development teams that work with them should adapt to the changing development landscape when developing for a CMS. The increasingly widespread practice of component-based development across teams helps ease the transition of code between development specialties, previously one of the most challenging and time-consuming tasks in a development life cycle. By rethinking the way that front-end development teams work, we can help increase developer productivity, ease unit testing and debugging, and substantially reduce impact on timelines and budgets.

Out with the Old: Page-Based Development

Using a page-based development approach tends to hinder the development life cycle in a variety of ways. The process would begin with front-end developers creating full-page templates based on the approved creative, and back-end developers would have to sift through documentation to accurately determine the beginning and end of each individual component. This lapse often led to elongated timelines, communication issues, and additional back and forth for both parties, but more often the majority of the time-consuming documentation discovery burden falls on the back-end development team.

In with the New: Component-Based Development

Using a component-based development approach enables iterative, agile development throughout the project lifecycle. This ideology allows developers to work side by side, creating back-end integration with large scale CMSs like Adobe AEM or Sitecore, and letting the front-end developers take over, compose, and polish the components afterwards. This improved, parallel teamwork strategy offers the benefit of  continuous delivery and iteration without the blocks of a turn-based development strategy.

thinking in components 3

Figure 1: Component-based html folder structure in AEM.

The Front-End Use Case

Implementing reusable components helps keep design consistent and can provide clarity in organizing code. By using a well-thought-out html component structure, the development teams are provided a clear use case for each component without the issue of scoping or miscommunication. Each of these front-end pieces should be independent, clearly defined, encapsulated, and above all, reusable. For consistency, frameworks such as Bootstrap should be utilized for their rigorous testing and widespread knowledge libraries. These highly regarded frameworks integrate well with component-based sites, and observe formats that can be easily interpreted by anyone with a background in development.

Quicker Updates with SASS

A set of well-organized Syntactically Awesome Style Sheets (SASS) adds to the component’s ability to be updated quickly, and allows for more confidence in those areas which will and won't be affected. Placing appropriate mixins, extensions, and variables related to a component in the same location as the component styles can lead to a better organized and clearer style architecture. As with the HTML structure that they style, each of these SASS files should be completely independent and reusable. This will allow for more global styles, such as fonts and colors, to be imported without the fear of disrupting a component’s style or functionality while adjusting another.

thinking in components 4

Figure 2: Example of component-based architecture illustrating proper use of SASS extensions.

Meet the Future: Component-Driven Architecture

Currently popular and emerging web technologies are favoring component-driven architecture. Using what is currently available, as front-end developers we can improve the development cycle of all CMS projects and work towards the future of our discipline. Whether this skillset is leveraged against Javascript frameworks such as React or Angular, or the emerging Web Component specification, we have the ability to not only shape the way we develop, but change the mindset of the teams within which we work.

< Return to Feed