DEV Community: kasual1

Card Composite via @ViewChildren in Angular

kasual1 — Thu, 07 Dec 2023 21:22:41 +0000

Imagine the following requirements for your Angular app:

Your customer wants a view that displays multiple cards at once.
A button at the top of the page should toggle the edit mode.
While in edit mode, all cards are editable at the same time.
As soon as you click "save" only those cards that actually have been edited are going to send a request to the server.
If you decide to discard the changes by clicking on "cancel" all cards should be reset to their initial state.

This is a common scenario in any more sophisticated web application. Nevertheless, I just recently discovered a very handy way to handle those requirements in Angular. In this article I want to share my solution, leveraging the @ViewChildren property decorator to implement the Card Composite pattern.
Find the whole example: here

Implementing a specific card component

Before we implement the card composite component, lets start with the implementation of its cards. We begin with the simple implementation of a single card, but since the card composite component will need to access the same functionality across every card, we later refactor our code into a base component class.

export interface User {
  firstName: string;
  lastName: string;
  age: number;
}

<h4>Card Title</h4>

<form #form="ngForm">
  <label for="firstname">Firstname</label>
  <input
    name="firstname"
    [disabled]="!inEditMode"
    [(ngModel)]="user.firstname"
  />

  <label for="firstname">Lastname</label>
  <input
    name="lastname"
    [disabled]="!inEditMode"
    [(ngModel)]="user.lastname"
  />

  <label for="age">Age</label>
  <input
    name="age"
    type="number"
    [disabled]="!inEditMode"
    [(ngModel)]="user.age"
  />
</form>

@Component({
  selector: 'app-user-card',
  templateUrl: './user-card.component.html',
  styleUrls: ['./user-card.component.css']
})
export class UserComponent implements OnInit {
  @Input()
  inEditMode: boolean = false;

  @Input()
  title: string = 'User';

  @ViewChild('form')
  form!: NgForm;

  user!: User;

  unchangedUser!: User;

  constructor(private userService: UserService) {}

  ngOnInit() {
    this.loadUser();
  }

  loadUser(): void {
    this.user = this.userService.getEntity();
    this.unchangedUser = { ...this.user};
  }

  save(): void {
    if (this.form.dirty) {
      this.entityService.setEntity(this.user);
      this.unchangedUser = { ...this.user};
    }
  }

  cancel(): void {
    this.user = { ...this.unchangedUser };
  }

}

Notice: For simplicity reasons, the services used in this tutorial only sets or gets an entity from local storage. In a real application they would most likely fetch the entity from server.

In the code above we have inEditMode as an input property to control whether or not the card's form controls should be disabled. Since we use two-way data binding, changes in the form are immediately reflected in our User entity. Therefore, in order to reset the User to its initial value, we need to make a copy after loading the User on init.
The card composite component is later going to leverage the save and cancel functions of a card to execute respective behavior.

Refactoring the card component to a generic base component

With all this functionality in place we are already good to go. We could just copy the code from the UserCardComponent and reuse it to create more cards, that share the same save and cancel behavior. Nonetheless, as an aspiring programmer a good practice is to reduce repetitive code. Therefore we are going to create a generic BaseCardComponent as follows.

@Component({
  selector: '',
  template: '',
})
export class BaseCardComponent<T> implements OnInit {
  @Input()
  inEditMode: boolean = false;

  @ViewChild('form')
  form!: NgForm;

  entity!: T;

  unchangedEntity!: T;

  constructor(private entityService: BaseEntityService<T>) {}

  ngOnInit() {
    this.loadEntity();
  }

  loadEntity(): void {
    this.entity = this.entityService.getEntity();
    this.unchangedEntity = { ...this.entity };
  }

  save(): void {
    if (this.form.dirty) {
      this.entityService.setEntity(this.entity);
      this.unchangedEntity = { ...this.entity };
    }
  }

  cancel(): void {
    this.entity = { ...this.unchangedEntity };
  }

}

As you notice, the BaseCardComponent does not look to different from the specific UserCardComponent. With the generic in place it is now much easier to create new card components just by extending from this base class. Please take a look at the examples below.

@Component({
  selector: 'app-user-card',
  templateUrl: './user-card.component.html',
  styleUrls: ['./user-card.component.css'],
  standalone: true,
  imports: [FormsModule, CommonModule],
})
export class UserCardComponent extends BaseCardComponent<User> {
  constructor(
    entityService: UserService
  ) {
    super(entityService);
  }
}

@Component({
  selector: 'app-bank-account-card',
  templateUrl: './bank-account-card.component.html',
  styleUrls: ['./bank-account-card.component.css'],
  standalone: true,
  imports: [FormsModule, CommonModule],
})
export class BankAccountCardComponent extends BaseCardComponent<BankAccount> {
  constructor(entityService: BankAccountService) {
    super(entityService);
  }
}

Notice: Of course all cards have their specific template that should include a in order to reference it within the component.

Implementing the Composite Card Component

With all the cards setup, we finally can start the implementation of the composite card component. Because it uses the @ViewChildren decorator at its core, the following abstract gives a more detailed explanation of how we are going to use it.

@ViewChildren

The @ViewChildren decorator allows you to get a reference to multiple elements of your template. While you can pass a single component to query the DOM for all occurrences of that Component, there is a less known query option that comes in handy for our use case. Instead of passing a component class, the @ViewChildren decorator also accepts multiple comma separated string selectors, like below.

@ViewChildren('component1, component2')
 cards!: QueryList<any>;

this is exactly what we want as the basis of our card composite component.
Composite Card Component
We start out by defining our template as depcited below.

<ng-container *ngIf="inEditMode === false">
    <button (click)="onEdit()">Edit</button>
   </ng-container>

   <ng-container *ngIf="inEditMode === true">
    <button (click)="onCancel()">Cancel</button>
    <button (click)="onSave()">Save</button>
   </ng-container>

   <app-user-card #userCard [inEditMode]="inEditMode"></app-user-card>
   <app-bank-account-card #bankAccountCard [inEditMode]="inEditMode"></app-bank-account-card>

Depending on the inEditMode property, we either show or hide the edit, cancel and save buttons at the top of our template. As mentioned before, we pass the inEditMode property down to our card components.

export class CardCompositeComponent {
  @ViewChildren('userCard, bankAccountCard')
  cards!: QueryList<BaseCardComponent<unknown>>;

  inEditMode: boolean = false;

  onEdit(): void {
    this.inEditMode = true;
  }

  onCancel(): void {
    this.cards.forEach((c) => c.cancel());
    this.inEditMode = false;
  }

  onSave(): void {
    this.cards.forEach((c) => c.save());
    this.inEditMode = false;
  }

}

In our .ts file, we get a reference to all our cards by listing them within the @ViewChildren decorator. To take care of type safety, we just add the refactored BaseCardComponent as a generic type to the QueryList. When clicking on save or cancel, all that is left to do is, to loop through all cards and call the respective function of our card components.

Conclusion

The @ViewChildren decorator makes it very easy to "compose" multiple components at once. Even though component inheritance in Angular should be handled with care, in this article I showed how it reduces code and provides a common interface for the composite component to interact with.

If you like to read about Angular, you can browse my other articles here.

If you want to support me, follow me on X.

Request Deduplication in Angular

kasual1 — Wed, 06 Dec 2023 20:49:32 +0000

Many Angular applications share a common problem. Using the same data in different components. While there are many solutions to solve this issue, in this article I am going to explain a really elegant solution that helped me to get rid of some misconceptions and improved my knowledge about the overall architecture of an Angular application.

Over the last couple of years the feature based architectural approach has gained a lot of popularity in the Angular community. You divide your app into small, self-sufficient parts and keep components, services and models within a such called feature module. This way it is really easy to extend functionality and reuse a feature wherever it is needed in the app. Unfortunately this approach also has its drawbacks. Since every feature is responsible for handling its own data, it is only a matter of time until you get duplicated requests. While one solution is to globally fetch the data and forward it to children via input-properties, this certainly leads to more complexity and makes it less easy to reuse a feature. Therefore we need a solution where everything can stay within the feature module.

I started to dig around the internet and interestingly I found the solution in the docs of Next.js. Within the data-fetching part they explain the general concept. In Next.js all requests are made using an extended version of the fetch API. Requests are automatically memoized so that you can fetch the same data in multiple places in a React component tree while only executing it once. For example, if you need to use the same data across a route (e.g. in a Layout, Page, and multiple components), you do not have to fetch data at the top of the tree then forward props between components. Instead, you can fetch data in the components that need it without worrying about the performance implications of making multiple requests across the network for the same data.

While this sounds exactly like the behavior that we are looking for, unfortunately the Angular framework does not provide such functionality out of the box. Therefore I sat down and build a solution myself.

A great place to start is the HttpInterceptor. First we create a new interceptor called CustomInterceptor and add it to the providers array of our app.module.ts.



// custom.interceptor.ts
@Injectable()
export class CustomInterceptor implements HttpInterceptor {
   return next.handle(request);
}

// app.module.ts
@NgModule({
  declarations: [
    ...
  ],
  imports: [
    ...
  ],
  providers: [
    {
      provide: HTTP_INTERCEPTORS,
      useClass: CustomInterceptor,
      multi: true
    }
  ],
  bootstrap: [AppComponent]
})
export class AppModule {}

Within the interceptor we can execute some custom logic that is executed right before a request is send out to the network. Lets start by implementing simple caching behavior.



// custom.interceptor.ts
@Injectable()
export class CustomInterceptor implements HttpInterceptor {

  cache: Map<string, HttpEvent<unknown>> = new Map();

  intercept(request: HttpRequest<unknown>, next: HttpHandler): Observable<HttpEvent<unknown>> {

    if(request.method !== 'GET') {
      return next.handle(request);
    }

    const cached = this.cache.get(request.urlWithParams);
    if(cached) {
      return of(cached);
    }

   return next.handle(request).pipe(
      tap(event => {
        if(event instanceof HttpResponse){
          this.cache.set(request.urlWithParams, event.clone())
        }
      })
    );
  }
}

In the code above we first check whether the request is eligible to be cached. Since we want to keep things simple, we only cache GET requests and immediately return the next.handle() otherwise. We then take a look in our cache and if it includes an entry for the current request we return this entry instead of making a new request. If the cache does not hold an entry already, we then tap into the response stream of next.handle(request) and use request.urlWithParams as a key to add the cloned response event to our cache.

When running your application with the current setup, all requests that have been responded already, are now served from cache. While this is certainly going in the right direction, there is another problem that needs to be solved. All requests that are concurrently fired and have not been responded yet, cause another request that isn’t served from cache. Therefore we now implement the actual deduplication behavior via a queue. We add to the HttpInterceptor as depicted below.



// custom.interceptor.ts
@Injectable()
export class CustomInterceptor implements HttpInterceptor {

  cache: Map<string, HttpEvent<unknown>> = new Map();

  // Queue to store ongoing requests
  queue: Map<string, Observable<HttpEvent<unknown>>> = new Map();

  constructor() {}

  intercept(request: HttpRequest<unknown>, next: HttpHandler): Observable<HttpEvent<unknown>> {

    if(request.method !== 'GET') {
      return next.handle(request);
    }

    // Check if request is currently in queue
    const queued = this.queue.get(request.urlWithParams);
    if(queued) {
      return queued;
    }

    const cached = this.cache.get(request.urlWithParams);
    if(cached) {
      return of(cached);
    }

    const shared = next.handle(request).pipe(
      tap(event => {
        if( event instanceof HttpResponse){
          this.cache.set(request.urlWithParams, event.clone())
        }
      }),
      // Delete from queue, since the request has been answered
      finalize(() => this.queue.delete(request.urlWithParams)),
      // Share replay to not cause duplicate subscriptions
      shareReplay()
    );

    // Add request to queue 
    this.queue.set(request.urlWithParams, shared);

    return shared;
  }
}

Similar to the cache, we add another Map called queue. We use this to store all ongoing requests until they have returned a response. So again we first check whether a request is currently in the queue and return it. Otherwise we store the entire next.handle(request) Observable in the queue. We add the finalize operator and delete the entry from the queue as soon as the Observable completes with a response. Last but not least we add shareReplay, in order to not cause duplicated subscriptions.

If we now run the application again, even concurrently fired requests should not cause a wire transfer anymore.

Bonus 1: Cache only for current active route path

While it is certainly nice to cache data for the entire lifespan of your application, some applications require to frequently pull in, up to date data. Some users might even expect your application to serve fresh data as soon as they navigate to a different route path. We can easily extend our current CustomInterceptor to achieve the desired behavior.



// custom.interceptor.ts
export class CustomInterceptor implements HttpInterceptor {

cache: Map<string, HttpEvent<unknown>> = new Map();

queue: Map<string, Observable<HttpEvent<unknown>>> = new Map();

// Store current active url path
currentUrl: string = '';

constructor(private router: Router) {}

intercept(request: HttpRequest<unknown>, next: HttpHandler): Observable<HttpEvent<unknown>> {
   // Clear cache if current active url path changes
   if(this.router.url != this.currentUrl) {

      this.currentUrl = this.router.url;

      this.cache.clear();
      this.queue.clear();
    }


    if(request.method !== 'GET') {
      return next.handle(request);
    }

    // ...

  }
}

We add the variable currentUrl to hold the current active route path of our application. As soon as the route path changes we update the currentUrl and clear the cache as well as the queue.

Now your application should deduplicate requests only while staying on the current route. As soon as you navigate to a different view the deduplication starts all over again.

Bonus 2: Skip cache for certain requests

Of course there are places in an app that always require to fetch up to date data. Let’s implement a simple flag that enables you to make selected requests skip the cache.



// custom.interceptor.ts
export const SKIP_CACHE = new HttpContextToken<boolean>(() => false);

export class CustomInterceptor implements HttpInterceptor {

// ...

intercept(request: HttpRequest<unknown>, next: HttpHandler): Observable<HttpEvent<unknown>> {
   // ...

    if(request.context.get(SKIP_CACHE)) {
      return next.handle(request);
    }

    if(request.method !== 'GET') {
      return next.handle(request);
    }

    // ...

  }
}

// data.service.ts
@Injectable({providedIn: 'root'})
export class DataService {

    constructor(private http: HttpClient) { }

    getData$(id: number): Observable<any> {
        const context = new HttpContext().set(SKIP_CACHE, true);
        return this.http.get(`https://swapi.dev/api/people/${id}`, { context });
    }

}

We introduce a HttpContextToken called SKIP_CACHE. As soon as this token is present on a http request and the value is set to true, we immediately return the next.handle(request).

Whenever you want to skip a certain request you just set this token on the HttpContext and pass it to the http get method of the HttpClient.

Conclusion

Especially in the context of feature based architectures, the presented solution seems quite elegant. Just like in Next.js, when developing a feature, you make all necessary requests right in your feature module, without worrying about implications of duplicated requests.

In fact, to me the solution seems so obvious, that I’m a bit disappointed that such technique is not mentioned anywhere in the Angular docs. Even though it would be great to get a native solution from the Angular team, I just published the discussed solution as a small npm package. Just head over to ngx-dedup and give it a try.

Follow Me

x.com (formerly twitter)
github.com
npmjs.com
medium.com