I wrote a few entries about standalone components in this newsletter. Today, I wanted to send you a Standalone Components Cheatsheet that lists everything you need to know about standalone components in Angular:
This PDF was written for the upcoming ng-conf conference. You can download it here.
So far, we have covered several RxJs operators and information about Subjects, but what about Observables themselves?
There are a few utility functions that create Observables out of existing data. Such Observables immediately return the data and complete upon subscription.
Here is an example of such an Observable created with the of() function:
And an example created with the from() function:
The difference between of() and from() is that of() emits all the data right away in a single emission, whereas from() uses an array of items and emits them one by one with no delay between emissions.
In other words:
What’s the point of an Observable that just returns data instantly and does nothing asynchronous? First is testing. Being able to return to an Observable with hard-coded data is perfect for unit testing purposes as we can quickly validate different scenarios without using the actual HttpClient, for instance.
Second is caching data and returning it as an Observable (which can be done even more easily with a BehaviorSubject or ReplaySubject). For instance, say we have a service that retrieves a list of all countries in the world from a server. We know that that list doesn’t change every day, so we want to cache it so that if another component requests that data, instead of making another HTTP request, we return an Observable of that data:
Note the use of the tap operator to spy on the Observable, catch the data, and store it in our “cache” variable.
That way, the API is consistent and components always subscribe to an Observable, not knowing if the data comes from a server or a local cache.
Earlier in this newsletter, we covered how to handle errors with RxJs Observables. What about errors in the rest of the application? Javascript has a primary try/catch mechanism, but this doesn’t help handle errors in a generic, unified way.
Fortunately enough, Angular has an ErrorHandler interface that can be implemented by global error handler services such as this one:
That way, we can implement a catch-all method to deal with errors and display them to the user consistently (code example here). Even better, such a service could report errors to a server for further investigation and debugging from the dev team.
Here is a link to my custom error-handling tutorial to see a good example of how to implement a ErroHandler service.
After talking about how to create Signals, how to update them, and how to derive a Signal value from other Signals, let’s look at how we can register side effects out of any number of Signals.
Enter effect(). The behavior of effect() is almost the same as computed(), with one major difference: computed() returns a new Signal, whereas effect() doesn’t return anything.
As a result, effect() is suitable for debugging, logging information, or running some code that doesn’t need to update another Signal:
You can see that code in action here on Stackblitz.
Note that trying to update a Signal within an effect() is not allowed by default, as it could trigger unwanted behavior (infinite loop such as SignalA triggers update of SignalB that updates SignalC that updates SignalA – and around we go).
That said, if you know what you’re doing and are 100% sure that you won’t trigger an infinite loop, you can override that setting with the optional parameter allowSignalWrites as follows:
This is one of the most common mistakes I see with my training/consulting clients. When deploying code to production, they would use the command: ng build.
Instead, you want to use: ng build --configuration=production
Why is that? Because a production build is optimized in several ways:
This code is as lightweight as possible (no tabs, whitespace, new line characters, variables have super short names, etc.) and a lot more challenging to understand (a hacker would have a harder time understanding your code).
2. The code gets tree-shaked. Angular removes unused dependencies and dead code and makes your build output as tiny as possible. Size matters on the web: The less code you ship to a browser, the faster it gets downloaded, parsed, and interpreted (which is also why Angular gives us lazy-loading capabilities)
3. Source maps are not generated in that same spirit of hiding what our source code looks like.
4. Angular DevTools are disabled on that code, again for obfuscation and reverse-engineering purposes.
If you’re still not convinced after reading all of this, give it a try on your Angular projects. The size of your dist folder after a production build should be at least 90 to 95% smaller compared to a regular build, which is massive.
A few months back, I suggested that Angular developers don’t use enough directives and use too many components. This is because components quickly become second nature when writing Angular code, while directives are less common and, as a result, can feel more complex at first.
The critical difference between components and directives is that components have an HTML template, and directives don’t. That lack of a template can be slightly uncomfortable at first unless you realize that you still have access to HTML attribute bindings but in a different manner.
For instance, let’s consider the following component template:
Those two bindings used in a directive would become:
In other words, when you see a binding with [] in a component, @HostBinding() does the same thing in a directive.
For example: [id]="testId" in a component template becomes @HostBinding("id") testId; in a directive class.
The same goes for event listeners. This component (click) binding:
Becomes the following in a directive:
As a recap: [] become @HostBinding and () become @HostListener. Those are the same thing. That’s it. No template is needed. For a real-life example of a custom directive, feel free to take a look at this tutorial of mine.
A few days ago, we saw that we could be notified of any error when subscribing using a specific callback function or that we could receive the same information using the tap operator.
There is another option available using a specialized operator called catchError and illustrated below under its deprecated name catch:
How does catchError help? As we can see in the marble diagram, it can return a different Observable when an error happens. This means that the subscriber would have no idea that something wrong happened as we are able to switch to a backup solution (perhaps some cached data or a different API endpoint).
This is especially important when you know that if an Observable throws an error, it will never emit another value in the future. This makes catchError an excellent option to recover or at least attempt to recover from an error in the browser. We will cover other options (such as operators that retry an Observable) in the subsequent editions of the newsletter.
After introducing how to create Signals and how to update them, let’s take a look at one more exciting feature that helps replace the need for RxJs Observables.
How to emit a new Signal value when one or more Signals get updated? That’s what computed() does. In my Signals course, I illustrate computed() with the following example:
In the above code, this.rates() and this.currency() are two different Signals. this.rates() emits up-to-date exchange rates for all currencies in the world. this.currency() emits the current currency selected by the user.
computed() takes a function as a parameter. The function returns the computed value from my two Signals; in this case, the up-to-date exchange rate for the current currency. If the exchange rates or the currency get updated, this computed Signal will emit an updated value automatically.
This is somewhat similar to combining several Observables and using switchMap or combineLatest to get a customized result. It’s a lot easier with Signals (one line of code!).
If you’re considering attending a tech conference and have never done so before, I would suggest going to ng-conf 2023 in Salt Lake City this June (also available online if you can’t travel to beautiful Utah):
You know what I’m talking about if you have attended ng-conf before. It is the largest Angular conference in the world, the Angular team is there, and the best Angular speakers are on stage (I can say so because I’m not speaking this year – but I’m going anyways!).
I have learned so much at ng-conf in the past. Several tips and tricks of this newsletter were gathered at the conference. It is safe to say that this conference helped me get where I am today as an Angular coach and consultant. The organizers go above and beyond to ensure everyone is welcome at ng-conf; the experience is always a blast.
After all, they’ve even brought a Back to the Future Delorean and a Daft Punk tribute concert to the event in the past few years – to name a few examples:
If you’re attending the conference, please let me know and come say hi. It’s always a pleasure to meet my readers. And if you’re not going… You’ll still get updates from the conference in this newsletter!
While services and dependency injection are good, just like many good things in life, they can be over-used and become somewhat of an anti-pattern.
Why? Because of how change detection works in Angular. Angular has two modes for change detection: The default mode and the onPush mode. onPush is an optimization that works if and only if you’re using input-driven components, also known as presentation components.
In other words, whenever you inject a service into a component, you prevent that component from using the optimized onPush change detection mode. This is one of the reasons best practices recommend sticking with container components (service-driven components tied to specific use cases) and presentation components (input-driven ones that can be used and reused as they’re not connected to any service – and any business logic).
The more presentation components you create, the more reusable your code is, and the more change detection can be improved. The next time you inject a service in a new component, think again: Could I pass that data as @Input(s) instead of injecting a service?
If so, congratulations: You just prevented your presentation component from falling into this anti-pattern.