💡A Brief Overview

There are applications which require loading some crucial data before users are allowed to use them.

For example, our application has multilingual support and white label capabilities; Therefore, we need to pre-emptively fetch from the server the user’s data, such as localization, internationalization settings, and theme color schema, and make it available to our components, before we allow the user to interact with them.

We want to ensure this because we don’t want to incur a bad user experience, such as jumpy content or flickering CSS.

In such cases, your application may benefit from what’s known as a splash screen — a loading screen that lets your users know that your application is still working, even though it might a while to perform the initial loading.

In this article, we’ll learn different ways to tackle this.

💎 Using an APP_INITIALIZER Token

APP_INITIALIZER is one of the built-in providers in Angular. It is a multi provider, meaning it can provide multiple values for a single token.

What makes it special and useful to us in these cases, is that it can take a function that returns a promise, and only when that promise is resolved, Angular will bootstrap the application.

Let’s see it in the source code:

When we call the bootstrapModule() method in our main file, Angular collects the provided app initializers that are of type promise, waits for all of them to resolve, and only then bootstraps the application. Keep in mind that if one of the initializers fails to resolve, the application will not be bootstrapped.

Let’s use it in conjunction with getting the user’s data from the server and saving it in the store:

app.module.ts

In our case, we’re using Akita, so we save the data in our UserStore , but this method will work with any other provider.

Now, let’s add the splash screen itself. The idea is to add the splash screen code to our index.html file inside the <app-root></app-root> or whatever your mount point is, because Angular will remove whatever’s inside when it’s done loading the application:

And voilà! Our users have a nice splash screen to look at while we load the data in the background:

The benefit of this approach is that, because we’re inside Angular context, we can use the existing services and framework features.

A bit of advice: A nice addition to this feature would be storing the data in local storage, with an expired flag that indicates whether we should re-fetch the data from the server.

🦊 Using the Extra Providers Option

The second approach we could take is to go outside of Angular context. In the main.ts file, we initialize a request and bootstrap the application only when we have the required data. For example:

main.ts

This will work, but it’s not very useful as we’re missing the ability to access the data we’ve received in our application. We have two options for how to solve this; Let’s take a quick peek at the platformBrowserDynamic source code:

We can see that at this point, we can optionally pass extraProviders that will be available in our application. Leveraging this ability, we can do the following:

Note that unlike the previous approach, we don’t have access to other providers at this stage, so we create a new one and initialize it with the data. Then we can use it immediately, everywhere in the application:

app.component.ts