Angular

A Guide to (Typed) Reactive Forms in Angular - Part III (Creating Custom Form Controls)

Published Jun 26, 2023

Updated Jun 26, 2023

3 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

So far in the series, we have learned the basics of Angular Reactive forms and created some neat logic to construct and display dynamic forms. But our work is still not done yet. Whether we just want to make our controls look good and enhance them with some markup, or whether we need a more complex control than a simple textarea, input or checkbox, we'll either need to use a component library such as Angular Material Components or get familiar with the ControlValueAccessor interface.

Angular Material, by the way, uses ControlValueAccessor in its components and I recommend looking into the source code if you want to learn some advanced use cases (I have borrowed a lot of their ideas in the past). In this post, however, we will build a basic custom control from scratch.

A common requirement for a component that cannot be satisfied by using standard HTML markup I came across in many projects is having a searchable combobox. So let's build one. We will start by creating a new Angular component and we can do that with a handy ng cli command:

  ng generate component form-fields/combobox

Then we'll implement displaying data passed in the form of our FormField class we have defined earlier in a list and allowing for filtering and selecting the options:

// combobox.component.ts
import { Component, ElementRef, Input, ViewChild } from '@angular/core';
import { FormField } from '../../forms.model';

@Component({
  selector: 'app-combobox',
  templateUrl: './combobox.component.html',
  styleUrls: ['./combobox.component.scss'],
})
export class ComboboxComponent {
  private filteredOptions?: (string | number)[];

  // a simple way to generate a "unique" id for each component
  // in production, you should rather use a library like uuid
  public id = String(Date.now() + Math.random());

  @ViewChild('input')
  public input?: ElementRef<HTMLInputElement>;

  public selectedOption = '';

  public listboxOpen = false;

  @Input()
  public formFieldConfig!: FormField<string | number>;

  public get options(): (string | number)[] {
    return this.filteredOptions || this.formFieldConfig.options || [];
  }

  public get label(): string {
    return this.formFieldConfig.label;
  }

  public toggleListbox(): void {
    this.listboxOpen = !this.listboxOpen;
    if (this.listboxOpen) {
      this.input?.nativeElement.focus();
    }
  }

  public closeListbox(event: FocusEvent): void {
    // timeout is needed to prevent the list box from closing when clicking on an option
    setTimeout(() => {
      this.listboxOpen = false;
    }, 150);
  }

  public filterOptions(filter: string): void {
    this.filteredOptions = this.formFieldConfig.options?.filter((option) => {
      return option.toString().toLowerCase().includes(filter.toLowerCase());
    });
  }

  public selectOption(option: string | number): void {
    this.selectedOption = option.toString();
    this.listboxOpen = false;
  }
}

<!-- combobox.component.html -->
<label for="combobox-input-{{ id }}">{{ label }}</label>
<div class="combobox">
  <div class="group">
    <input
      #input
      type="text"
      role="combobox"
      (focus)="listboxOpen = true"
      (blur)="closeListbox($event)"
      (input)="filterOptions(input.value)"
      [value]="selectedOption"
      id="combobox-input-{{ id }}"
    />
    <button type="button" tabindex="-1" (click)="toggleListbox()">
      &#9660;
    </button>
  </div>
  <ul *ngIf="listboxOpen" role="listbox">
    <li
      *ngFor="let option of options"
      role="option"
      class="option-for-{{ id }}"
      (click)="selectOption(option)"
    >
      {{ option }}
    </li>
  </ul>
</div>

Note: For the sake of brevity, we will not be implementing keyboard navigation and aria labels. I strongly suggest referring to W3C WAI patterns to get guidelines on the markup and behavior of an accessible combo box.

While our component now looks and behaves like a combo box, it's not a form control yet and is not connected with the Angular forms API. That's where the aforementioned ControlValueAccessor comes into play along with the NG_VALUE_ACCESSOR provider. Let's import them first, update the @Component decorator to provide the value accessor, and declare that our component is going to implement the interface:

import { ControlValueAccessor, NG_VALUE_ACCESSOR } from '@angular/forms';

@Component({
  selector: 'app-combobox',
  templateUrl: './combobox.component.html',
  styleUrls: ['./combobox.component.scss'],
  providers: [
    {
      // provide the value accessor
      provide: NG_VALUE_ACCESSOR,
      // for our combobox component
      useExisting: ComboboxComponent,
      // and we don't want to override previously provided value accessors
      // we want to provide an additional one under the same "NG_VALUE_ACCESSOR" token instead
      multi: true,
    },
  ],
})
export class ComboboxComponent implements ControlValueAccessor {

Now, the component should complain about a few missing methods that we need to satisfy the ControlValueAccessor interface:

A writeValue method that is called whenever the form control value is updated from the forms API (e.g. with patchValue()).
A registerOnChange method, which registers a callback function for when the value is changed from the UI.
A registerOnTouched method that registers a callback function that marks the control when it's been interacted with by the user (typically called in a blur handler).
An optional setDisabledState method that is called when we change the form control disabled state-

Our (pretty standard) implementation will look like the following:

  private onChanged!: Function;
  private onTouched!: Function;

  public disabled = false;

  // This will write the value to the view if the form control is updated from outside.
  public writeValue(value: any) {
    this.value = value;
  }

  // Register a callback function that is called when the control's value changes in the UI.
  public registerOnChange(onChanged: Function) {
    this.onChanged = onChanged;
  }

  // Register a callback function that is called by the forms API on initialization to update the form model on blur.
  public registerOnTouched(onTouched: Function) {
    this.onTouched = onTouched;
  }

  public setDisabledState(isDisabled: boolean): void {
    this.disabled = isDisabled;
  }

  public setDisabledState(isDisabled: boolean): void {
    this.disabled = isDisabled;
  }

We don't have to update the template a lot, but we can add [disabled]="disabled" attribute on our button and input to disable the interactive UI elements if the provided form control was disabled. The rest of the work can be done in the component's TypeScript code. We'll call this.onTouched() in our closeListbox method, and create a value setter that updates our internal value and also notifies the model about the value change:

  public set value(val: string | number) {
    this.selectedOption = val.toString();
    this.onChanged && this.onChanged(this.selectedOption);
    this.onTouched && this.onTouched();
  }

You can check out the full implementation on StackBlitz.

Conclusion

In this series, we've explored the powerful features of Angular reactive forms, including creating and managing dynamic typed forms. We also demonstrated how to use the ControlValueAccessor interface to create custom form controls, such as a searchable combo box. This knowledge will enable you to design complex and dynamic forms in your Angular applications.

While the examples provided here are basic, they serve as a solid foundation for building more advanced form controls and implementing validation, accessibility, and other features that are essential for a seamless user experience. By mastering Angular reactive forms and custom form controls, you'll be able to create versatile and maintainable forms in your web applications. If you want to further explore the topic and prefer a form of a video, you can check out an episode of JavaScript Marathon by my amazing colleague Chris.

Happy coding!

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Jan Kaiser
Software engineer passionate about everything web-related. Particularly loves Angular, SCSS, TypeScript, soccer and dachshunds
@honzikec @honzikec

Overview of the New Signal APIs in Angular

Overview of the New Signal APIs in Angular Google's Minko Gechev and Jeremy Elbourn announced many exciting things at NG Conf 2024. Among them is the addition of several new signal-based APIs. They are already in developer preview, so we can play around with them. Let's dig into it, starting with signal-based inputs and the new matching outputs API. Signal Based Inputs Discussions about signal-based inputs have been taking place in the Angular community for some time now, and they are finally here. Until now, you used the @Input() decorator to define inputs. This is what you'd have to write in your component to declare an optional and a required input: ` With the new signal-based inputs, you can write much less boilerplate code. Here is how you can define the same inputs using the new syntax: ` It's not only less boilerplate, but because the values are signals, you can also use them directly in computed signals and effects. That, effectively, means you get to avoid computing combined values in ngOnChanges or using setters for your inputs to be able to compute derived values. In addition, input signals are read-only. The New Output I intentionally avoid calling them signal-based outputs because they are not. They still work the same way as the old outputs. The Angular team has just introduced a new output API that is more consistent with the latest inputs API and allows you to write less boilerplate, similar to the new input API. Here is how you would define an output until now: ` Here is how you can define the same output using the new syntax: ` The thing I like about the new output API is that sometimes it happens to me that I forget to instantiate the EventEmitter because I do this instead: ` You won't forget to instantiate the output with the new syntax because the output function does it for you. Signal Queries I am sure most readers know the @ViewChild, @ViewChildren, @ContentChild, and @ContentChildren decorators very well and have experienced the pain of triggering the infamous ExpressionChangedAfterItHasBeenCheckedError or having the values unavailable when needed. Here is a refresher on how you would use these decorators until now: ` With the new signal queries, similar to the new input API, the values are signals, and you can use them directly in computed signals and effects. You can define the same queries using the new syntax: ` Jeremy Elbourn mentioned that the new signal queries have better type inference and are more consistent with the new input and output APIs. He also showcased a brand new feature not available with the old queries. You can now define a query as required, and the Angular compiler will throw an error if the query has no result, guaranteeing that the value won't be undefined. Here is how you can define a required query: ` Model Inputs Jeremy and Minko announced the last new feature is the model inputs. The name is vague, but the feature is cool—it simplifies the definition of two-way bindings. Until now, to achieve two-way binding, you would have to define an input and an output following a given naming convention. @Input and @Output had to be defined with the same name (followed by "Change" in the case of the output). Then, you could use the template's [()] syntax. ` ` That way, you could keep the value in sync between the parent and the child component. With the new model inputs, you can define a two-way binding with a single line of code. Here is how you can define the same two-way binding using the new syntax: ` The html template stays the same: ` The model function returns a writable signal that can be updated directly. The value will be propagated back to any two-way bindings. Conclusion The new signal-based APIs are a great addition to Angular. They allow you to write less boilerplate code and make your components more reactive. The new APIs are already in developer preview, so you can start playing around with them today. I look forward to seeing how the community will adopt these new features and what other exciting things the Angular team has in store for us, such as zoneless apps by default....

Apr 3, 2024

3 mins

AngularJavaScript

Using HttpClient in Modern Angular Applications

Introduction With all the wonderful treats that the Angular team has given us during the recent "renaissance" era, many new developers are joining in on the fun. And one of the challenges they'll face at some point is how to call an API from your Angular application properly. Unfortunately, while searching for a guide on how to do this, they might stumble upon a lot of outdated information. Hence, this article should serve as a reliable guide on how to use the HttpClient in Angular >= 17. The Setup To make an HTTP request in Angular, you can take advantage of the HttpClient provided by the @angular/common/http package. To use it, you'll need to provide it. Here's how you can do that for the whole application using the bootstrapApplication function from @angular/platform-browser: ` With that, you should be good to go. You can now inject the HttpClient into any service or component in your application. Using HttpClient in Services Let's take a common example: You have a database object, say a Movie, and you want to implement CRUD operations on it. Typically, you'll want to create a service that provides methods for these operations. Let's call this service MovieService and create a skeleton for it with a method for getting all movies. ` Implementing the Method using HttpClient Let's assume we have a GraphQL API for our movies. We can implement our getAllMovies using HttpClient to make a request to fetch all movies. First, we will need to define a new type to represent the response from the API. This is especially important when you are using GraphQL, which may return a specific structure, such as: ` When working with a real API, you'll likely use some code generator to generate the types for the response from the GraphQL schema. But for the sake of this example, we'll create an interface to represent the response manually: ` Now, we can implement the getAllMovies method using HttpClient: ` > Note: The post method is used here because we are sending a request body. If you are making a GET request (e.g. to a REST API), you can use the get method instead. The getAllMovies method returns an Observable of MoviesListResponse. In this example, I have typed it explicitly to make it obvious at first glance, but you could also omit the type annotation, and TypeScript should infer it. > Note: While I'm excited about signals as much as the next guy, making HTTP requests is one of the typical async operations for which RxJS Observables are a perfect fit, making a great argument for RxJS still having a solid place in Angular alongside signals. Using the Service in a Component Now that we have our MovieService set up, we can use it as a component to fetch and display all movies. But first, let's create a Movie interface to represent the structure of a movie. Trust me, this will prevent many potential headaches down the line. Although using any at the beginning and implementing the types later is a valid approach in some cases, using data fetched from an API without validating the type will inevitably lead to bugs that are difficult to solve. ` Now, we can start implementing our standalone MoviesComponent: ` In this component, we are calling the getAllMovies method from the MovieService in the constructor to fetch all movies and assign them to the movies property which we will use to display the movies in the template. ` In this case, placing our code inside the constructor is safe because it doesn’t depend on any @Input(). If it were, our code would fail because the inputs aren’t initialized at time of instantiation. That's why it is sometimes recommended to place logic in ngOnInit instead. You could also put this call in an arbitrary method that is called e.g. on a button click. Another way to handle the subscription is to use the async pipe in the template. This way, Angular will automatically subscribe and unsubscribe from the observable for you and you won't have to assign the response to a property in the component. Due to the structure of the returned data, however, we'll need to use the RxJS map operator to extract the movies from the response. ` > Note using the pipe method to chain the map operator to the observable returned by getAllMovies. This is a common pattern when working with RxJS observables introduced in RxJs 5.5. If you see code that uses the map operator directly on the observable and wonder why it isn't working for you, it's likely using an older version of RxJS. Now, we can simply apply the async pipe in the template to subscribe to the observable and display the movies: ` Conclusion HttpClient in Angular is pretty straightforward, but with all the changes to RxJS and Angular in the past few years, it can pose a significant challenge if you're not super-experienced with those technologies and stumble upon outdated resources. Following this article, you should hopefully be able to implement your service using HttpClient to make requests to an API in your modern Angular application and avoid the struggle of copying outdated code snippets....

Mar 27, 2024

4 mins

AngularJavaScript

How to Run End-to-End Tests on Vercel Preview Deployments

How to Run End-to-End Tests on Vercel Preview Deployments End-to-end (E2E) tests are an essential part of modern web development. They simulate real user interactions and ensure your application works as expected in a live environment. When you're working with platforms like Vercel, which provide seamless deployment experiences, running E2E tests on preview deployments makes sense to catch any issues before merging your changes into the main branch. However, running E2E tests on preview deployments can be challenging as if the deployment isn’t ready when the tests start running, you’ll get errors when they should have succeeded. The Challenge: Timing Your E2E Tests Imagine you're working on a feature and pushing your changes to a branch. Vercel starts deploying the preview, and once that's done, you want to run your E2E tests automatically. But if the deployment isn't ready when the tests start, they might fail, and you'll be left wondering if the issue is with your code or the deployment process. Github Actions allow us to leverage a combination of actions that work together to ensure that your E2E tests only start once the Vercel deployment is ready. The Solution: Combining GitHub Actions for Seamless Testing To solve this problem, we can use two GitHub Actions in tandem: 1. vercel-preview-url: This action retrieves the preview URL of the Vercel deployment. It runs on push and pull request events, ensuring you get the exact URL of your deployment, which can then be used for further tests or other integrations. 2. github-action-await-vercel: This action waits until the Vercel deployment is marked as "READY". It continuously checks the deployment status, ensuring your tests only run once the deployment is fully prepared. ` Breaking Down the Workflow 1. Fetch the Preview URL: The vercel-preview-url action first retrieves the URL of the Vercel deployment. This URL is unique to the deployment, and we need to know it to run our E2E tests against the correct environment. This step ensures that we have the right URL before proceeding to the next steps. 2. Await Deployment Readiness: The github-action-await-vercel action waits for the deployment to be fully ready. It checks the deployment status at intervals (e.g., every 15 seconds) and only proceeds once the deployment is marked as "READY." This step ensures that your E2E tests don't run prematurely, preventing false failures. 3. Run E2E Tests: Once the deployment is ready, your E2E tests are executed against the live preview. By this point, you can be confident that the environment is fully set up, and any failures will likely be due to actual issues in the code rather than deployment timing. Why This Workflow Matters This workflow is essential for teams that rely on automated testing as part of their CI/CD pipelines. By waiting for the Vercel deployment to be fully ready, you minimize the risk of flaky tests that fail due to timing issues rather than code problems. This approach saves time and effort, as developers can focus on fixing real bugs rather than troubleshooting deployment issues. Moreover, this setup is flexible and can be adapted to various project needs. Whether you're running tests on a simple static site or a complex application, ensuring that your deployment is ready before running tests can dramatically improve the reliability of your CI/CD pipeline. Conclusion In modern web development, ensuring the reliability of your CI/CD pipeline is crucial. By leveraging GitHub Actions like vercel-preview-url and github-action-await-vercel, you can confidently run E2E tests on Vercel preview deployments. However, remember that the Vercel deployment can take some time to deploy, especially for larger projects, so use this approach wisely and ensure you only run it when necessary....

Sep 20, 2024

3 mins

InfrastructureVercelPlaywrightCypress

Introduction to Zod for Data Validation

As web developers, we're often working with data from external sources like APIs we don't control or user inputs submitted to our backends. We can't always rely on this data to take the form we expect, and we can encounter unexpected errors when it deviates from expectations. But with the Zod library, we can define what our data ought to look like and parse the incoming data against those defined schemas. This lets us work with that data confidently, or to quickly throw an error when it isn't correct. Why use Zod? TypeScript is great for letting us define the shape of our data in our code. It helps us write more correct code the first time around by warning us if we are doing something we shouldn't. But TypeScript can't do everything for us. For example, we can define a variable as a string or a number, but we can't say "a string that starts with user_id_ and is 20 characters long" or "an integer between 1 and 5". There are limits to how much TypeScript can narrow down our data for us. Also, TypeScript is a tool for us developers. When we compile our code, our types are not available to the vanilla JavaScript. JavaScript can't validate that the data we actually use in our code matches what we thought we'd get when we wrote our TypeScript types unless you're willing to manually write code to perform those checks. This is where we can reach for a tool like Zod. With Zod, we can write data schemas. These schemas, in the simplest scenarios, look very much like TypeScript types. But we can do more with Zod than we can with TypeScript alone. Zod schemas let us create additional rules for data parsing and validation. A 20-character string that starts with user_id_? It's z.string().startsWith('user_id_').length(20). An integer between 1 and 5 inclusive? It's z.number().int().gte(1).lte(5). Zod's primitives give us many extra functions to be more specific about *exactly* what data we expect. Unlike TypeScript, Zod schemas aren't removed on compilation to JavaScript—we still have access to them! If our app receives some data, we can verify that it matches the expected shape by passing it to your Zod schema's parse function. You'll either get back your data in exactly the shape you defined in your schema, or Zod will give you an error to tell you what was wrong. Zod schemas aren't a replacement for TypeScript; rather, they are an excellent complement. Once we've defined our Zod schema, it's simple to derive a TypeScript type from it and to use that type as we normally would. But when we really need to be sure our data conforms to the schema, we can always parse the data with our schema for that extra confidence. Defining Data Schemas Zod schemas are the variables that define our expectations for the shape of our data, validate those expectations, and transform the data if necessary to match our desired shape. It's easy to start with simple schemas, and to add complexity as required. Zod provides different functions that represent data structures and related validation options, which can be combined to create larger schemas. In many cases, you'll probably be building a schema for a data object with properties of some primitive type. For example, here's a schema that would validate a JavaScript object representing an order for a pizza: ` Zod provides a number of primitives for defining schemas that line up with JavaScript primitives: string, number, bigint, boolean, date, symbol, undefined, and null. It also includes primitives void, any, unknown, and never for additional typing information. In addition to basic primitives, Zod can define object, array, and other native data structure schemas, as well as schemas for data structures not natively part of JavaScript like tuple and enum. The documentation contains considerable detail on the available data structures and how to use them. Parsing and Validating Data with Schemas With Zod schemas, you're not only telling your program what data should look like; you're also creating the tools to easily verify that the incoming data matches the schema definitions. This is where Zod really shines, as it greatly simplifies the process of validating data like user inputs or third party API responses. Let's say you're writing a website form to register new users. At a minimum, you'll need to make sure the new user's email address is a valid email address. For a password, we'll ask for something at least 8 characters long and including one letter, one number, and one special character. (Yes, this is not really the best way to write strong passwords; but for the sake of showing off how Zod works, we're going with it.) We'll also ask the user to confirm their password by typing it twice. First, let's create a Zod schema to model these inputs: ` So far, this schema is pretty basic. It's only making sure that whatever the user types as an email is an email, and it's checking that the password is at least 8 characters long. But it is *not* checking if password and confirmPassword match, nor checking for the complexity requirements. Let's enhance our schema to fix that! ` By adding refine with a custom validation function, we have been able to verify that the passwords match. If they don't, parsing will give us an error to let us know that the data was invalid. We can also chain refine functions to add checks for our password complexity rules: ` Here we've chained multiple refine functions. You could alternatively use superRefine, which gives you even more fine grained control. Now that we've built out our schema and added refinements for extra validation, we can parse some user inputs. Let's see two test cases: one that's bound to fail, and one that will succeed. ` There are two main ways we can use our schema to validate our data: parse and safeParse. The main difference is that parse will throw an error if validation fails, while safeParse will return an object with a success property of either true or false, and either a data property with your parsed data or an error property with the details of a ZodError explaining why the parsing failed. In the case of our example data, userInput2 will parse just fine and return the data for you to use. But userInput1 will create a ZodError listing all of the ways it has failed validation. ` ` We can use these error messages to communicate to the user how they need to fix their form inputs if validation fails. Each error in the list describes the validation failure and gives us a human readable message to go with it. You'll notice that the validation errors for checking for a valid email and for checking password length have a lot of details, but we've got three items at the end of the error list that don't really tell us anything useful: just a custom error of Invalid input. The first is from our refine checking if the passwords match, and the second two are from our refine functions checking for password complexity (numbers and special characters). Let's modify our refine functions so that these errors are useful! We'll add our own error parameters to customize the message we get back and the path to the data that failed validation. ` Now, our error messages from failures in refine are informative! You can figure out which form fields aren't validating from the path, and then display the messages next to form fields to let the user know how to remedy the error. ` By giving our refine checks a custom path and message, we can make better use of the returned errors. In this case, we can highlight specific problem form fields for the user and give them the message about what is wrong. Integrating with TypeScript Integrating Zod with TypeScript is very easy. Using z.infer<typeof YourSchema> will allow you to avoid writing extra TypeScript types that merely reflect the intent of your Zod schemas. You can create a type from any Zod schema like so: ` Using a TypeScript type derived from a Zod schema does *not* give you any extra level of data validation at the type level beyond what TypeScript is capable of. If you create a type from z.string.min(3).max(20), the TypeScript type will still just be string. And when compiled to JavaScript, even that will be gone! That's why you still need to use parse/safeParse on incoming data to validate it before proceeding as if it really does match your requirements. A common pattern with inferring types from Zod schemas is to use the same name for both. Because the schema is a variable, there's no name conflict if the type uses the same name. However, I find that this can lead to confusing situations when trying to import one or the other—my personal preference is to name the Zod schema with Schema at the end to make it clear which is which. Conclusion Zod is an excellent tool for easily and confidently asserting that the data you're working with is exactly the sort of data you were expecting. It gives us the ability to assert at runtime that we've got what we wanted, and allows us to then craft strategies to handle what happens if that data is wrong. Combined with the ability to infer TypeScript types from Zod schemas, it lets us write and run more reliable code with greater confidence....

Nov 15, 2024

7 mins

JavaScriptZod

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

A Guide to (Typed) Reactive Forms in Angular - Part III (Creating Custom Form Controls)

Conclusion

Jan Kaiser

You might also like

Overview of the New Signal APIs in Angular

Using HttpClient in Modern Angular Applications

How to Run End-to-End Tests on Vercel Preview Deployments

Introduction to Zod for Data Validation

Let's innovate together!

You might also like

Overview of the New Signal APIs in Angular

Using HttpClient in Modern Angular Applications

How to Run End-to-End Tests on Vercel Preview Deployments

Introduction to Zod for Data Validation