Clientlibs - Approaches and Best Practice - Wed

CLIENT SIDE LIBRARIES Approaches and Best Practices … and some ideas

WHY ARE WE DOING A TALK ABOUT CLIENTLIBS? Hard to get right with the component based nature of AEM Area that is ignored – “just get the CSS in there” Front-end developers often don’t get a say in how its integrated in AEM – can miss out on some common front end best practices Have seen a lot of different implementations – pros & cons

WHO IS THIS TALK FOR? Architects, Developers

• The different approaches to clientlibs for greenfields projects • Existing projects – critical thinking so you don’t compound the problem • Show you how we think it could be done better taking ideas from Angular

Front-end Developers

• See how AEM handles your HTML / CSS so you can be more effective

Product Owners • Make sure your team are thinking critically about this so you don’t have bugs later on

WHY IS IT IMPORTANT? JS & CSS – can quickly become large and complex if ad-hoc approach is taken Large amounts of JS on a page can slow it down and increase bugs Only JS that is used on a page should be loaded Unstructured CSS – recurrent bugs that will drive clients and front-end developers crazy Structured approach results in more maintainable and performant solution – avoid introducing bugs in the first place

WHAT WE’VE SEEN One gigantic clientlib file THE GOOD

THE BAD • Hard to debug

• It’s cached in your browser • Fewer HTTP requests

• File size can become large – creating problems for older browsers • JS / CSS exist on the page even if your components do not (introducing bugs) • JS needs to be written carefully to ensure it only runs when related components are on the page

WHAT WE’VE SEEN

One clientlib per template Often used as it seems this is how the AEM clientlib system was designed to be used THE GOOD GOOD THE • Easy to include on the page at template level • Makes sense if your website has a reasonable number of templates and strict components on each page type • Still cacheable per template

THE BAD THE BAD

• Re-usable components need to be included in multiple templates – duplicating JS • Many projects don’t have strict templates – end up with either heaps of templates / clientlibs or small number of templates using parsys • JS needs to be written carefully to ensure it only runs when related component is on page

WHAT WE’VE SEEN Components include their own clientlibs THE GOOD • JS / CSS can live with the component JSP or Sightly code – neat & tidy • JS & CSS only included if component is actually on the page

THE BAD • Can get to be a lot of clientlibs. • Requires extra effort to combine and minify clientlibs to keep HTTP requests down. • As /apps isnt accessible on publishers, need to anchor all clientlibs in /etc anyway

TYING THEM ALL TOGETHER Best practices can be dependent on project requirements – a combination of different approaches can often work well Keep the JS/CSS modularised together with components. Group common JS / CSS together into functional areas that can be included at a template level with embed tags. Separate complex component clientlibs and load individually for easier debugging. One big clientlib for trusted 3rd party minified libraries Debug with &debugClientLibs=true

MODULARISING JS WHERE POSSIBLE Modularise your JS code where possible Less code / more reuse Faster development if you can re-use functionality in an already tested module Example – MockableController

TIE JS TO MARKUP ANGULAR STYLE! Learning from concepts of AngularJS Multiple of the same components on a page – how do you target your JS to the correct component? Associate the JS and HTML Defined scope to the component element Example – Show More Text example

ANY QUESTIONS?