Category: Angular

Custom form validation functions

Alain Chautard

Let’s continue our dive into Angular form validation capabilities. So far, we have seen how to display custom feedback to the user based on basic HTML validation features. Today, let’s see how to customize the validation itself.

The good news is that all we need is a function. That function takes a FormControl as a parameter and returns null if the value entered by the user is valid. If the value is invalid, we return a ValidationErrors object, any key/value object we want.

Here’s an example:

Pretty straightforward, right? If the zip code is wrong, we return an object with a custom error message. Otherwise, we return null.

Of course, we can validate more precisely by adding several different checks and specific error messages for each case:

Then to have a specific input use that validation function, we can pass it as a parameter to the FormControl constructor like so:

And then such FormControl gets bound to the proper input in our HTML template (this is the approach for reactive forms – we will cover a method that works for template-driven forms tomorrow). We can then add some error handling by using the errors property of our FormControl, which is going to have the ValidationErrors object returned from our validation function:

Now our form provides custom feedback using our custom validation function:

You can access the code for the above example on Stackblitz.

Implementing custom feedback to form validation with Angular

Alain Chautard

Yesterday, we saw that Angular uses six different CSS classes (actually, eight – I didn’t mention ng-pending, which is the temporary state when async validation is being performed, and ng-submitted, which applies to the form element only).

Today, let’s see how we can customize the feedback displayed to the user beyond CSS classes. The nice thing about Angular validation properties is that they’re not just available as CSS classes. They are also available as public properties on the ngModel and the ngForm directives used in our form.

We can access such properties using template reference variables to access the exported values of these directives as follows:

The above code would result in the following rendering:

Of course, displaying true or false is not very user-friendly. Instead, we can use *ngIf and make the experience a little more polished:

Which looks like this:

We can apply the same idea to the form element and decide to disable the submit button as long as the form is invalid:

Or we could even hide the button as long as the form is invalid:

You get the idea. As simple as those validation properties are, they enable many possible different customizations of how we display validation feedback and hints to the user.

You can play with my code example on Stackblitz.

Basic form validation with Angular

Alain Chautard

Validating user input in HTML forms can be a tedious task. In this new series, we’ll look at how Angular can help us implement painless form validation.

First, it’s essential to know that Angular relies primarily on native browser validation features that use modern HTML properties. For instance, if a form field has to be filled out, you can mark it as required using the required HTML attribute:

If the user input has to match a specific format, you can specify such format using the pattern attribute, which uses a regular expression syntax – here, a 5-digit number

Other available HTML validation attributes are min, max, minlength, maxlength. You can also set the input type to something more specific than text, such as email or tel for additional validation and capabilities. Here is the list of all possible input types.

Once you have specified your validation rules using such attributes, Angular is going to toggle some CSS classes on the corresponding HTML elements automatically: ng-valid when the entered value is valid, and ng-invalid when the entered value is invalid.

This means that all we have to do to provide visual feedback to the user is implementing such classes in our CSS stylesheets:

The above CSS classes result in the following styling of form inputs:

If we want to fine-tune the rendering of our form based on whether the user has already typed something or not, there are additional classes added by Angular for such purposes:

  • ng-pristine: true when the user has not changed the element value
  • ng-dirty: opposite of pristine — true when the user has altered the element value
  • ng-touched: true when the user has put focus on the element (say clicked on it) and then removed the focus from the element (clicked away from it)
  • ng-untouched: Opposite of touched — means the user hasn’t put focus on the element or hasn’t removed that focus yet.

Using combinations of these classes is powerful. For instance, here is how we could add the error styles only once the user has “touched” an input:

Which results in the following default rendering:

And then once the user has typed something and removed the focus from the element:

You can try a few live examples using the code from this Stackblitz repo. Tomorrow, we’ll see how to do more than just CSS styling using those validation properties.

Creating a dialog in two lines of code

Alain Chautard

The theme of our week so far is that we don’t always need to think just in terms of components. We saw that directives and CSS selectors can be powerful tools to keep in mind.

Today, I’m going to show how modern HTML and template reference variables can do a lot of work for us with very little code.

Dialogs and modal windows have been a pain to work with for a very long time on the web. Not anymore though.

Here are a few lines of code that makes it all work painlessly:

dialog is a modern addition to HTML with a simple API: show(), showModal(), close(). The above code creates a template reference variable #dialog to get access to the dialog element, and then we call dialog.showModal() to open a modal window. That’s it. No dependency is needed, no CSS trick to create an overlay, no component library, and no jQuery.

Here is a link to a fully working example and a slighter longer tutorial with styling information for HTML dialogs.

The power of Angular selectors

Alain Chautard

Yesterday, we saw how using directives instead of components can increase code reusability by not tying our code logic to a specific HTML template.

Now, if we want to write some code once and for all and make it work for all HTML elements in our app that match some specific conditions, we have another underused tool at our disposal: CSS selectors.

For instance, let’s say we want the isActive directive from our previous example to be applied to all buttons in our application. Of course, we could manually look for all buttons and add the isActive attribute to them, but that would be tedious and error-prone.

Or we could be more imaginative and change the selector of that directive so that it applies to all buttons and any other elements that have an isActive attribute:

With that implementation, all current (and future) buttons will have that directive applied to them. But what if we want to make any exceptions and disable the directive on some buttons? That’s how we could do it:

Then all we would need is to add the disableIsActive attribute to those buttons that don’t want the isActive directive:

My point here is that there are some creative use cases for CSS selectors, and those selectors are the same as those used for CSS styling, meaning that we can rely on classes, attributes, element names, or any combination of the above!

The Angular framework does precisely that in quite a few places. If you’ve ever wondered how forms get auto-magically handled by Angular, now you know the answer. The ngForm directive has a complex selector that would apply to all form elements by default:

When to create a directive vs. a component?

Alain Chautard

Most Angular applications are composed of a majority of components and just a few directives if any. Today, I’d like to show you an example where a directive makes much more sense than a component.

Consider the following component template:

We have created a component tied to one single HTML element (button), and all the logic in that template is about changing attribute values (for the isActive class and the disabled attribute).

To achieve this, we needed three specialized inputs that resulted in a loss of reusability:

The above isn’t ideal because:

  • Our button can only display text, not any HTML (so no icons, for instance)
  • Our button assumes that its state always depends on saved and hasError, but what if we want to add a third variable to the mix for other use cases?

Let’s create a directive instead:

Which would be used like so:

This implementation is a lot better because:

  • It would work with any HTML element, not just buttons (assuming the element supports disabled properly)
  • The button can display anything, not just text
  • The criteria for isActive to be true depends on the use case and isn’t tied to just saved and hasError.

The point here is that using a directive in that scenario made our code more flexible, and as a result, more reusable. That’s why popular component libraries rely heavily on directives rather than components. Here’s an example from the Angular Material documentation:

You can see that mat-button is a directive, not a component. That way, it can be used with a button or an a tag. You can find the example code of this post on Stackblitz.

Think about this the next time you’re tempted to create a component with one or two lines of HTML in its template. Most likely, what you need instead is a directive.

Check out this tutorial for another example of a directive that makes perfect sense instead of using a component.

Change detection for Angular components

Alain Chautard

Angular comes with two component change detection strategies: default and onPush.

Default is used by default: Angular will check if your component needs to be refreshed every time something happens in the browser. Zone.js triggers such change detection by notifying Angular when a DOM event happens (someone clicked on a button) or a setTimeout completes, or an HTTP request completes.

In other words, any time a callback function runs in the browser, Angular will check if our components need to be re-rendered with new data.

With onPush, the change detection behavior changes. onPush indicates that our component only relies on inputs to display data (in other words – it’s a presentation component) and that DOM events or HTTP requests do not impact the HTML rendering of that component.

As a result, you can use onPush to improve the performance of your presentation components, which is another good reason to follow the presentation vs. container components approach covered yesterday. The official documentation here shows an in-depth dive into change detection strategies.

Container vs. Presentation Components

Alain Chautard

One of the fundamental concepts of component architecture in Angular applications is to find the right balance between container and presentation components.

Let’s define what those are:

  • Presentation components are reusable, simple pieces of UI. Think buttons, dialogs, cards, nav bars, etc.
  • Container components are the exact opposite: They’re not reusable. They’re tied to a specific use case. Those are usually entire screens or sub-screens, the app component, etc.

From a code standpoint, container components use services to interact with the back end. Such components know where to get the data using those services and then feed that data to their children using inputs, which are presentation components:

A simple way to identify those components is that presentation components only have inputs and outputs, no dependency injection. Container components have dependencies injected and most likely no inputs or outputs.

When to use container vs. presentation components?

Suppose you have components that are good candidates to become presentation components but are using services. In that case, you can most likely inject that service in its parent container and then pass the data to said component using an input. That way, your presentation component will be reusable in other places without being tied to a specific use case.

Of course, just like with any best practice, there are exceptions to consider. There are times when reusability makes sense and others when it does not. Do not force your components into one of these categories if it doesn’t make sense, but give it a try if it’s a quick win. Your application architecture (and possibly performance – stay tuned for more on that soon) will thank you later.

How to update my version of Angular?

Alain Chautard

Yesterday, we mentioned why it’s essential to keep your version of Angular as up-to-date as possible.

Today, we’re going to see how to do that. A concise answer would be to use the instructions at https://update.angular.io because that’s where all the information is. You can select your current version, the one you want to upgrade to, click a button, and you get a detailed TODO list as a result:

A typical upgrade consists in:

  1. Upgrading your current version of the Angular CLI: npm install -g @angular/cli@latest
  2. Upgrading your project code to the latest version: ng update @angular/core@latest @angular/cli@latest

The ng update command will update Angular and its dependencies and even change your code if the new version of the framework has some breaking changes (meaning that some functions or classes have been renamed or replaced with something else). Yes, it’s all automatic!

There are some scenarios where the upgrade can be more difficult:

  1. For example, if you have dependencies that are not maintained anymore or that get upgraded weeks/months later – something I’ll address in a later edition of this newsletter.
  2. If a Node.js upgrade is needed by Angular, which means upgrading your dev environment and continuous integration servers.

Again, the key is to stay as up-to-date as possible to make your upgrades a 5 to 10-minute task every six months rather than a 2-week deep dive every few years.

Angular Release Schedule

Alain Chautard

Angular is constantly evolving. A quick look at the release notes of the framework shows that new releases are happening every week. For example, yesterday, we mentioned the latest updates of Angular 15.1.

Let’s talk about how often Angular is released. The main release cadence is the following:

  • Major version every six months (Angular 16 is released six months after Angular 15)
  • Minor versions every month if needed, usually 1 to 3 between each major version (Angular 15.2 is released a month after 15.1)
  • Patch versions every week if needed (Angular 15.1.1 is released the week after 15.1.0)

This is important because you can plan your upgrades based on that cadence. For instance, some of my consulting clients plan the major releases of their applications twice a year, one month after they get a new version of Angular.

It’s also important to know that major versions are supported for 18 months. This is for critical fixes and security patches only. New features and improvements are added to a major version during its six months lifespan.

As of today, here are the actively supported versions:

If you’re using any version older than 13, you’re out of the support window and potentially exposed to bugs, vulnerabilities, and other issues. As a result, it’s always recommended to use the latest major version as much as possible or as a plan B to stay one or two major versions behind, but not more.

You can read the entire rationale behind that approach as well as more information about Angular’s release schedule here: https://angular.io/guide/releases