Disclaimer: this post is for the more technically inclined – the development crowd.
Generally when you are using something like Angular or one of the other comparable frameworks for Single Page Application (SPA), there is a tendency to believe that it needs to control the entire page or even application. While that is generally the case, people using a Content Management System (CMS) can still get the power out of it even if the SPA framework is not the core delivery mechanism of the site’s pages. SharePoint or Sitecore are great examples of this. You might have a page on one of these two tools where content editors need to change out widgets. Even though it’s not SPA, your widgets can still be MVC or MVVM that consume service layers. You can harness this inside of the CMS; you just have to be more aware of how the frameworks can work with you vs. against you.
- Widgets within CMS. For us at Arke, we have pages with widgets (renderings in Sitecore terms) that only exist one time on the page. In this case, the widget itself can be a SPA. It only needs to control itself. It can be very self-contained and can get a very responsive feel for Angular even though we don’t control the whole page.
- SharePoint. In SharePoint, you can still keep it low by channeling and isolating it to using the dialog framework. That dialog actually opens up an application page in an iframe, so it can then use Angular. It helps answer the question, “Can we actually reuse this widget?”
Flexibility and Benefits
We’ve found more efficiency by leveraging Angular when building visual web parts in SharePoint 2013. Rather than having our markup compiled into our assembly, we use the visual web part to load Angular and bootstrap our app, but the display is delivered with partial views. This allows us to make updates directly to the views without having to redeploy the solution, saving an app domain recycle. It’s really fast to do development on it compared to conventional SharePoint 2013 web part development methodologies.
You may be thinking, “Why don’t you just use the app model?” Well, sometimes it’s just not appropriate. For instance, if the client is on premise and I want to leverage code that can talk to it, and don’t want to worry about part of my app being in the cloud and part of it not. This is beneficial because you don’t have to have an app that lives in the cloud and requires handling authentication and OAuth.
We’ve been playing with this idea, but haven’t really fully gone down the path yet. We are still learning the best ways to capitalize on the strengths of the SPA frameworks to augment the CMS development process. The biggest benefit of using Angular in this way, however, is already readily apparent, which is a much faster application build time because it’s a client side, responsive experience without a lot of development overhead. This is really, a huge win.