, are web applications that have a little bit of extra functionality added by service workers. In this article, we'll show you how to write a PWA in Angular and by the end, you will have a working PWA, which you can install on your device.

Service workers assist in caching files and API calls, making the app feel faster and more responsive. PWAs can also be installed on a user's device and 

. You can also check out the code here in 

Really, all it is is a special browser tab where the application is run. It feels native, though, and familiar to users. When you make a change to your application, the change is sent out to every device because, again, 

. No more managing multiple code bases for multiple targets.

So now that we know some of the benefits of PWAs, 

how do we go about converting our Angular app into a PWA

? Luckily, the Angular team has solved this problem for us! In this article, we'll go over how to convert our application to a PWA and add some of the basic PWA functionality that we'll need. 

By the end of this article, you will have a working PWA, installable on your device.

Let's start by creating a new application with the CLI:

Answer all the prompts (or select your defaults with the 

 command) and change into the new directory. Now we'll add the PWA functionality through a different CLI command:

Running that command does the following things to your application:

This is really all you need for your application to be turned into a PWA. Your application does need to be built with a production configuration, and served with an application server of some sort (not 

) for the PWA to work. One way to do that would be to run the following commands:

ng build --prod
npx http-server -p 8080 -c-1 dist/my-pwa

With these two commands, your application will be built (with the environment set to production) and the application will be served using 

 in your browser, and you should see a little plus sign in the URL bar (if you're using Chrome).

Clicking on that plus button will allow you to install the application. 

This is great, but we're going to really want a 

 to show up for the user, telling them they can install the application. Also, we should let the user know when there are updates for the application so that they can update the app. 

We also will want to tell the service worker what information to cache, both API calls and other assets. Let's go ahead and start there.

 file allows for two different types of cached data, asset groups and data groups. Asset groups are HTML, JavaScript, and CSS files, as well as images, fonts, and other files like that. We can set this up by adding the following to the 

"assetGroups": [
	{
		"name": "app",
		"installMode": "prefetch",
		"resources": {
			"files": ["/favicon.ico", "/index.html", "/*.css", "/*.js"]
		}
	}
]

 array, but we'll start with this first one. Each group needs to have a unique name, and the 

As you can see above, you can name files explicitly, or have file pattern names to be matched. It's the same with the 

, but you'll add in CDN URLs for CSS files, JS files or fonts, for example, the 

 attributes are technically optional, but if you don't add them then nothing could be cached...so they're not 

 optional. (They're optional in that you can leave one of them off, but you shouldn't leave both of them off.)

There are a couple other attributes we can add as well, but they have default values so they're not required. 

 attribute. The two options as values for this attribute are 

 is used by default. This method is bandwidth intensive, as it downloads and caches all the files for the current version of the app to make sure they're available when requested. The 

 option doesn't cache anything until the resource is requested. If the resource is never requested, it's never cached. This is really perfect for images, especially if you have the same image at different resolutions. Some of those resolutions may never be requested, so caching them doesn't make any sense.

The same options as above are available for another attribute on the 

, all matching assets are updated immediately. If the value is 

, the assets are updated when they're requested. There is one catch here though: the 

 is also set to lazy. Its value defaults to the same value as the 

One reason you may have multiple entries in the 

es the files we see above: the favicon, the root 

 file, and CSS and JS files. But you'll likely want to use a 

 method of caching other image files. You could put the images in a different 

 object and have them be cached differently. This flexibility is great to make sure that the performance of your app is not affected by caching files to the device.

Data groups are similar in theory to the 

, but they're configured differently. Let's take a look at an example 

"dataGroups": [
	{
		"name": "swapi",
		"urls": ["https://swapi.co/**"],
		"cacheConfig": {
			"strategy": "freshness",
			"maxSize": 100,
			"maxAge": "3d",
			"timeout": "10s"
		}
	}
]

Again, we still need a unique name for the 

 attribute is also required, with the URLs listed in the array having their responses cached. The remaining values that need to be provided are in the 

 object. Two of the four listed above are required (

 sets the maximum number of entries, or responses, in the cache. Open ended caches can be bad, so make sure to put some sort of size on the cache. 

 determines how long the responses can live in the cache before they're considered invalid and need to be updated. The source that you're caching here will be the deciding factor for the age. If it's something that rarely, if ever, changes you can safely cache the responses for much longer than sources that have new data frequently coming through them.

 tells the service worker how it should go about caching the responses to the API calls for this source. 

 means that the service worker will prioritize updating the information before using the cache. It will only used data in the cache if the timeout limit has been reached. 

, which is the default value, prioritizes using cached data before hitting the network. It means that sometimes stale data can be served to users, but it does make the call to a given endpoint return data much quicker. This method is best used for calls that don't frequently change.

To read more about the configuration for the service worker, go check out the 

Angular documentation on service worker config

. With this configuration, though, we have a service worker that is running and actively caching our API requests as well as our assets in the application. But we still will want to prompt the user to install the application and to let them know when the application has updated and there's a new version for them to install.

Let's talk about providing an installation prompt. 

Many browsers will ask the user if they'd like to install the PWA to their device automatically. But the user can decline, and if they do so, it may be some time (potentially months) before they're asked again. 

We can add a little code to our application, though, that will show this prompt for us to make sure the user sees it. I'm going to show you the code for this in a normal JavaScript file which will be included with the application, but you could also convert this code to run in an Angular component as well. The only risk with that is that the 

 event fires before the application bootstraps, in which case the prompt would never be shown.

var promptEvent;
var btn = document.querySelector('#pwa-install-button');

window.addEventListener('beforeinstallprompt', event => {
	promptEvent = event;
	btn.style.display = 'block';
	console.log('beforeinstallprompt caught');
});

btn.addEventListener('click', () => {
	if (promptEvent) {
		promptEvent.prompt();
		promptEvent.userChoice.then(result => {
			if (result.outcome === 'accepted') {
				console.log('user accepted add to homescreen');
			} else {
				console.log('user dismissed the add to homescreen');
			}
			promptEvent = undefined;
		});
	}
});

All that's going on here is that we're waiting for the 

 event to fire. When it does, we show a PWA install button. If it's clicked, we use the built in PWA install prompt for the browser. It's that simple. We really let the browser and operating system handle the heavy lifting here. We're just making sure the button actually shows up.

The last thing that we'll cover here is showing an update prompt when a new version of the application is ready. For this one, we will use actual Angular functionality to accomplish our goals.

Let's start by creating a component we can use to show the update notification:

Inside this component, we will need to inject the 

...

constructor(private _swUpdate: SwUpdate) {}
...

ngOnInit() {
	if (this._update.isEnabled) {
		this._update.available.subscribe(() => {
			this.updateAvailable = true;
		})
	}
}

<p *ngIf="updateAvailable" class="update-notification">
	There is a new version of this app available. <span (click)="doUpdate()">Update now?</span>
</p>

doUpdate() {
	this.updateAvailable = false;
	window.location.reload();
}

In this component, we're subscribing to the 

 service, which will emit a new value each time there is an update available for the application. 

When the service emits the value, we set a variable which will show and hide the update notification to true. If they click "accept" on the notification, the application is updated (which is really just reloading the page). If they click cancel, the notification is hidden until another new version of the app is ready. 

That's really all it takes to prompt the user to update. You could force them to update the application in that 

 method, if you wanted, but you force them into doing something that they may not be ready for. What if they're filling out a big form when the update comes? Reloading the page would be really frustrating. It's likely almost always better to prompt the user first.

PWAs are a great option for many applications, giving the user a native feel without having to write a single line of native app code. Your mobile "app" and desktop "app" and web app are all using the exact same code base, but allowing for them to run in different locations. And with the Angular team having figured out the majority of the hard parts for us with the configuration and registration of the service worker, it's very simple to add this functionality to your site.

If you still have questions about PWAs, you can 

 on the Google developers page to get some more information.

<h1 data-node-type="titlePlaceholder">PWAs and Angular</h1><div data-node-type="summary" class="summary-block">PWAs, or <em>Progressive Web Apps</em>, are web applications that have a little bit of extra functionality added by service workers. In this article, we'll show you how to write a PWA in Angular and by the end, you will have a working PWA, which you can install on your device.</div><p>Service workers assist in caching files and API calls, making the app feel faster and more responsive. PWAs can also be installed on a user's device and <strong>used like it is a native application</strong>.</p><div data-panel-type="info" data-panel-position="inline" class="panel panel-type-info panel-position-inline"><div class="panel-container lolwut"><p>The completed code repo is here on <a href="https://github.com/pjlamb12/plamb-newline-pwa" rel="noopener noreferrer nofollow">Github</a>, and can see the deployed app at <a href="https://plamb-newline-pwa.netlify.com" rel="noopener noreferrer nofollow">plamb-newline-pwa.netlify.com</a>. You can also check out the code here in <a href="https://stackblitz.com/edit/plamb-newline-pwa-stackblitz" rel="noopener noreferrer nofollow">Stackblitz</a>.</p></div></div><p>Really, all it is is a special browser tab where the application is run. It feels native, though, and familiar to users. When you make a change to your application, the change is sent out to every device because, again, <strong>it's just a web application</strong>. No more managing multiple code bases for multiple targets.</p><p>So now that we know some of the benefits of PWAs, <strong>how do we go about converting our Angular app into a PWA</strong>? Luckily, the Angular team has solved this problem for us! In this article, we'll go over how to convert our application to a PWA and add some of the basic PWA functionality that we'll need. </p><p>By the end of this article, you will have a working PWA, installable on your device.</p><div data-embed="true" contenteditable="false" class="embeddedIframeWrapper embed-container editing embed-position-hang"><iframe src="//cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fstackblitz.com%2Fedit%2Fplamb-newline-pwa-stackblitz%3Fembed%3D1&amp;url=https%3A%2F%2Fstackblitz.com%2Fedit%2Fplamb-newline-pwa-stackblitz&amp;image=https%3A%2F%2Fc.staticblitz.com%2Fassets%2Ficon-664493542621427cc8adae5e8f50d632f87aaa6ea1ce5b01e9a3d05b57940a9f.png&amp;key=c4a3d56b91fa4b36945f1953875308ab&amp;type=text%2Fhtml&amp;schema=stackblitz" frameborder="0" sandbox="allow-scripts allow-forms allow-same-origin"></iframe></div><h2>Creating our Application</h2><p>Let's start by creating a new application with the CLI:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-OLl4Y" id="cm-OLl4Y">ng new my-pwa</textarea><p>Answer all the prompts (or select your defaults with the <code>ng new</code> command) and change into the new directory. Now we'll add the PWA functionality through a different CLI command:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-8YozD" id="cm-8YozD">ng add @angular/pwa --project my-pwa</textarea><p>Running that command does the following things to your application:</p><ol><li><p>Adds a <code>manifest.json</code> to the root of the project (with information about the PWA)</p></li><li><p>Adds a <code>ngsw-config.json</code> to the root of the project (for the service worker)</p></li><li><p>Adds some default icons that the app will use when installed</p></li><li><p>Updates the <code>app.module.ts</code> file to register the service worker for you</p></li><li><p>Updates the <code>angular.json</code> file to add the <code>manifest.json</code> and <code>ngsw-config.json</code> files to the assets list</p></li><li><p>Updates the <code>index.html</code> to include a link to the <code>manifest.json</code>, a meta tag for theme-color, and a noscript tag</p></li></ol><p>This is really all you need for your application to be turned into a PWA. Your application does need to be built with a production configuration, and served with an application server of some sort (not <code>ng serve</code>) for the PWA to work. One way to do that would be to run the following commands:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-DZMU4" id="cm-DZMU4">ng build --prod
npx http-server -p 8080 -c-1 dist/my-pwa</textarea><p>With these two commands, your application will be built (with the environment set to production) and the application will be served using <code>http-server</code>. </p><p>Go to <code>localhost:8080</code> in your browser, and you should see a little plus sign in the URL bar (if you're using Chrome).</p><figure class="photo figure-position-inline"><img src="https://s3.amazonaws.com/assets.fullstack.io/n/20191018185232206_install-plus.png" attachmentid="5743785d-1261-4d95-8771-696b898864a4" contenteditable="false" data-width="1068" data-height="166"><div></div></figure><p>Clicking on that plus button will allow you to install the application. </p><figure class="photo figure-position-inline"><img src="https://s3.amazonaws.com/assets.fullstack.io/n/20191018185326416_install-prompt.png" attachmentid="cc41b7b1-7117-43d3-9929-a444bf05006f" contenteditable="false" data-width="1078" data-height="566"><div></div></figure><p></p><p>This is great, but we're going to really want a <em>prompt</em> to show up for the user, telling them they can install the application. Also, we should let the user know when there are updates for the application so that they can update the app. </p><p>We also will want to tell the service worker what information to cache, both API calls and other assets. Let's go ahead and start there.</p><h2>Asset and Data Groups</h2><p>The <code>ngsw-config.json</code> file allows for two different types of cached data, asset groups and data groups. Asset groups are HTML, JavaScript, and CSS files, as well as images, fonts, and other files like that. We can set this up by adding the following to the <code>ngsw-config.json</code> file:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-xcPMF" id="cm-xcPMF">"assetGroups": [
	{
		"name": "app",
		"installMode": "prefetch",
		"resources": {
			"files": ["/favicon.ico", "/index.html", "/*.css", "/*.js"]
		}
	}
]</textarea><p>We can have multiple entries in the <code>assetGroups</code> array, but we'll start with this first one. Each group needs to have a unique name, and the <code>resources</code> object, where either the <code>files</code> to be cached are declared or the <code>urls</code> to be cached are declared. </p><p>As you can see above, you can name files explicitly, or have file pattern names to be matched. It's the same with the <code>urls</code>, but you'll add in CDN URLs for CSS files, JS files or fonts, for example, the <code>resources</code> and <code>files</code> or <code>urls</code> attributes are technically optional, but if you don't add them then nothing could be cached...so they're not <em>really</em> optional. (They're optional in that you can leave one of them off, but you shouldn't leave both of them off.)</p><p>There are a couple other attributes we can add as well, but they have default values so they're not required. </p><p>The first is the <code>installMode</code> attribute. The two options as values for this attribute are <code>prefetch</code> and <code>lazy</code>. If you don't add anything, <code>prefetch</code> is used by default. This method is bandwidth intensive, as it downloads and caches all the files for the current version of the app to make sure they're available when requested. The <code>lazy</code> option doesn't cache anything until the resource is requested. If the resource is never requested, it's never cached. This is really perfect for images, especially if you have the same image at different resolutions. Some of those resolutions may never be requested, so caching them doesn't make any sense.</p><p>The same options as above are available for another attribute on the <code>assetGroup</code> entry, the <code>updateMode</code>. The behavior is very similar to <code>installMode</code>; if the value is <code>prefetch</code>, all matching assets are updated immediately. If the value is <code>lazy</code>, the assets are updated when they're requested. There is one catch here though: the <code>updateMode</code> can only be set to <code>lazy</code> if the <code>installMode</code> is also set to lazy. Its value defaults to the same value as the <code>installMode</code>.</p><p>One reason you may have multiple entries in the <code>assetGroups</code> array is to have an entry that <code>prefetch</code>es the files we see above: the favicon, the root <code>index.html</code> file, and CSS and JS files. But you'll likely want to use a <code>lazy</code> method of caching other image files. You could put the images in a different <code>assetGroup</code> object and have them be cached differently. This flexibility is great to make sure that the performance of your app is not affected by caching files to the device.</p><p>Data groups are similar in theory to the <code>assetGroups</code>, but they're configured differently. Let's take a look at an example <code>dataGroups</code> entry:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-DChvw" id="cm-DChvw">"dataGroups": [
	{
		"name": "swapi",
		"urls": ["https://swapi.co/**"],
		"cacheConfig": {
			"strategy": "freshness",
			"maxSize": 100,
			"maxAge": "3d",
			"timeout": "10s"
		}
	}
]</textarea><p>Again, we still need a unique name for the <code>dataGroup</code> entry. The <code>urls</code> attribute is also required, with the URLs listed in the array having their responses cached. The remaining values that need to be provided are in the <code>cacheConfig</code> object. Two of the four listed above are required (<code>maxSize</code> and <code>maxAge</code>) with the other two being optional (<code>timeout</code> and <code>strategy</code>).</p><p><code>maxSize</code> sets the maximum number of entries, or responses, in the cache. Open ended caches can be bad, so make sure to put some sort of size on the cache. <code>maxAge</code> determines how long the responses can live in the cache before they're considered invalid and need to be updated. The source that you're caching here will be the deciding factor for the age. If it's something that rarely, if ever, changes you can safely cache the responses for much longer than sources that have new data frequently coming through them.</p><p><code>strategy</code> tells the service worker how it should go about caching the responses to the API calls for this source. <code>freshness</code> means that the service worker will prioritize updating the information before using the cache. It will only used data in the cache if the timeout limit has been reached. <code>performance</code>, which is the default value, prioritizes using cached data before hitting the network. It means that sometimes stale data can be served to users, but it does make the call to a given endpoint return data much quicker. This method is best used for calls that don't frequently change.</p><p>To read more about the configuration for the service worker, go check out the <a href="https://angular.io/guide/service-worker-config" rel="noopener noreferrer nofollow">Angular documentation on service worker config</a>. With this configuration, though, we have a service worker that is running and actively caching our API requests as well as our assets in the application. But we still will want to prompt the user to install the application and to let them know when the application has updated and there's a new version for them to install.</p><h2>Installation Prompt</h2><p>Let's talk about providing an installation prompt. </p><p>Many browsers will ask the user if they'd like to install the PWA to their device automatically. But the user can decline, and if they do so, it may be some time (potentially months) before they're asked again. </p><p>We can add a little code to our application, though, that will show this prompt for us to make sure the user sees it. I'm going to show you the code for this in a normal JavaScript file which will be included with the application, but you could also convert this code to run in an Angular component as well. The only risk with that is that the <code>beforeinstallprompt</code> event fires before the application bootstraps, in which case the prompt would never be shown.</p><p>Here's the install prompt file:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-VfIsU" id="cm-VfIsU">var promptEvent;
var btn = document.querySelector('#pwa-install-button');

window.addEventListener('beforeinstallprompt', event =&gt; {
	promptEvent = event;
	btn.style.display = 'block';
	console.log('beforeinstallprompt caught');
});

btn.addEventListener('click', () =&gt; {
	if (promptEvent) {
		promptEvent.prompt();
		promptEvent.userChoice.then(result =&gt; {
			if (result.outcome === 'accepted') {
				console.log('user accepted add to homescreen');
			} else {
				console.log('user dismissed the add to homescreen');
			}
			promptEvent = undefined;
		});
	}
});</textarea><p>All that's going on here is that we're waiting for the <code>beforeinstallprompt</code> event to fire. When it does, we show a PWA install button. If it's clicked, we use the built in PWA install prompt for the browser. It's that simple. We really let the browser and operating system handle the heavy lifting here. We're just making sure the button actually shows up.</p><h2>Update Prompt</h2><p>The last thing that we'll cover here is showing an update prompt when a new version of the application is ready. For this one, we will use actual Angular functionality to accomplish our goals.</p><p>Let's start by creating a component we can use to show the update notification:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-IG5OJ" id="cm-IG5OJ">ng g c update-notification</textarea><p>Inside this component, we will need to inject the <code>SwUpdate</code> service from <code>@angular/service-worker</code>:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-PaXdG" id="cm-PaXdG">...

constructor(private _swUpdate: SwUpdate) {}
...</textarea><p>Next, add the following to the <code>ngOnInit</code> function:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-V8Otw" id="cm-V8Otw">ngOnInit() {
	if (this._update.isEnabled) {
		this._update.available.subscribe(() =&gt; {
			this.updateAvailable = true;
		})
	}
}</textarea><p>Here's the HTML for the component:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-jPvcm" id="cm-jPvcm">&lt;p *ngIf="updateAvailable" class="update-notification"&gt;
	There is a new version of this app available. &lt;span (click)="doUpdate()"&gt;Update now?&lt;/span&gt;
&lt;/p&gt;</textarea><p>And the <code>doUpdate</code> function in the component:</p><textarea data-iscodemirror="true" data-mode="javascript" data-uniqueid="cm-MmCcH" id="cm-MmCcH">doUpdate() {
	this.updateAvailable = false;
	window.location.reload();
}</textarea><p>In this component, we're subscribing to the <code>SwUpdate</code> service, which will emit a new value each time there is an update available for the application. </p><p>When the service emits the value, we set a variable which will show and hide the update notification to true. If they click "accept" on the notification, the application is updated (which is really just reloading the page). If they click cancel, the notification is hidden until another new version of the app is ready. </p><p>That's really all it takes to prompt the user to update. You could force them to update the application in that <code>subscribe</code> method, if you wanted, but you force them into doing something that they may not be ready for. What if they're filling out a big form when the update comes? Reloading the page would be really frustrating. It's likely almost always better to prompt the user first.</p><h2>Conclusion</h2><p>PWAs are a great option for many applications, giving the user a native feel without having to write a single line of native app code. Your mobile "app" and desktop "app" and web app are all using the exact same code base, but allowing for them to run in different locations. And with the Angular team having figured out the majority of the hard parts for us with the configuration and registration of the service worker, it's very simple to add this functionality to your site.</p><p>If you still have questions about PWAs, you can <a href="https://developers.google.com/web/progressive-web-apps" rel="noopener noreferrer nofollow">read this article</a> on the Google developers page to get some more information.</p>

AUTHOR

Preston Lamb

PWAs, or Progressive Web Apps, are web applications that have a little bit of extra functionality added by service workers. In this article, we'll show you how to write a PWA in Angular and by the end, you will have a working PWA, which you can install on your device.

Learn

The newline Guide to Building Your First GraphQL Server with Node and TypeScript

Teach

Amelia Wattenberger

Author of Fullstack D3

Community

PWAs and Angular

Responses (0)

Masterclasses

Tutorials

Fullstack React with TypeScript