DEV Community: Aaron Frost

You Should Upgrade to Angular 9 TODAY

Aaron Frost — Thu, 12 Dec 2019 00:42:43 +0000

The TL;DR Version

Let me open by briefly summarize my points of why you should upgrade today. I will cover each point in more detail lower in this article.

The Angular team is actively listening to feedback from people who upgrade today. Thus, if you are worried about having problems and may need help, then now is the perfect time for you to try it and have their help.
The testing cycle for this release of Angular has been one of legends. No prior version of Angular (including AngularJS) has ever gone through such a rigorous testing phase. This should help lessen your fears.
The Angular community will begin to evolve more quickly once v9 is here. You will miss some of it if you are not on v9.
The point of this release was to NOT provide new functionality, but to maintain the current. So you don't have to worry about massive API changes that will break you.

For those of you who have short attention spans (like me), I hope that this summary is enough to give you some talking points and/or enough to start thinking about the benefits of upgrading to Angular 9 today.

And for those of you who want more reasoning, keep going. The rest of this article is for you.

A Longer Reasoning

If you are going to update to Angular 9 once it is in general release 9.0.0, you should definitely do it today! Or you could wait until 9.0.1 or 9.1.0. But let me explain why I think that for this release specifically you should consider updating sooner, rather than later.

You Have Support From Google

Because 9.0.0 is in RC mode, the Angular team is actively watching the feedback from people upgrading. This means that if you upgrade today, they will be listening to YOUR feedback. And when you think about it, we would rather upgrade while they are still looking at it (before they have moved their focus onto 10.0.0). If you think your team may need some help from them, then TODAY is the time for you to upgrade.

In the past when I have upgraded during the RC phases, the Angular team is there listening to my issues, and asking to get on Hangouts so that they can see the issues I am dealing with. This could be you if you get on the upgrade today.

At the end of the day, what helped us determine when to upgrade? We wait until we think it is "safe". Well, if you are going to have issue upgrading, wouldn't you rather have the issues while the Angular team is here to help? In the scenario where your project DOES have an issue with the upgrade, you are more "safe" doing it earlier while you still have the active attention of the team.

If you try this and have an issue or any problems, you can file an issue on the angular repo, or you can try and chat with experts on the Angular gitter.

V9 Has Been Tested EXTREMELY Well

No version of Angular has been more rigorously tested than has been Angular v9. Not even the initial release of Angular v2 went through this thorough of a testing cycle. How could it have? When v2 was released, it had a fraction of the users that Angular v8 currently has. Inherently this means that the amount of community feedback that v2 received was inconsequential when compared the the number of projects running on v8 today.

So when you simply compare the number of RC and Beta users that v9 has had, it is the most tested version of Angular ever.

Additionally, thanks to the version control system used internally at Google, any time the Angular team releases a change to the framework, the tests of every project at Google that depends on Angular get executed. So thousands of tests across hundreds of projects get executed for each PR from the Angular team. Clicking "Merge" on those PRs must be stressful!

A few months ago, a member of the community who isn't familiar with Angular assumed that only React was heavily dog fooded prior to being released, when nothing could be further from the truth.

With each PR put into Ivy and Angular 9, if any of the hundreds of projects across Google broke, the Angular team had to fix those breaks before they could move on. Knowing that the Angular team and React team have massive amounts of projects to validate their changes should help us all sleep better at night.

Post v9 Community Will Change Quickly

I remember being at an Angular conference a few years ago, and joking with my friends about playing a drinking game every time someone said something about "Ivy will fix that".

We have been waiting for Ivy for years now. And now that it is here, all of the changes and evolutions that were in holding patterns waiting on Ivy can now land in the community. This means that we should see some really cool things coming from some of the smartest people in the Angular community once v9 is here.

And while that cambrian-explosion-esk event is happening in the Angular community, if you're sitting in Angular 6/7/8/other instead of being in 9, your project may miss out on some of the cooler new changes.

Now, I am not imploring you to join the entire Angular community and chase the pendulum. In fact, I have made a solid career of NOT chasing the pendulum. However, many of the changes coming soon will be HIGHLY beneficial for any Angular project.

Consider the following tweet by Sander Elias. If people like Sander make our life tons easier by introducing features like observable lifecycle hooks, you won't want to miss that. That's a game changer.

These kinds of changes will happen often and regularly now that Ivy is here. The arrival of v9 is like undaming the water in a lake. Cool new features should begin to flow into the community. You should encourage your team to be a part of that, and even participate with changes of your own.

What Makes This Release Awesome Is It's LACK Of Changes

Where almost all other releases of software are heralded and praised for what they add to the ecosystem, Angular's v9 release should be applauded for it's stability. The feature of v9 is it's LACK of features. What makes it so wonderful is it's lack of visibly wonderful changes.

Angular v9 was about making major changes under the hood of the framework, without having any outward changes on our code. The API surface should remain entirely unchanged (with the exception of the few documented changes that each have schematics to make the migration pain free). The point of the release is to have every app work the same as it did before.

Because this is the point of the release, it makes it a great time for your team and your projects to get on board early and be a part of the v9 upgrade party that is happening right now (before the official v9 release).

Conclusion

One of my favorite hobbies is that of fishing. I've been doing it since I was a kid. While I still have a lot to learn, you could call me an expert in ice fishing. And when I take my friends ice fishing for the first time, many of them need me to walk out on the ice and show them that it truly is safe, and that the ice is strong and more than capable of holding us up to have a fun day.

My intention in this article is not to throw guilt on those who aren't ready to update. Neither is my intention to disregard the concerns of some of those reading. We are all fighting a fight that no one else sees, and I don't pretend to understand all of what everyone is dealing with.

Rather, I want to walk out on the ice and show that it is strong and much more capable that some will give it credit for. As web developers, we stand on the backs of giants to build the projects we build. The Angular team has worked hard to make a good, solid, safe release for all of us. And I believe that they have succeeded.

If any of you have questions about joining me out here on in Angular v9 ice (ahead of it's official release), feel free to hit me on on Twitter. My DMs are open.

If you're ready to try this out, checkout the Upgrading to Angular 9 Guide.

Cheers!

Route-Fully-Rendered Detection in Angular

Aaron Frost — Mon, 04 Nov 2019 22:52:26 +0000

Background

One of the main pieces of profiling an app's performance is measuring how long it takes to route from one view to another *(more comments at end). If you can track over time your app's view-to-view rendering times, then you get the powerful, God-like ability to see at-a-glance when any of your routes have slowed down unexpectedly.

What are you measuring?

When you're measuring the time it takes to route from one view to another, what are you really measuring? While we could spend an afternoon discussing what the most important pieces to measure are, I am going to take another angle. Let me share the user story that I needed to solve.

As a user, I want to measure the time it takes from when I start to navigate until the next page is fully rendered.

So once the navigation starts, the user wants to know how long it takes until the next view is fully rendered. Great! Now that I know what I want to measure, how do I do this in Angular? Let's talk about how I detect these two distinct moments: Navigation Start and View Fully Rendered.

Detecting "Navigation Start"

All frontend frameworks that have a router make detecting the beginning of the navigation easy. Angular is no exception. In Angular, we can use the Router for this. The following is a code block that we can run to grab only NavigationStart events, and then track when that happens.



@Injectable({providedIn: 'root'})
export class PerfService {

    navStart$ = this.router.events.pipe(
        filter( event => event instanceof NavigationStart),
        startWith(null), // Start with something, because the app doesn't fire this on appload, only on subsequent route changes
        tap(event => /* Place code to track NavigationStart here */),
    ).subscribe();

    constructor(private router: Router) {}

}

In the above code, I am successfully detecting the start of navigation. Easy!

Now let's look at what we need to do when the next view is fully rendered.

Detecting "View Fully Rendered"

Angular doesn't provide a way for us to intrinsically know that a view has fully rendered. There isn't a lifecycle hook in Angular or React that says "All Things Accounted For, I am Fully Rendered!". The closest thing we have in Angular is AfterViewInit, which only tells you that the initial view of the component has been rendered. Any requests to the server will blow this away.

So now what?

A Too Simple Approach

The simplest approach to detecting when a view is fully rendered is to look at its code, and once all of the data has been retrieved and set onto your component, you can then say that this view is fully rendered.

But think about that...

You have to modify every single component in your app to detect and report its Fully Rendered event. That means three things:

You have to modify every top-level component in the app and teach it to report this event.
You have to create an audit so that no one on your team has forgotten to report this event on any future routes.
The code that reports this Fully Rendered action is spread throughout your entire application. 🤢

This was not a good enough solution. So let me tell you what I did. I wanted something that didn't require me to modify every component manually and distribute the detection code across the app. I wanted a federated approach that allowed all of the detection code to be collected into one place. So how can I do that?

An Accurate Approach to Fully Rendered

zonejs to the rescue! One great things about working with Angular is that you already have zonejs in your app. And for this problem, zonejs is PERFECT!!

When anything noteworthy happens in an Angular app, the NgZone will tell you that it is not stable. And once all of the noteworthy things have finished, it will tell you that it is stable again. So, once the NavigationStart fires, you can ask the NgZone to tell you once all of the noteworthy things have finished happening. This way you can distinguish between your app actively rendering the next view and when the app is done retrieving data and rendering the next view. SO COOL!

Anything noteworthy in Angular will create whats called a macrotask in the Angular zone. Any time we fetch new data or the component is deciding if it needs to re-render, a macrotask is created in the zone. So we can ask the zone if it has any macrotasks pending.

Note: I didn't use zone.isStable because sometimes the zone.isStable will return true, even when we have pending macrotasks. So it's better to look at the pending macrotasks.

Once the NavitationStart fires, you can use some code like this:



// Once NavigationStart has fired, start checking regularly until there are

// no more pending macrotasks in the zone

// Have to run this outside of the zone, because the call to interval

// is itself a macrotask. Running that interval inside the zone will

// prevent the macrotasks from ever reaching zero. Running this outside

// of Angular will not track this interval as a macrotask. IMPORTANT!!

this.zone.runOutsideAngular(() => {

    // Check very regularly to see if the pending macrotasks have all cleared

    interval(10)

        .pipe(

            startWith(0), // So that we don't initially wait

            // To prevent a memory leak on two closely times route changes, take until the next nav start

            takeUntil(this.navigationStart$),

            // Turn the interval number into the current state of the zone

            map(() => !this.zone.hasPendingMacrotasks),

            // Don't emit until the zone state actually flips from false to true

            distinctUntilChanged(),

            // Filter out unstable event. Only emit once the state is stable again

            filter(stateStable => stateStable === true),

            // Complete the observable after it emits the first result

            take(1),

            tap(stateStable => {

                // FULLY RENDERED!!!!

                // Add code here to report Fully Rendered

            })

        ).subscribe();

});

Voalá

At this point, we have detected both the NavigationStart as well as the Fully Rendered moments. We can now use something like PerfumeJS to begin measuring these times. Once PerfumeJS measures the times, we need to stick those into our analytics database so that we can begin to track these over time.

Viewing this data over time on a per-route basis allows you to understand you apps in very meaningful ways. If an API ever slows down, the views affected will load slower, and this test will tell you. If someone checked in some bad code that is killing the app performance, this will tell you.

I invite everyone to begin checking out their apps performance and using approaches like this to do that.

Afterthought

In your app, if you have any long running setInterval calls then it is possible that the macrotasks never settle in your app. If this method doesn't work for you, then you have other issues in your app. It is very easy to find a third-party component or library that will have a setInterval that will prevent your app's zone from ever settle back to zero pending macrotasks. How to find and fix these issues is the topic of another blogpost, another day. If anyone is in this situation and would like to chat about getting it fixed, please DM me on twitter :)

Extra Thoughts

* Regarding the most important things to measure on your apps performance... there are a lot of things to measure. Things like time to first byte or time to first meaningful content. This post is not to declare that this is the most important piece of frontend performance measuring. It is, however, something that should matter when you look at how your app is performing.