When it comes to running “one off” startup methods when your Angular Application starts, everyone will tell you to use the “APP_INITIALIZER” token. That’s all well and good to be told that, but when you actually check the documentation, it’s a little sparse…

Admittedly there is a bit more on the token scattered around in other documentation pieces, but they are surprisingly hard to find and again, typically only lightly touch on actual real world usage. So consider this a beginners guide on how to use APP_INITIALIZER in your own app.

The Basics

The first step is to create our startup function. For the purposes of this article, I’m going to create a simple function that itself, returns a function to run.

It’s important that the function itself returns a function!

In our main module (typically AppModule), we want to add a provider to our NGModule decorator. For example :

Ignore the fact I don’t have any declarations, I’ve removed them so it doesn’t clutter things up. Now a couple of things to note here.

  • We are adding a provider with the key of APP_INITIALIZER
  • We are setting the “multi” flag to true as we may have multiple APP_INITIALIZER’s to run.
  • And finally we are telling it to use the startmeup method to create the method we want to run.

Running our application now, we should see a console message of “Started!” as soon as the page loads.

UseValue vs Use Factory

It may look strange for our startup method to itself return a method. It seems a bit silly to box things up like that. Why not just run the startup code itself? Well you can do that (With some caveats).

For example, we could change our startmeup function to look like so :

Then we can change our provider line to “useValue” instead of “useFactory”

The main problem you run into with this method is that it’s much harder to use dependencies. We’ll talk about that a little later on. For now, just know you can do either but there are certainly pros and cons for each. Typically I find factories provide me the most versatility.

Inline Methods

It’s obviously worth noting that you don’t need to create an entirely new function variable/object, and you can instead do it all inline.

For the useValue route, you can use :

To do the same thing with factories does look a little messier because you need to return a method that returns a method… So the nesting can look a bit extreme but in general it looks like :

Using Dependencies

It’s possible, but unlikely, that your startup method can run on it’s own with no dependencies. But it’s probably a whole lot more likely that you are going to require either outside services of your own, or Angular’s own helper services. HttpClient for example.

You can inject these into your startup factories. Note that you cannot (easily) inject dependencies when using useValue. Your application won’t blow up, but your dependency will be undefined. There are ways around this but it’s the primary reason to stick with useFactory.

As an example of using dependencies, I can rewrite my startup factory like so :

And I can modify my provider line adding in the “deps” field :

This allows Angular’s built in DI to inject in HttpClient to my startup method which is extremely handy!

Calling Startup Methods Of Services

So, exporting functions all over the place is sort of rough. And it’s pretty likely that we want to bootstrap an actual service (Maybe to reach out and grab configuration values etc). To do that, we can create a class that holds our startmeup factory. We also need to mark it as Injectable.

When adding our provider line, we now instead set our dependency to be the StartupClass (The additional dependency of HttpClient will be resolved behind the scenes when requesting the StartupClass). We still call useFactory as we still have to tell it which particular method we want to run on startup.

Note that our method is actually still returning a function itself. This can be a bit off putting to read in this way so we can change it to instead simply run it’s startup calls :

And then modify the provider line to instead create a factory in of itself :

Notice the additional () to create a method within the useFactory line.

Using Promises

A pretty common scenario for startup methods is reaching for configuration values. That could be from a file, local storage, a cookie etc. And it’s highly possible that these methods are async in nature. As an example below, I’ve modified my startup method to read a settings file.

Note that the await promise line is simply to make it “seem” like it’s taking a long time to complete it’s job. e.g. It’s a slow startup task. In a real world example this wouldn’t be there.

Let’s also go to our main app component and write an NgOnInit method that simple writes to the console log.

Now let’s pause for a second and think. If we run our app right now, what will be written to the console first? The “Configuration loaded” message or the “On Init” message. Well logic would tell us that surely our message that our configuration loaded will run first because we’ve told Angular that the startmeup method should be loaded before everything else.

Well that is wrong.

The problem is that the http get method returns an observable to tell us when it’s complete. And we aren’t waiting for that to finish at all.

The general pattern is to use promises and return that promise to the APP_INITIALIZER. So as an example :

Here we are returning a promise from our method. The App Initializer will actually wait until this promise is resolved before continuing on. If we refresh our page now, we will notice that not only does the “On Init” message come after the “Configuration loaded” message. But the page itself is blank for 5 seconds (Because of our fake sleep to emulate a long http call) because all progress is halted until startup is complete.

This may sound bogus to halt an application like this. But the general idea is that the “majority” of work from your Angular application would not actually be able to take place until the startup method is resolved. For example if you are using telemetry like New Relic, Raygun, Application Insights etc. You really should have the token loaded and App Insights running before attempting to do other work. Otherwise if your application crashes, there is now a race condition as to whether you have all the necessary information to log the error or not.

Usage Outside Of Single Page Apps

As we saw above, the use of APP_INITIALIZER essentially halts the loading of a page until complete. In a true Single Page App (SPA), this is fine because it’s only really going to happen once on the initial load. If you are making use of Angular’s router for instance, then the App Initializer won’t be called again until a proper browser refresh occurs.

Obviously this isn’t the case if you are doing full page reloads. Every page load will re-load the angular app, and therefore kick off the startup process again. Be wary of using the APP_INITIALIZER token in these situations as it can severely slow down your application on every single page load.

I get this little error almost daily when working in Angular (Particularly in VS Code).

The first time I got the issue, it drove me mad as I was copy and pasting code from another file where it was working just fine, yet in my new code file everything was blowing up.

As it turns out, NodeJS has it’s own version of “EventEmitter” that is not generic. When using VS Code or other IDE’s that have auto completion, they will sometimes pick this EventEmitter to import rather than the one from Angular. The way to check is to see what your import statement looks like. It should be coming from @angular/core :

In my (broken) case, it was :

In actuality, there are a couple of EventEmitter objects. For example another half broken example would be :

So just check exactly where you are importing EventEmitter from to get around this pesky error!

When I first picked up Angular many years ago, one of the more frustrating aspects was that on using the router to navigate to another page, the scroll position was kept. This meant you were taken to the new page, but you would be scrolled halfway down the page (Or often right at the bottom if you were filling out a form).

Back then, you had all sorts of crazy fixes involving listening for router events, or maybe even manually scrolling the page. So recently when I ran into the issue on a new project I hoped things had changed. And they have, sort of. I mean, the issue is still there but there is a slightly more elegant fix.

When registering your router module (Typically a new Angular project created using the CLI will have an app-routing.module.ts), you can now edit your import as follows  :

In future versions of Angular, it’s hoped that this will become the default (Certainly there would be far more use cases of scrolling to the top over keeping the same position), but as of writing you still manually need to add the scrollPositionRestoration param.

Note that this was introduced sometime in Angular 6, for earlier versions (Which hopefully you aren’t creating new projects on), you will still need to do the old school subscribe method. To do this, you need to modify your main component (Often your AppComponent) to subscribe to the router event of NavigationEnd and then call scroll.

Again this is required only if you are running a version of Angular before 6!

As part of a recent project, I was asked to limit the type of characters that can be input into a text field. I had a quick search around but every single time I thought I had found a solution, it was some form of using the pattern attribute to simply show if invalid characters had been input, but it didn’t actually stop the user from typing them in the first place.

Now, I know that sometimes this can be a bit of an anti-pattern as a limiting the users input like this can be frustrating when you don’t show any warning or validation message, but there are some valid use cases.

The Directive Code

Below is the actual directive which you can add into your Angular project. In my case, I’m developing in Angular 8, but this should work in any modern Angular version.

A quick rundown of the code :

  • I’m using the selector of “inputrestriction” and I’ve made the input variable itself be called the same. Change as you require.
  • The input string takes a regex pattern to match on *allowed* characters.
  • I’m using the host listener to listen for a key press and deciding to allow it or not.

Usage Examples

We can then crack on with some really simple use cases such as letters only :

Or numbers only :