Anda di halaman 1dari 11

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 dont 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 dont 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 dont
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 WEVE SEEN


One gigantic clientlib file
THE GOOD

THE BAD
Hard to debug

Its 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 WEVE 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 dont 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 WEVE 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?