DEV Community: Mike Hartington

Announcing Ioniconf 2020

Mike Hartington — Thu, 21 May 2020 15:41:01 +0000

It’s finally happening! The moment that’s been talked about, questioned, speculated, humbly requested, not so humbly requested, and otherwise called for by many a community member …the first-ever Ionic conference.

You heard it right, folks. Announcing Ioniconf 2020!

Ioniconf 2020 is an all digital event taking place June 24th (t-minus 34 days and counting) from the comfort of your own home! We’ve brought together industry leaders to share everything they can about Ionic and the Web Platform, in a celebration of the web and web developers.

What you need to know

Let’s share some backstory here, because it’s been a wild ride getting this event up and running. Rewind back to my first ngConf in 2015. After the conference was over, a few of us on the Ionic team and some community members were celebrating a successful trip when one brought the idea of an Ionic conference. “Yeah, we’ll have the event in Vegas, I’ll help you all out in setting up the details, and it will be great. It will be something to celebrate this amazing community and bring in people who are experts in our industry to share their knowledge.”

Well, you know how it goes. Planning and executing a physical event is no easy - or cheap - endeavor. And as weeks turned to months, and months turned to years, we put off the idea until we were ready.

Well, given the current climate and the growing acceptance of (nay, clamoring for) virtual events, we decided that the time was indeed right. And now here we are.

And just like we originally envisioned, Ioniconf 2020 will be a celebration of the Ionic community. A fun-filled day focused on education, sharing, and enlightenment in the ways of the web.

The format is a one day, single track, online conference covering all things related to web development and Ionic. Attendees can sit back and enjoy a full day of amazing talks, plus Q&A with speakers after sessions. We’ll be watching for questions from social media, so be sure to tag your questions with #AskIoniconf2020

Stay tuned for details about Ioniconf 2020 in the coming weeks as we add speakers, topics, and other exciting details. We are excited to put this event on and we hope you’ll join us!

Is Apple trying to kill PWAs?

Mike Hartington — Thu, 02 Apr 2020 16:19:45 +0000

It seems that any time Apple releases something there is bound to be some noise regarding it. This time, it's in regards to browser storage and Apple’s recent proclamation that such data will be deleted after 7 days. Well let's break this down and see what this really means for developers.

Let me start by saying that these are only my opinions. These do not reflect the opinions of Ionic or the rest of my coworkers. In fact, there’s healthy disagreement and differing views among our team, as I’m sure there are on yours.

Recently, Apple released a blog post talking about their latest enhancements to Intelligent Tracking Prevention. There's a lot to this blog post, but the part that stuck out to everyone was

Now ITP has aligned the remaining script-writable storage forms with the existing client-side cookie restriction, deleting all of a website’s script-writable storage after seven days of Safari use without user interaction on the site. These are the script-writable storage forms affected (excluding some legacy website data types):

Indexed DB
LocalStorage
Media keys
SessionStorage
Service Worker registrations

Wait what? Apple is going to clear out my site's storage after seven days? WTF Apple?? This seems to be the reaction that most people are having on Twitter, Hacker News, etc. The backlash was so strong that the blog post author went back and added some additional comments to clarify exactly what they meant. So what does this mean?

📞 Seven days...

Well from the very beginning, it's been pretty vague what is considered "Seven days of use". I kept thinking about the scene from "Scary Movie 3" where the main character has an argument about what "Seven Days" really means (a gem in an otherwise 'meh' movie). Well after thinking about the blog post for a few days now, I think I finally have the breakdown.

Inside of Safari, there is an internal counter. Let's say you access Site A (startrack-ng.web.app). Site A has a service worker and when you visit it, it registers the service worker with Safari. You leave the site and don't touch your phone for the rest of the day. The next day, you use your phone again and go to Site A. Since you've used Site A again, there is no day counted against you.

So now you wait another day, you open Safari, but this time you go to Site B. You read some articles, close out the browser and don't use your phone. After this day, you have now reached one day of Safari use without interacting with Site A. You are now down to six days.

The next day you don't use Safari at all. You still use your phone, but you haven't actually opened the browser. Well since you haven't used Safari, you do not accrue another day. So your count will still be at six days remaining.

This is the pattern. You have seven days of Safari use for users to visit your site. If after seven days of Safari use, your site is not loaded, the script-writable storage will be cleared out.

Home Screen Apps

One of the questions that did arise out of the Twitter/Hacker News backlash was with regards to apps on the home screen. Since they are not loaded through Safari, what's their counter logic? Turns out, they effectively do not have a counter. Well, they do, but the same logic as above is applied. Since they only load one web app, their counter will effectively never hit seven days.

Capacitor/Cordova Apps

Similar to Home Screen Apps, Capacitor/Cordova apps are not affected by this. Some interesting technical details here...it seems the counter is limited to Safari-based apps. Since Cap/Cordova Apps use WKWebview, they actually don't have a counter at all.

Ok, I believe you, but my Twitter circle doesn't

So if this is the case, what is all the frustration about? There seems to be an inherent distrust when it comes to Apple and the web. A lot of people see Apple as the villain in the Web Ecosystem, wanting to kill it in favor of the iOS App Store. While Apple is certainly an odd-duck when it comes to its behavior in the Web Ecosystem, I do not see them as the villain.

Apple and Safari have made their claim on being a fast, secure, and private browser. That's their mission statement. Everything that Safari/Webkit does all goes to make sure users have a fast browser that doesn't use their data for ads or malicious intents. When third-party sources attempt to track you and identify who you are, this goes against Safari's goals.

Let's go back to Service Worker, since it seems to be the most contentious change. As it stands, the Service Worker Spec does not define a limit on how long a registration should last. I read this blog post from Jeremy Keith
and came across this passage:

So I was curious. Wanting to give Apple the benefit of the doubt, I set about trying to find out how long service worker registrations currently last before getting deleted. Maybe this announcement of a seven day time limit would turn out to be not such a big change from current behavior. Maybe currently service workers last for 90 days, or 60, or just 30.
Nope:
There was no time limit previously.

Which links to a tweet from Safari's Dev Rel.

I will say this, yeah this is a drastic change. I can think of a few situations where this will hurt my user experience. But I do think that having no limit on service worker life is even more dangerous. Considering how powerful service workers are, they should have some limitations to make sure they do not become an attack vector for fingerprinting.

PWA !== Service Workers

There are a lot of people who see service workers as a key part of Progressive Web Apps. If you are not adding a service worker to your site, it's not a PWA. I respectfully disagree. A PWA is not a specification. There is no official document that says "A PWA is A,B,C", and there shouldn't be. PWA is defined by best practices. Tying PWA to a specific API seems like a mistake and does more harm.

Is Apple Trying to kill the Web?

No, Apple is not trying to kill the web. The people who work on Safari love the web and want to see the web’s continued growth. What I think we’re seeing is a conflict of culture, goals, and priorities. Developers constantly want new bells and whistles but haven’t considered what all that means. While it might be difficult to have a voice in the community push back and say “we should have limits”, it’s a conversation I think we all should be having.

Thanks y’all for listening, I would love to know your thoughts on this as well. Cheers!

Deploying an Ionic PWA to ZEIT

Mike Hartington — Thu, 19 Mar 2020 14:26:34 +0000

There's no shortage of fantastic hosting providers these days. If you're looking to deploy a web app, you really can't pick wrong. But there are a few that stand out as being the best hosting solution for Progressive Web Apps. Today we're going to look at how to deploy an Ionic React app to ZEIT and how simple ZEIT makes the whole process.

Why ZEIT?

When I say "ZEIT", what I really mean is their static site platform, Now. This platform provides a fast and scalable solution for static sites, JAMstack based web apps, and Serverless Functions. For our use case, we're just going to be utilizing the static hosting, but I highly suggest you take a look at the Serverless portion of their docs, as this could be your one stop shop for all your future apps. The serverless features become very compelling though once you consider SSR with Ionic Angular and Ionic React.

With ZEIT, we can simply connect an existing app that is on GitHub, configure the build commands, and we'll have our app deployed almost instantly.

The App itself

For this demo, I'll just use a sidemenu based template and use React for my framework. ZEIT itself can support more than React, so if you're using Angular, the process will be similar.

I'll create my app and connect it to a GitHub repo

ionic start zeit-pwa sidemenu --type react

cd zeit-pwa

git remote add origin git@github.com:mhartington/zeit-pwa.git

git push origin master

For the app portion, this is all we need, so let's move over to Zeit's dashboard and connect the app.

Deploying

From the dashboard, we're presented with the option to import a new project. Once we click on that, we're given the option to either start from a new template (a blank slate) or import from a git repository. Since our project is already on GitHub, we'll select that and connect our GitHub account.

Once connected, we can click "Import from GitHub", search our repositories for the project, and select it. Once we've confirmed the project import, we'll be prompted to enter an app name. By default this will just be the repo name, which will be fine for our test. We'll hit continue for this and the next prompt which asks us for the project root. Since
our app is not in a mono-repo setup, the default here works just fine.

The next segment is the one that is the most important. We'll need to modify the output directory and development command. Since this is a React project, our output directory will be build, and our development command will be npm run start. For Angular projects, the output directory would be either WWW or the outputPath value in your angular.json and the development command would be npm run start. With this information corrected, we can hit deploy and ship our app.

With our project created, it will take about a minute for our app to be built and deployed to a live URL. For my app, the url is zeit-pwa.now.sh. All apps deployed through ZEIT will be assigned a .now.sh suffix domain. But this can be configured to use a custom domain.

With our app now setup and deployed, any time we commit changes and push them to GitHub, ZEIT will automatically trigger a new build. Once the build is completed, our app will be deployed and will be live!

Parting thoughts

ZEIT, Now, and the whole product suit is quite a compelling service. Given its easy integration with popular frameworks/libraries, simple setup with existing Git repositories, and overall speed, it's pretty obvious why it's starting to look like a premier solution for PWAs. There's a lot more that can be done with ZEIT/Now, so be sure to check out their documentation. Cheer!

SSR with Angular Universal And Ionic

Mike Hartington — Thu, 05 Mar 2020 14:30:50 +0000

So, Angular universal is a thing... And it seems it is something you all have been very excited about for some time. Since I tweeted about this some time ago, it's been one of the top 3 most common questions asked of us (right behind "when's Ionic Vue going to be ready"). Well I did promise that it would be happening soon and that there would indeed be a blog post, so let's take care of that today!

Introducing the @ionic/angular-server module for Angular Universal!

Universal JavaScript

First off, what is Universal JavaScript anyway? Essentially it's JavaScript that can run on the server and in the browser. This is what people refer as "Server Side Rendering" (SSR). By utilizing SSR and Universal JavaScript in our app, we can do an initial render of our app on the server and send over a precompiled version before any JavaScript has been run on the client. With this technique we can achieve

Faster load times ¹
Better SEO ranking
Preview cards on social media

Faster load times can vary and can really fluctuate depending on your app & other circumstances. Your mileage may vary.

So if SSR can help us, how can we add it to our app? Well up until recently, you couldn't. A lot of Ionic's components utilize window and other DOM specific APIs. Since we're on a server and running in Node, we don't have the DOM. This is where Angular Universal and @ionic/angular-server module comes in.

Angular Universal

Angular Universal is Angular's library for running our apps on the server. In earlier releases of Angular (and AngularJS), setting up an app to run on the server was a bit of a pain. Thankfully, Angular Universal and it's various runtimes make this really straight forward.

First let's create an app and update it to the latest version of Angular

ionic start myApp blank --type angular
cd myApp
ng update @angular/core @angular/cli
npm install @angular/animations

Once this has completed, let's add the Express engine for Angular Universal

Express is a popular framework for Node. For more information, please checkout the Express website

ng add @nguniversal/express-engine

This will set up our project to be ready for Angular Universal. Before we continue any further, let's install the @ionic/angular-server module.

npm install @ionic/angular-server@dev

@ionic/angular-server is currently part of a dev release and will be part of an upcoming release of Ionic. Be sure to keep an eye out.

Now, let's open our editor and inspect our project.

Lay of the Land

After Angular Universal is added to our project, you'll notice some *.server.* related files around the project. Specifically a main.server.ts and a app.server.module.ts. These two files in particular are responsible for bootstrapping our app once it is loaded on the server. We can see what this will be like by running:

npm run dev:ssr

This will start our live reload server for our SSR app. Don't be surprised if you see a lot of output from the terminal, we actually have a lot going on here. This script is performing a build of our client side app, as well as building out the server side portion as well. Once this has finished, we'll get a message that our app is available to load on localhost:4200. Once loaded, our app looks like an normal Ionic App.

But if we disable JavaScript on our page, we'll end up getting a blank screen.

What gives? Well this is where the @ionic/angular-server module comes in.

First, let's stop our server for a bit and open our src/app/app.server.module.ts. Here is where our app will bootstrap when it is deployed to our server. Without diving into too many details, Angular Universal provides an entry hook so we can handle situations where our components will be rendered on the server. To take advantage of this, we'll import IonicServerModule and add it to the imports array of our ngModule

import { NgModule } from '@angular/core';
import { ServerModule } from '@angular/platform-server';
import { AppModule } from './app.module';
import { AppComponent } from './app.component';

// Tell Ionic components how to render on the server
import { IonicServerModule } from '@ionic/angular-server';

@NgModule({
  imports: [
    AppModule,
    ServerModule,
    IonicServerModule
  ],
  bootstrap: [AppComponent],
})
export class AppServerModule {}

Once this has been added, we can run our dev-server again and see that our app will still work, even if JavaScript has been disabled.

Some technical details

Now if we wanted to we could deploy our app to different providers (Firebase Cloud Functions for example) and be off to the races, but that doesn't cover everything. You should validate that any library being used can work in situations where there is no window object. Since Universal still isn't too common of a practice, many DOM specific libraries either haven't added support for Universal, or simply just can’t. If you’re using libraries built with Angular, you should be good. If you’re not sure if your project will have issues, the output from a full server build should point you to the problematic library.

Parting thoughts

Since this is only a pre-release of Angular Universal support, we’re looking to get feedback from users. We’ve tested things pretty extensively, but we’d love for you to try it out and let us know if you run into any issues.

We've really only scratched the surface of what can be done. There's topic's like prerender, state transfer, and even static site generation (via Scully) that are now available to us with Angular Universal.

This really is an exciting time to be working in Angular with Ionic. There's a lot more information available out there and I'd encourage people to check out a few resources listed below. As for now, try out the Universal module, let us know if you run into any issues, and thank you for being so patient while we work on it! Cheers 🍻

A New Package for the CLI

Mike Hartington — Tue, 04 Feb 2020 15:40:02 +0000

TL;DR, we're re-releasing the CLI package under a new name, @ionic/cli!
To update, first you will need to uninstall the old CLI package.

$ npm uninstall -g ionic
$ npm install -g @ionic/cli

You will still interact with the CLI via ionic command, just how the CLI is installed has changed. And now, on with the blog post!

Everything has a beginning

Many years ago, when Ionic was still in it's pre 1.0, we saw a great opportunity to help devs build amazing apps without having to guess how that would be done. While the V1 days of Ionic included things like bower, scripts tags, and gulp, it was our first attempt to make a tool that did everything for you. After building out all the initial functionality, we had one last task...what do we call this tool?

We called it...Ionic!

Our initial logic was that we would have one tool and one framework that covered everything. Want to build apps with Ionic? Just install Ionic. This worked great, and for a long time we were set on just keeping things as they were. That is until we started noticing a common point of confusion with our users.

What version of Ionic are you using?

When debugging a user issue or working with community members, one of the first things we ask people is "What version of Ionic are you using?" This has led to some confusion in the community as people would assume that ionic -v would give them the version of both the framework and the CLI. This however is not the case. One or two instances would be enough to ignore this, but given how common this is, we thought it was finally time to solve this issue.

As the number of packages under the Ionic organization has grown, we would ship them under the scoped package name. Our release of Ionic for Angular? @ionic/angular. React? @ionic/react. This is a pretty clear message that when you install one of these packages, you know exactly what you are getting. There is no confusion in this package's purpose or what context this package should be used in.

Moving towards a scoped package

To help with this confusion, we're rereleasing the CLI package under a new name, @ionic/cli. This unifies how we ship tools across Ionic and make sure that people are aware what tool they are installing when setting up their environment. I mentioned this last week in an Ionic newsletter and so far the feedback from the community has been incredibly supportive.

In the past this has been a suggestion that many community members have made and as time has gone on, it seems to be the move many other CLI tools have done. Angular in particular rebranded the angular-cli package in favor of @angular/cli and the Vue CLI has done the same thing (vue-cli to @vue/cli). With this in mind, we finally decided it was time.

To update to the new CLI, you must first uninstall the old CLI package:

$ npm uninstall -g ionic

# Then install the new CLI package
$ npm install -g @ionic/cli

This new package name coincides with the release of the CLI’s 6.0. This includes some new features which can all be reviewed in the Changelog.

The old CLI package will not be updated to the newer 6.0 releases and has an official deprecated warning now. While this should work for some time, we encourage everyone to update to the new CLI package to receive all the latest updates.

Well that’s all for now folks! We are glad the feedback so far has been super supportive of this change and can’t wait for you all to upgrade….Seriously, we can’t wait. Upgrade your CLI 😄.
Cheers!

Angular 9.0.0 and Ivy improvements

Mike Hartington — Thu, 19 Dec 2019 17:49:06 +0000

One of the biggest updates in the pipeline right now is the upcoming release of Angular 9.0.0. Currently in RC, Angular 9.0 will hopefully ship early next year. But this release includes so much that I thought it required a post to highlight some of the most important updates. Now for Ionic devs, why should they care about this? Well given that most apps currently are built with Angular and Ionic, any improvements to the overall ecosystem should always be welcomed! But given the goals of Angular 9.0, this directly impacts (in a positive way) Ionic be being able to ship faster and smaller apps, in faster manner. For reference, we'll be looking at the Angular version of the Star Track demo app - built with Ionic 4 and Angular - and checking out the improvements.

Ivy By Default

One of the biggest improvements to Angular coming in 9.0 is that Ivy is enabled by default. Ivy is Angular's new renderer. A super high level overview is that Ivy enables apps to only require pieces of the render that they actually need, instead of the whole thing. This means that our final output will be smaller, which is always better for performance. It's important to note, that Ivy won't make your components/app significantly smaller if you're using every feature available to Angular. But there are noticeable improvements to the main.js chunk of an app.

For comparison, let’s look at the build output from Star Track with Ivy enabled and with it disabled. We’ll compare the size of the main.js file, which is mostly going to be Angular specific code.

# Ivy disabled
$ ng build --prod
...
chunk {10} main-es2015.d03d9cadf1579320f520.js (main) 537 kB [initial] [rendered]
chunk {10} main-es5.d03d9cadf1579320f520.js (main) 628 kB [initial] [rendered]
...


# Ivy enabled
$ ng build --prod
...
chunk {10} main-es2015.bfc9e260b847bc2b02fc.js (main) 465 kB [initial] [rendered]
chunk {10} main-es5.bfc9e260b847bc2b02fc.js (main) 551 kB [initial] [rendered]
..

From 537kb/628kb without Ivy, to 465kb/551kb with it! Note that Star Track is using almost every feature available from Angular, so delta is a bit smaller, but still a welcomed improvement!

Now Ivy has been around for sometime in earlier release, but always as an opt-in feature. With 9.0, however, Ivy is enabled by default and developers need to opt-out manually. If Ivy is so great, why would developers need to opt-out of it? Well, as this is part of a new major version, there are bound to be some breaking changes here and there. Most of these are not change that app developers need to worry themselves with, but something that component authors would need to deal with. If you're using third-party components/packages that have not updated, you'll want to opt-out of Ivy for now, and open an issue (or better yet, a pull request) against the repo.

Ionic itself will be ready for Ivy when Angular 9.0 is shipped. I've been following along and making the necessary updates needed. We recently have merged a pull request and have been testing a build of Ionic and Angular 9.0.

EntryComponents...BYE BYE BYE

If you've been working with Angular for some time now, you know that one of the most frustrating things to deal with are entryComponents. entryComponents, for the uninitiated, are components that Angular will load imperatively and not through a template. For Ionic, this means overlay components like Modals and Popovers make heavy use of entryComponent for figuring out what to actually render. From a users perspective, there's often a bit of a hiccup when working with Modals/Popovers. The process typically goes:

Generate a new component
Splitting it out into its own module
Attempt to load the component in an overlay
Get an obscure error about a Module Factory
Realize you forgot to add setup entryComponents

This was such a common issue that we even modified the component schematic from Angular to include options for auto-adding components to entryComponents. Thankfully, with 9.0, this is a thing of the past!

With the way components are compiled (thanks to Ivy), entryComponents are no longer needed. So Modals and Popovers just become much easier to think about.

CLI Improvements

In addition to improvements coming to the framework itself, Angular's CLI is also getting some improvements as well. For starters, when serving your app, the app will automatically be built using AOT. This is a great improvement as we no longer have to deal with different environments for our apps. For example; you serve your app with ionic serve or ng serve and the app builds fine. There are no errors, the app loads, all is well! But, when you go to deploy and do a production build, an error appears. Why is the error there and why did it show up only during production? Well due to how components are built, AOT often is able to find potential errors before they happen at run time. Say you have a click handler like so:

<ion-content>
  <h1>Click the button</h1>
  <ion-button (click)="logEvent($event)">Click me</ion-button>
</ion-content>

And the component class looks like so:

@Component({...})
export class MyComponent{

  constructor(){...}

  logevent(event: any){
    console.log(event)
  }
}

The small error here is that the click handler is for logEvent, but the actual method is called logevent. This would result in a runtime error, which we do not want. Thanks to being able to run AOT when running serve, we can now catch small errors like this and get meaningful feedback before they ever happen.

Another improvement is with differential builds. In previous releases, the Angular CLI would perform two different builds, on for ES5 environments and one for ES2015. This process produced the ES5 builds first, then would go back and rebuild the app for ES2015, which could make your production builds take a long time if the app was rather large. With 9.0, the CLI will now change how this is done. Instead of building the ES5 version, the CLI will do a ES2015 build of your app first. From there, that ES2015 build will go through a much quick build process to produce a ES5 build with the necessary polyfills. This is a small and subtle change, but can make your build time much faster!

Parting Thoughts

Angular 9.0 is still in RC (RC6) as of now and most likely won't be shipping before the year is over (good news IMO). But with all the improvements we've gone over here, Angular 9.0 will be a welcome update that should help every developer be successful! Cheers 🍻

Progressive Web Apps in Ionic React

Mike Hartington — Wed, 20 Nov 2019 22:06:18 +0000

With the launch of Ionic React a few weeks back, the reception from the community has been incredible. We’re thrilled that so many of you are excited to use Ionic React, and I myself was excited to try React a bit more. Given that I spend most of my time with Angular, it was fun to see what another framework could offer as I learned how to "think" in React.

With that in mind, I wanted to share my experience rebuilding a personal demo app that I have built in Angular (Star Track) and rebuild it in React. For this exercise, I’m going to focus on how I created a Progressive Web App (or PWA) with Ionic React. Let's dive in!

If you would like to see the final results, you can see an early version of Star Track React here.

App Manifest

Adding the App Manifest was fairly straightforward.

If you’ve built with Angular, you’re probably used to running ng add @angular/pwa and having one created for you. The logic here is that not everyone may need a PWA.

With Create React App (CRA), however, a manifest and placeholder icons are provided out-of-the-box. This was nice, as I could quickly jump in there, make the edits I needed, and get back to building my app.

Service Workers

Service Workers are an essential part of the PWA experience. Without one, our apps would not be able to work offline or be resilient to flaky network connections.

In Angular, we work with the @angular/service-worker package to create and interact with our Service Worker. This allows us to express our caching strategy for our app's resources in a JSON files.

So how does this work in React?

Out-of-the-box, Create React App (CRA) utilized the Workbox library from the Chrome team. By using Workbox's webpack plugin, we're able to get a complete list of all the resources our app needs and create a precache with a hash revision. This is done automatically at build time so there's no need for us to configure this.

But we are putting the pig before the pen here, as we need to opt-in to Service Workers in our main index.ts file. By default CRA has Service Workers disabled due to their advanced nature. The idea being that devs are not used to their content caching. While I disagree with this, I do appreciate that the team has noted their reason on the CRA docs.

To opt-in and register our Service Worker, we can call serviceWorker.register():

//index.ts

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
import * as serviceWorker from './serviceWorker';

ReactDOM.render(<App />, document.getElementById('root'));

// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
// serviceWorker.unregister();
serviceWorker.register();

With this call, we're able to register the Service Worker that the build scripts will create for us.

Handling updates

Since CRA internalizes a lot of moving pieces with Service Workers, I was worried that I would not have a mechanism for handling updates. But digging into the registration function, there's an optional config parameter that could be passed that could handle this. The config argument is an object that can accept an onSuccess and onUpdate key, with a callback function as their values.

From this, we can modify our original register call to pass a config object:

register({
  onUpdate: async (registration: ServiceWorkerRegistration) => {
    await registration.update();
  }
});

Not a whole lot of magic happening here, but it's a bit clearer when looking at the registration function

if (navigator.serviceWorker.controller) {
  // At this point, the updated precached content has been fetched,
  // but the previous service worker will still serve the older
  // content until all client tabs are closed.
  console.log( 'New content is available and will be used when all tabs for this page are closed. See https://bit.ly/CRA-PWA.');

  // Execute callback
  if (config && config.onUpdate) {
    config.onUpdate(registration);
  }
}

When our Service Worker has registered, we can hook into the lifecycles and trigger an update when the new content has been cached.

Parting Thoughts

While focusing mainly on Service Worker and App Manifest, I'm still diving deep into PWAs with React. With what I (and the rest of the Ionic team) learn while we build more and more Ionic React apps, we'll be able to provide the best suggestions for delivering fast, powerful, feature-rich apps with React. Cheers 🍻!