Alternatives To Master Pages And Web Part Pages For Hosting Angular Spa

Why Move Away from Master Pages and Web Part Pages?

Master pages and web part pages have been the traditional way to build SharePoint sites and pages. However, they have some limitations when trying to implement complex single page applications (SPAs) using modern JavaScript frameworks like Angular:

Limited capabilities for dynamic functionality – Master pages and web part pages render on the server, making it difficult to create truly dynamic and interactive client-side experiences
No out-of-the-box support for advanced frameworks – Integrating frameworks like Angular requires custom solutions and workarounds
Lack of flexibility and control – The rigid page structure makes it hard to fully control the markup and front-end logic

These limitations have led many teams to look for alternatives that offer better support for client-side SPAs built with Angular and other modern frameworks.

Best Alternatives for Hosting Angular SPAs

There are a few compelling options for hosting Angular apps in SharePoint without relying on traditional master pages and web part pages:

Table of Contents

SharePoint Framework (SPFx)

The SharePoint Framework (SPFx) allows developers to build client-side solutions with Angular and other JavaScript frameworks that can be deployed directly to SharePoint. Key capabilities include:

Full support for TypeScript, Angular, React and other frameworks
Client-side rendering for faster performance
Easy integration with SharePoint data and services
Built-in build tools, bundling and deployment pipelines

Azure Static Web Apps

Azure Static Web Apps provides automated builds, deployments, and hosting for modern SPAs. With this approach:

The Angular app can be deployed as a static site in Azure and scaled globally
Dynamic functionality comes from calling the SharePoint REST API
No need to fit the SPA architecture into SharePoint constructs

Third-Party SharePoint Frameworks

There are third-party frameworks like Angular Elements and React.js that simplify integrating modern SPAs into SharePoint pages:

Allows hosting components built with Angular, React and other frameworks as custom elements
Development remains entirely client-side using the framework
Renders components directly into SharePoint pages

Migrating an Existing Angular App to SharePoint Framework

Overview of SPFx Architecture

The SharePoint Framework (SPFx) uses modern JavaScript tooling and web standards to allow developers to build client-side solutions for SharePoint. Some key aspects include:

Solutions are structured as SharePoint add-ins with a configurable manifest
Client bundles use standard APIs like npm, TypeScript, webpack
Bundles can include almost any client framework like Angular, React, etc.
Solutions deploy to SharePoint app catalogs and load on-demand

This flexible architecture makes it possible to migrate existing Angular apps to run within SharePoint pages.

Creating SPFx Project with Angular Elements

An SPFx project can use Angular elements to surface components in SharePoint pages:

Create SPFx project using Yeoman generator
Choose “no JavaScript framework” since we’ll manually add Angular
Use Angular CLI to generate library in src folder
Add module for custom components, bootstrap module
Build and bundle Angular code with SPFx pipeline

Referencing Angular Code and Assets

The bundled Angular app can be referenced in the main SPFx component:

Import and add custom component to declarations
Load styles by importing .scss files
Bundle external assets like images and fonts
Expose public API from Angular library

Deploying the Solution

To deploy the SPFx package:

Bundle solution using SPFx toolchain
Upload .sppkg file to SharePoint app catalog
Add the client-side solution to a SharePoint site
Host Angular app in page placeholders like Script Editor

This allows the Angular app to be safely embedded within SharePoint pages.

Integrating Angular with Azure Static Web Apps

Configuring an Azure Static Site

Azure Static Web Apps can host an Angular front-end app and serve it globally:

Create Azure static site resource
Link GitHub repository with Angular source code
Configure builds with Angular CLI and output directory
Set up staging and production deployment environments

Setting up CI/CD Pipeline

Static site resource creates a continuous deployment pipeline:

New GitHub commits trigger builds
Azure builds app with ng build
Output files pushed to staging slot
Promote changes by swapping staging and production

Mapping Routes and Deploying Build Artifacts

The Angular router configurations get deployed along with the bundled artifacts:

App routes defined using Angular router work normally
Azure serves index.html for unknown paths
Angular loads appropriate component for route

Calling SharePoint REST API

The static Angular app can authenticate and access the SharePoint REST API:

Use Azure AD authentication for app backend
Call SharePoint search, list and other REST endpoints
Build custom services wrapping REST APIs

This provides a scalable global CDN for the app frontend while integrating SharePoint data.

Using Third-Party Frameworks Like Angular Elements

Creating Encapsulated Angular Components

Angular Elements allows converting components to custom elements using the createCustomElement() API:

Decorate component class with @Component decorator
Import BrowserModule and call createCustomElement()
Adds browser polyfills and wraps component

This encapsulates the Angular component as a standard custom element.

Registering Components as Custom Elements

To use the Angular element within HTML:

Import component class
Get element name from class decorator
Call customElements.define(elementName, class)
Element can now be used like built-in elements

Loading and Using Components on Pages

Pages can load the web component polyfills and register Angular elements globally:

Add @webcomponents polyfill bundle
Register import map to load elements
Define custom elements
Insert element tags declaratively in HTML

This approach keeps Angular implementation encapsulated while rendering dynamic UIs.

Example Code Snippets

SPFx Angular Integration

“`js
// Reference Angular library
import { MyComponent } from ‘./angular/mycomponent’;

@NgModule({
declarations: [
MyComponent
]
})
export class AppModule { }
“`

Azure Static Site CI/CD Workflow

“`yaml
trigger:
– main

pool:
vmImage: ubuntu-latest

steps:
– script: |
npm install
npm run build
displayName: ‘Build Angular App’

– task: AzureStaticWebApp@0
inputs:
azure_static_web_apps_api_token: $(AZURE_STATIC_WEB_APPS_API_TOKEN_PROD)
“`

Wrapper for Angular Component as Custom Element

“`js
import { createCustomElement } from ‘@angular/elements’;
import { MyComponent } from ‘./mycomponent’;

customElements.define(‘my-element’, createCustomElement(MyComponent))
“`

Summary and Recommendations

In summary, SharePoint Framework, Azure Static Web Apps and third-party custom elements are three solid alternatives for hosting complex Angular-based SPAs in SharePoint.

Pros and Cons of Each Approach

SPFx – Tight SharePoint integration but requires custom deployment
Azure Static Web Apps – Simple cloud hosting but loose SharePoint coupling
Custom Elements – Encapsulates Angular code but browser support can be limited

When to Use Each Alternative

Some guidelines on when to choose which approach:

SPFx – When SharePoint data/identity integration is required
Azure Static Web Apps – For public-facing sites with minimal SharePoint integration
Custom Elements – To modernize pages incrementally while migrating

Best Practices for Implementation

Use SPFx generator to start new solutions for easy deployment
Follow patterns like custom elements and service injection
Plan for identity management and data connectivity
Implement resilient error handling and fallback UIs

Carefully evaluating these alternatives against application requirements and following best practices will enable successfully deploying Angular solutions on SharePoint at scale.