Disabling button on api calls in Angular

Tony Shaji — Wed, 01 Jan 2025 16:44:00 +0000

While working on multiple frameworks, I have come across a common bug that occurs caused by clicking an api calling button multiple times. The issue is that the consecutive button click is causing repeated api calls. This causes unwanted operations in the database. The common solution is to disable the button before the api call and enable it after the call has been completed either by response or error.

The code looks like this

saveData(): void {
    this.isSaving = true; // Disable the button and show the spinner

    // Call the service method
    this.mockService.btnclickCheck().subscribe({
      next: (response) => {
        console.log('Service response:', response);
        this.isSaving = false; // Re-enable the button
      },
      error: (error) => {
        console.error('Error occurred:', error);
        this.isSaving = false; // Re-enable the button even on error
      }
    });
  }

This solution works but this disabling and enabling needs to be added everywhere when a button calls api. The same code is being repeated everywhere for a click on button. But If the same code is repeated we should always look to extract it to a common place and decrease the clutter on the rendering part. For Angular there is an easy way to extract it to a directive and clean up the components code

import { Directive, ElementRef, Input } from '@angular/core';
import { EMPTY, exhaustMap, finalize, fromEvent, isObservable, Observable, of, Subscription, take } from 'rxjs';

export type ButtonHandler = (
  e?: MouseEvent
) => Observable<unknown> | Promise<unknown>;

const defaultHandler: ButtonHandler = (e) => EMPTY;
@Directive({
  selector: 'button[save-btn]',
  exportAs: 'saveBtn',
  host: {
    '[disabled]': ' _processing',
    '[class.loading]': '_processing',
  },
})
export class ButtonClickDirective {

  private _processing = false;
  private _sub = Subscription.EMPTY;

  @Input()
  handler: ButtonHandler = defaultHandler;

  get processing(): boolean {
    return this._processing;
  }

  constructor(private readonly btnElement: ElementRef<HTMLButtonElement>) {}

  ngAfterViewInit() {
    this._sub = fromEvent<MouseEvent>(this.btnElement.nativeElement, 'click')
      .pipe(exhaustMap((e) => this.wrapHandlerInObservable(e)))
      .subscribe();
  }

  ngOnDestroy() {
    this._sub.unsubscribe();
  }

  private wrapHandlerInObservable(e: MouseEvent) {
    this._processing = true;
    const handleResult = this.handler(e);
    let obs: Observable<unknown>;
    if (isObservable(handleResult)) {
      obs = handleResult;
    } else {
      obs = of(handleResult);
    }
    return obs.pipe(
      take(1),
      finalize(() => (this._processing = false))
    );
  }

}

Here the directive uses a fromEvent operator from RxJs to create an event on button click. The components should use this operator to chain to this event using pipe operator and call the necessary api calls. The directive has a check using exhaustmap operator that make the check if an inner observable is active. If there is an inner observable, a flag is set to true. Based on this flag value we can add visual changes like disabling button or adding a spinner to the event target which is of course the button

handler: any = (e:any) => {
    const api = this.mockService.btnclickCheck();
    api.subscribe((res) => {
      console.log(res);
    });
    return api;
  };

<button save-btn [handler]="handler">Click me!</button>

The api calls required to be called are added as input. In the directive empty observable is set as default value for handler input. The response from api is handled at the end such that it is always an observable. The flag is reset at the end in finalize operator. You can find the sample code here https://github.com/tonyshaji/button-click-directive
Now the button and it’s api call is in your component, but disabling and enabling of button or adding some spinners for that cause is moved to a directive. Making the component leaner and cleaner

Backpedaling in Angular: Scenarios to avoid

Tony Shaji — Thu, 30 May 2024 11:18:06 +0000

New gen JavaScript based frameworks like angular have been created to overcome the shortcomings of JavaScript. Often developers who are new to these frameworks implements old JavaScript code, instead of using new features of Angular. Here are some avoidable scenarios.

Avoiding Observables to use Async awaits and promises.

Async await is a JavaScript feature for asynchronous operations. But angular comes with a better and more powerful library Rxjs. Async await cannot cancel the operation once it is executed while Rxjs can cancel it. Async await only supports a single emission for a call, But Rxjs can run for any number of times.

When you already have a better library like Rxjs, it makes no sense to use async await. Since Angular is based on JavaScript async await will surely run on Angular. But it doesn’t mean that You should be using it. Whatever async await can do, Rxjs can do better and even more.
Using reactive forms and template driven forms together

Some developers seems to use reactive forms and template driven forms together.

Reactive forms are guided by the principle of 'one-way' data binding, which involves managing the state of forms using an immutable approach. This means that changes to the form state are made in a way that prevents them from being directly modified after they are initially set. By following this approach, there is a clearer separation of concerns between the template, which defines the form structure, and the component logic, which handles form behavior and interactions. This separation enhances maintainability and readability of the codebase, making it easier to understand and maintain.

The ngModel directive will keep track of the value typed in by the user with each key pressed, and it will also keep track of the validity state of that particular form control only. NgModel adheres to ‘two-way’ binding.

While running this angular produces a warning in development mode

Actually reactive forms are a better and more feature rich version of template driven form
Creating common service for calling Api

Angular is built over typescript which is a strongly typed language. Which means there is stricter typing rules at compile time, which implies that errors and exceptions are more likely to happen during compilation. Most of these rules affect variable assignment, function return values, procedure arguments and function calling.

When common service is created for all Api calls the type is given as any in usual cases which discards the benefits of strong typing.
Not using angular cli to create new files

If you doesn’t use angular cli, there is higher chance that the naming convention is broken somewhere, making the code less readable.
Creating one single module for all shared components

Many developers add all shared component to a single module and calls it shared module. This in fact increase the load on the page and makes rendering slower. The components that are not required for the current page is loaded from the shared module. With standalone component this issue is almost solved. But in angular apps using old version this issue exists.

The best solution to fix this is even though all shared components are
in a shared folder, each component should have it’s on module. So only
one module needs to be imported for that particular component. Or to
make things much simpler update to newer versions.

Conclusion

When a framework provide you with new feature make utmost use of it, Instead of sticking to the old methods you are used to. The leaning process is beneficial for the developer.

Forem: Tony Shaji

Disabling button on api calls in Angular

Backpedaling in Angular: Scenarios to avoid