Building a Single Page Application with AngularJS and Sitecore: Part 2

In the second and final in a series of posts related to AngularJS and Sitecore, we’ll explore Angular in a Sitecore context. By running Angular within a Sitecore instance, we’re pairing the speed of Angular with dynamic rendering of Sitecore, opening our discussion to multiple interesting scenarios.

SPA Integration with Sitecore

Suppose we want more than just Sitecore content in our SPA, we also want Sitecore renderings. Our previous example ran as a SPA with a direct line to Sitecore by way of the Sitecore Item Web API. Building on the previous example, lets now have the start page of our SPA as the home item of a new Sitecore site within our instance. We’ll then define content which lets us:

1. Use renderings for content outside of our views (static content for all pages across our SPA).
2. Use Sitecore items as views in our Angular routing.

Note: Since we’re building off the previous example, we’re still using the Sitecore Item Web API. This could easily be changed to other methods, such as directly serializing objects to JSON.

Looking at Sitecore, this is our configuration:

1. Callouts – Ads displayed below our Angular views (labeled as “Heading Callout” above).
2. Profiles – Data returned by our Web API calls.
3. Views – It’s here where we’ll be swapping out our Angular views for Sitecore items.

Looking at the presentation details of our views, you’ll notice they don’t have the default layout used by our SPA, as this would cause a nested default layout effect within our application. Instead, we define a “PartialView”.

The ParialView layout paired with an allprofiles rendering essentially makes this the equivalent of the allprofiles view in our previous example. The difference, however, is now our views are powered by Sitecore. We can insert other renderings, content, etc.

PartialView Layout:

The only change required is to wire everything up. We can do this rather easily by altering our routes to now point at our Sitecore views instead of html files on the file system. Since we’re in the context of a Sitecore instance, Sitecore properly handles the request serving only the content for the views requested.

Technical Considerations

Caching

Angular is fast because only specific areas of the DOM are manipulated, but we have to be aware of caching issues. Any personalized areas of content or special rendering rules may very well be ignored.

When publishing updates to our views, we want to be sure we’re getting the latest and greatest version. We can force the application to reload views by appending the item version number as a query string parameter to our view. This will force a refresh through our routing.

DMS/Tracking

Out of the box configuration, DMS will track with every page request. Since our SPA remains on the same page for each request, we’re not going to be actively tracking each action by the user. Of course, we could implement a solution where we’re firing client-side events to our DMS solution.

Page Editor

Simply won’t work. Manipulating content or rendering placement within the SPA is not possible through the page editor.

Workflows

Tests using basic workflows failed on HTML validation. The extra Angular directives caused failures upon attempting to submit for approval.

Views in Sitecore Content

Our views are publically accessible with a PartialView layout. We want to be sure these don’t make their way out to be indexed, as they don’t have a full page layout associated with them. We want to be sure these are not crawled and no pages link back to these outside the context of our SPA.

Just Because You Can, Doesn’t Mean You Should

While we all love to push the boundaries of what Sitecore can offer and building solutions while incorporating other technologies, it’s important to be aware of the pros versus the cons. Building a SPA within the context of a Sitecore instance, while an interesting discussion, may bring about more issues than problems its solving.

For me at least, if someone were to suggest a similar approach, it would have to be quite convincing. In almost all cases, all we’re going to need is access to Sitecore content. If all you need is content, you may want to take a different route (no pun intended).

Alternate Approach: Angular Views in Sitecore

If all we’re after is Sitecore renderings used in conjunction with Angular, why not simply use Angular views? Why add the complexity of a SPA, if we can achieve our goal by building dynamic forms with Angular. Using Angular views, without Angular routing, we now regain control over the issues listed above under Technical Considerations.

Conclusion

Walking through each of these posts and scenarios using Angular in a Sitecore context was fun. I encourage anyone interested in using Angular to take into account all points covered in both posts. Hopefully these experiments assist the community and other developers looking to leverage Angular in future projects.

For the complete solution, including routing, Sitecore field mappings and all views and controllers, go here: https://github.com/PetersonDave/SinglePageAppDemo/tree/with-sitecore-integrated.

Building a Single Page Application with AngularJS and Sitecore: Part 1

During the November meetup of the Philadelphia Area Sitecore User Group, we explored the possibilities of using Angular with Sitecore. Two options were explored. The first, building a SPA with Angular and Sitecore Item Web API and finally, Integrating Angular into a Sitecore instance. This post, the first in a series of two related posts, discusses the Sitecore Item Web API implementation.

SPA with Sitecore Item Web API

Building a Single Page Application where we need content from Sitecore, the Sitecore Item Web API is a perfect option. We’re able to access our Sitecore instance via GET requests, obtaining Sitecore items serialized as JSON. While adding a dependency on our SPA, we can contain the dependency as single point of entry and distribute the content across view models.

In our SPA demo site, we use an Angular factory as the entry point into our Sitecore instance by way of the Sitecore item Web API. Angular factories allow us to obtain data and reuse it across multiple controllers and routes. The data is saved in an array through get() and made available via getProfiles():

Note: For this demo, the get request is calling the current site, as the current site is running as the Sitecore instance. This can easily be changed to a non-relative URL path.

The factory, profileService, then serves content to our controller allprofiles. There are two methods to take note of here.:

1. vm.load() – Makes the GET request to our Sitecore instance, populating the profiles array within our profileService.
2. populateRepository() – Our callback method which profileService calls upon successfully loading profiles from the Sitecore Item Web API. A repository property of our model is populated here.

Finally, within our view, we access the data and use Angular’s awesome databinding to populate our view from our view model:

The “Load Data” link invokes our vm.load() method, while div class “row” is repeated for each item returned in our view model’s repository property.

Technical Considerations

Security

When making Sitecore Item Web API calls, if you’re planning on making cross-domain requests, you may run into some issues. While I have seen some recommended solutions, I have not tried implementing any.

Accessing Sitecore content adds additional configuration to ensure content can be accessed by your application. In our example, we’re saving our credentials within $httpprovider’s default header. Any GET request to our Sitecore instance are accessed as our demo site’s Admin user:

Note: for obvious reasons, do not use your admin account. This is for demo purposes only.

Performance

While it might seem difficult to overload your Sitecore instance from requests coming from a SPA, be aware of how your SPA accesses your Sitecore instance. You would never want to have your method which invokes GET requests within any repeated elements, such as our ng-repeat element.

Conclusion

Accessing Sitecore content using the Sitecore Item Web API is very easy and works exceptionally well within a SPA or application using the AngularJS framework.

For the complete solution, including routing, Sitecore field mappings and all views and controllers, go here: https://github.com/PetersonDave/SinglePageAppDemo/tree/with-sitecore-webapi.