Build single page applications using AngularJS on AEM

© 2015 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential.

Build single page applications using AngularJS on AEMDavid Benge | Lead Computer Scientist


What Is a Single Page Application?

wikipedia:

“A single-page application (SPA), is a web application or web site that

fits on a single web page with the goal of providing a more fluid user

experience akin to a desktop application. In a SPA, either all necessary

code – HTML, JavaScript, and CSS – is retrieved with a single page

load, or the appropriate resources are dynamically loaded and added to

the page as necessary, usually in response to user actions. The page

does not reload at any point in the process, nor does control transfer to

another page”

2


Single Page Application Pro’s and Con’s

Pro’s

Use of page fragments or partials speeds up

the loading of secondary pages

Better mobile device experience

Reduced number of resource requests across

the network greatly speeds up the applications

page transitions

Lack of full page refresh creates a more app

like smoothness leading to a richer user

experience

3

Con’s

Has Search Engine Optimization issues due to

the fact that pages/views rendering is driven

via javascript.

Components and some core libs rely on the

document Ready event to initialize

Speed of the initial load can be slow

Not social sharing friendly. Twitter and

Facebook and others have issues when users

try to share SPA pages.


The Technical Reasons Are Great But Why Did I really Choose To Do An SPA?

4

• The debate on my development team between web and native has

become a religious war. It was time to see if we could get the experience

we want on the mobile experience without building a native application.

• Mobile applications have their place, but I believe a well built site can

convey the same information.

• Informational mobile apps without shared web content create data silos

that make discoverability and interoperability difficult.

• Responsive is a nice start but we wanted to take it further. We are also

experimenting with a concept we call ReDaptive. Watch our GitHub and

YouTube channels for more information in the future on this concept.


Must have native application like smoothness on everything from the

high resolution desktop to the smartphone.

Search and social friendly

Works with AEM authoring

Our development pattern needed to be easy to follow and understand

No JSP; all Sightly

Semantic html markup. Each page should be useable as a data

record based on markup

Javascript needed to be balanced with markup. Avoid 500 js library

include madness

5

© 2015 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. 6

Our Proof Of Concept Combine sling with Angular


• Custom base page component that allows pages to be either an Angular application

entry point or rendered as a view partial

• Angular JS code to control the application/site and its view navigation

• Rewrite rule to help handle search engines by adding a selector

• Based on runmode Base Page includes content or an Angular ui-view element

• Responsive design

• Custom video component that makes use of Adobe Dynamic Media and native HTML5

video tag markup. Selects best rendition to use based on the video element size and

browser device group detected

• Use of BrowseCap for device detection

• Nearly all Sightly

• Use of Less for style

• Adobe Analytics for metrics

• Uses AdobeAtAdobe boiler plate project - Available in our GIT repo

• Creative Cloud Extract used to build site from XD comps

• Photoshop used to develop the comps

• Adobe Edge inspect used to debug on devices


High Level Technical Overview Of The Base Page Component

We created a standard page component that inherits from wcm/foundation/components/page.

This new base page component has a content.html include in the center. This is where our page views get loaded. We change the markup based on if the request was made on a publish or author environment.

If the request was on author we do a standard content include.

If it’s a page request on publish we don’t do the include and just insert the div with the angular ui-view

<div class="page-content" ui-view data-sly-test="${teamsitePage.isPublisher && !teamsitePage.isSearchEngine}"></div><div data-sly-include="content.html" class="page-content" data-sly-test="${!teamsitePage.isPublisher || teamsitePage.isSearchEngine}"></div>

In the base component we also include some meta data. We use this to tell angular and other components how to behave based on the environment.

<meta name="publisher" content="${teamsitePage.isPublisher}"/><meta name="wcmmode" content="${teamsitePage.metaWcmMode}">

8


High Level Technical Overview Of The Standard Page Component

All the pages inherit from the

base page

Each new page component

includes their markup in a file

named content.html

If needed they can include a

controller like in this example

The controller code is stored in a

client lib under the page

component

9

<div class="contact-block" ng-controller="ContactController">

<div class="hi"><span>Hi. </span>How can we help you?</div>

<div class="methods">

<div class="method">

<div class="title">Technology Questions</div>

<div class="phone">+1 613 857 9233</div>

<div class="email">[email protected]</div>

</div>


<div class="title">Work with Us</div>



</div>


<div class="title">Everything Else</div>



</div>

</div>

</div>

</div>


High Level Technical Overview Of The Base Page Component Partial Selector

Under the base page component we have a file named partial.html.

This file handles any request for a page that has the partial selection

appended to it. This file simply includes content.html with No header,

No footer, No navigation, just the meaty center of the view in our case.

The partial also includes new metatags with data to replace the

header meta data. The new tags are prefixed with partial for example

partial:title. Its contents will replace the header metatag’s content for

title. The replacement of the metadata is handled by the Angular

application.

<meta name="partial:keywords" content="${head.keywords}" id="partialKeywords"/>

10


High Level Technical Overview Of The Base Page Component Partial Selector

We need to tell Angular about the site hierarchy because Angular will be

handling navigation from view to view. Angular controls the view

loading on the client side via a library called router.ui so it needs to

know how map urls to view partials.

Under the base page component we have a file named routes.json.jsp.

This file provides us a endpoint for Angular’s ui.router to use to load the

router and state provider on the fly on the first page load. One thing we

do alter on the routes is the value of the templateUrl returned from our

routes.json.jsp. On our page path we include a partial selector. Thanks

to the magic that is sling when we make that request now we will get

just the center conent of the page when we navigate from view to view.

11


High Level Technical Overview Of The Base Page Component Angular Router

12

Example output from our routes.json.jsp file is

shown to the left.

This is an example of how we are rewriting out our

routes and re-writing the templateUrl to include the

.partial selector.

Example /content/teamsite/work.html

becomes

/content/teamsite/work.partial.html

When the application/site is loaded in the browser

any link or navigation to a url for example

/content/teamsite/work/cmo.html is handled by the

$location service. It will resolve the url to the

templateUrl which is set to

/content/teamsite/work/cmo.partial.html.

The request to

/content/teamsite/work/cmo.partial.html will be

returned as just the center of the view and injected

into the existing page.


So Far This Is What It Looks Like On The AEM Page Component Side

13


High Technical Overview Of The Proof Of Concept – Component Conclusion

So that’s it for the AEM side of the application. Once the base component pattern was established it was easy to work with.

Its all fairly normal AEM component and page development from that point on. With a few exceptions for stock components that make heavy use of the document ready event.

Summary In author runmode, it will do full page refreshes

Search engine friendly due to the fact there is a full page request

On social shares of a page, the path exists

In publish run mode, the client side will do partial page refresh

Thanks to the magic of sling resolution we are able to serve full pages or partials as needed. Every path can be an entry point to our SPA base application.

14


The Angular Bits


The Angular Js bits we used to round out this solution are:

Controller – Controllers ended up being minimally used at the page level. Router.ui – used to load and control the routes. We also use the routing events to load page meta data

Service – We have a service that helps with pulling and setting meta data on the page

Directives – We have a few to provide functionality

Custom html5 video player directive

Explore page directive to help with the scrolling and other ui bits on the explore page

Angular Carousel which drives the image carousels

16


Whats Next?

17

• We will be adding more functionality to the proof of concept

site

• We are really liking directives and plan to do more work in that

area and investigate using polymer

• Clean up of the header libs to remove some of the

dependency on document ready event


Code is located in out Github repo https://github.com/AdobeAtAdobe

Live site can be found at http://www.adobeatadobe.com

Twitter @AdobeAtAdobe

Video sessions on this proof of concept will be posted on

our YouTube channel https://www.youtube.com/user/AdobeAtAdobe

Date post:	10-Aug-2015
Category:	Documents
Upload:	connectwebex
View:	100 times
Download:	3 times

Build single page applications using AngularJS on AEM

Documents