DEV Community: Anirban Mukherjee

Vue - build dynamic reactive form

Anirban Mukherjee — Sun, 13 Jul 2025 17:46:03 +0000

anirbmuk / vue-dynamic-form

Dynamic and reactive form generation using Vue3

This article intends to demonstrate dynamic and reactive form generation based on user-defined configurations.

Overview

This is a Vue 3 application that demonstrates dynamic form generation based on user-defined configurations. The application allows users to specify how many input fields and select drop-downs they want, and then dynamically creates a form with the specified number of fields.

Project Structure

vue-dynamic-form/
├── src/
│   ├── components/
│   │   ├── FormDefinition.vue    # Form configuration interface
│   │   └── FormImplementation.vue # Dynamic form renderer
│   ├── types/
│   │   └── form-definition.d.ts  # TypeScript type definitions
│   ├── App.vue                   # Main application component
│   └── main.ts                   # Application entry point
├── package.json
└── README.md

Core Concepts

1. Form Definition Type

The application uses a simple type definition to specify form structure:

export type FormDefinition = {
  input: number;  // Number of text input fields
  select: number; // Number of select dropdown fields
}

2. Component Architecture

FormDefinition.vue (Configuration Component)

Purpose: Provides UI for users to specify form structure
Features:
- Number inputs for input and select field counts
- Real-time validation (minimum 0)
- Emits updates to parent component
Props: Receives current form definition
Events: Emits update:form-definition when configuration changes

FormImplementation.vue (Dynamic Form Renderer)

Purpose: Dynamically renders form fields based on configuration
Key Features:
- Reactive field generation
- Memory-efficient ref management
- Automatic cleanup of unused fields

Dynamic Form Generation Logic

The FormImplementation.vue component uses a sophisticated reactive system:

Reactive State Management:

// Reactive state management for dynamic form fields
// objectRefs: Stores reactive refs for each form field (input-1, input-2, select-1, etc.)
const objectRefs: Record<string, Ref<string>> = {};
// objectRefKeys: Reactive Set to track which keys currently exist
// Used for template iteration and cleanup logic
const objectRefKeys = reactive<Set<string>>(new Set<string>());
// objectRefsList: Alternative array representation of refs (currently unused)
// Could be used for bulk operations or debugging
const objectRefsList = reactive<Ref<string>[]>([])

Watcher-Based Field Management:
- Watches for changes in the count prop
- Creates new reactive refs for each required field
- Removes unused refs to prevent memory leaks
- Maintains field state across re-renders
Field Creation Strategy:
- Uses unique keys (input-1, input-2, select-1, etc.)
- Only creates new refs when they don't exist
- Preserves existing field values during re-renders

Memory Management

The application implements careful memory management:

Selective Creation: Only creates refs for fields that don't exist
Cleanup Logic: Removes refs for fields no longer needed
State Preservation: Maintains field values during configuration changes

Template Rendering

The template uses Vue's reactive system effectively:

<!-- Dynamic input fields -->
<div v-for="i in count.input" :key="`input-${i}`" class="form-group">
  <input v-model="objectRefs[`input-${i}`].value" />
</div>

<!-- Dynamic select fields -->
<div v-for="j in count.select" :key="`select-${j}`" class="form-group">
  <select v-model="objectRefs[`select-${j}`].value">
    <!-- Options -->
  </select>
</div>

Usage Flow

Initial State: Application starts with 0 input and 0 select fields
Configuration: User adjusts counts in FormDefinition component
Dynamic Generation: FormImplementation component creates corresponding fields
Real-time Updates: Form updates immediately as configuration changes
State Persistence: Field values are preserved during configuration changes
Memory Management: When components are removed, the associated refs are also deleted, to prevent memory leak.

——-

Cheers :-)
Anirban Mukherjee

Custom Toggle Button Vue Component

Anirban Mukherjee — Sat, 06 Apr 2024 10:20:11 +0000

anirbmuk / toggle-button-vue

A toggle-button component using Vue3

This blog post aims to create a simple Toggle-Button component with Vue3, which can also be integrated with a form, via v-model.

Sometimes it is important to create these UI components on your own, instead of relying on heavier UI libraries. When you do this, you get to learn a few more intricate stuff, which you may ignore while using ready-made solutions, and also, you make it light-weight by excluding features you may not even need.

The ToggleButton Component

Props:

options (array)
modelValue (string)

defineProps({
  modelValue: {
    type: String,
    default: ''
  },
  options: {
    type: Array as PropType<KeyValue<string>[]>,
    required: true
  }
})

Emits:

update:model-value (string)

defineEmits<{
  (e: 'update:model-value', value: string): void
}>()

Let's talk about the props.
The options array is a list of key-value objects, which are displayed as buttons.

<template v-for="option of options" :key="option.value">
  <button
    type="button"
    :class="{ selected: modelValue === option.value }"
    @click="$emit('update:model-value', option.value)"
  >
    {{ option.label }}
  </button>
</template>

The modelValue prop is an interesting one. It should be named modelValue (case-sensitive), if you want this component to have a data-binding. When a custom component has this prop, and it is bound to a v-model, the value flows into this component and is applied to the underlying model.

If you want the component to have a 2-way data-binding, you also need to define an emit called update:model-value (again, case-sensitive). You write your logic to emit this event with the new value, every time a new button is clicked.

...
@click="$emit('update:model-value', option.value)"
...

Now that your component is ready for 2-way binding, you can use it in your application:

<ToggleButton :options="options" v-model="selected" />
...
const options = [
  {
    label: 'Male',
    value: 'M'
  },
  {
    label: 'Female',
    value: 'F'
  },
  {
    label: 'Diverse',
    value: 'D'
  }
] satisfies KeyValue<string>[]

const selected = ref<string>('F')

That's all folks. Refer to the GitHub repo for the complete code!

Anirban Mukherjee

A unique Angular hover directive

Anirban Mukherjee — Wed, 22 Jun 2022 17:07:26 +0000

@angular/cli: 13.3.0

anirbmuk / ng-hover

Angular 13.3.0 application to build a unique hover directive

Again, a strange requirement at work and the engineer goes to the drawing board to stretch the framework, and angular never disappoints!

What was needed to be done?

When the user hovers on one part of the page, some css effect should be applied on another specified part of the page, something like this:

Interesting, isn't it? Well there could be a million other simpler solutions, but I thought of building a custom angular directive which could be used in multiple places.

The solution

The directive I built needed two inputs:

The reference of elements on which the style is to be applied.
The list of css classes to be applied.

export interface IGroupHover {
  elements: HTMLDivElement[];
  classList?: string | undefined;
}

@Input() set appGroupHover(config: IGroupHover) {
  this._elements = config?.elements ? [...config?.elements] : [];
  this._classes = config?.classList?.split(' ') || [];
}

I have used Tailwindcss for this demo, but that is just because I find it easy to use. Tailwind is no way related to the original purpose.

Also, for the sake of simplicity of the demo, I have only targetted HTMLDivElement, but you can extend this solution to any HTML element.

The directive utilizes @HostListener for mouseenter and mouseleave events.

On mouseenter, I apply the classes to the referenced elements.

@HostListener('mouseenter') onMouseover() {
  if (this._elements && this._classes) {
    for (const element of this._elements) {
      for (const userClass of this._classes) {
        userClass && element.classList?.add?.(userClass);
      }
    }
  }
}

On mouseleave, I remove the classes from the referenced elements.

@HostListener('mouseleave') onMouseleave() {
  if (this._elements && this._classes) {
    for (const element of this._elements) {
      for (const userClass of this._classes) {
        userClass && element.classList?.remove?.(userClass);
      }
    }
  }
}

And technically, this is all that the directive needs. Now let's see how to use it.

The implementation

I have a grid layout of 3 columns, and I intend to hover over the middle column, while alternately applying the specified classes on the left or right columns. I have prepared a similar data-set.
While looping through this data-set, I set a #left view reference on the left column, and a #right view reference on the right column.
On the middle column, I apply the directive and pass these references and the classes I want to apply. So each middle column has its own directive instance, with its own HTMLDivElement reference and class-list to apply.

And there you go! You can download the source code from GitHub.

Cheers :-)
Anirban Mukherjee

Angular lazy loading directive with IntersectionObserver

Anirban Mukherjee — Thu, 02 Jun 2022 12:27:27 +0000

@angular/cli: 13.3.0

anirbmuk / ng-lazy-load

Angular 13.3.0. application to demonstrate a lazy loading directive using IntersectionObserver API

So let's dig into lazy loading once again! Previously, I had written an article Angular infinite scrolling using RxJs and NgRx, which explained the concept of loading more data on reaching the end-of page. But this time, the concept is wider, or more generic.

This time, I would like to reach a certain part of the viewport, and then load some data specific to that part, or maybe perform some tracking action. So I would observe a specific HTML selector and then do something when that selector comes into view. And that selector could be anywhere in the page, not just the end, something like this:

So of course, we go for the IntersectionObserver API. Almost all modern browsers now support it, so we should ideally have no problem for a modern website.

Let us once again break down the requirements, one by one.
1) We need a custom directive, which we can place on any HTML element.
2) This directive will accept a callback method as a parameter, so that the parent component consuming the directive can decide what to do once the child element comes into view.
3) Tracking should happen only once, so that every time the element comes into view (due to user scrolling up and down), the data should not be re-fetched. But this is my specific use-case, you may choose to do differently.
4) The observer should be disconnected when the element is destroyed.

The directive:

Whenever we place a directive on an element, we get a reference to the consuming element. And to be honest, this is all we need.
Almost the entire logic happens in the constructor, since each directive placed on each element creates a new instance of the class.

Let's understand what is being done:

The Options:

root - this essentially means the relative component against which your component - the one you would like to observe - should intersect. For our use case, this is the entire document.
rootMargin - this would consider if the document has some margin, so that the intersection logic would consider that during its calculation.
threshold - this is a value between 0 and 1 (or consider 0 and 100%). A value of 1 means, the API would consider my component to be intersecting with the document only when 100% of the element is in view. You can change this as per your need.

The Intersection callback and The Observer:

For all components we observe, the callback is executed. For our use case, we have only one target - the element on which our directive is placed. We create a new instance of IntersectionObserver and assign it to an observer. This observer observes our component, which is injected into our directive class through elementRef: ElementRef.

So what happens next?

Depending on the threshold value, the entry.isIntersecting evaluates to true or false, and it is then that we need to do something.

And what do we do then?

Our directive takes in a callback as an input, and we fire this callback - this.appTrackable?.();

Also, I mentioned before that each directive on each element is a new instance. So we maintain a class level variable - tracked. And once the intersection logic is satisfied and the callback is fired, we do not need to fire the logic again and again. You could go one step ahead and disconnect the observer itself.

When the component gets destroyed, so does the directive, and you can tap onto the ngOnDestroy method, to disconnect the observer.

ngOnDestroy(): void {
  this.observer?.disconnect();
}

The implementation

The implementation means placing the directive on an element and then passing a callback reference to it.

home.component.html

<app-people [appTrackable]="callback1"></app-people>
<app-place [appTrackable]="callback2"></app-place>

The callback methods include some logic to fire HTTP calls to fetch data for that element, but that is not what this article is about and so I will not go into its details. But you can always check it out from GitHub. Just remember to bind your callback to the service or class instance, as applicable.

home.component.ts

export class HomeComponent {
  constructor(private readonly data: DataService) {}

  readonly callback1 = this.data.callback.bind(this.data, 'people');
  readonly callback2 = this.data.callback.bind(this.data, 'places');
}

So what are the possibilites?

Well you can do whatever you want with the callback thingy! But, I would say, tracking for analytics is one very important use case. You can also use this to execute infinite loading on scroll. Let me know in the comments if you can come up with more use cases!

Cheers :-)
Anirban Mukherjee

Handle CAPS-LOCK on/off event in Angular

Anirban Mukherjee — Sat, 07 May 2022 20:58:06 +0000

This is an interesting, yet quite commonly expected, use-case - warn the user that the CAPS-LOCK is ON, specially while entering a password, so that the user is aware of it and can change it, if needed.

anirbmuk / ng-capslock-demo

Angular 13.3.0 application to demonstrate how to display CAPS-LOCK-ON/OFF message

There are a few scenarios handled in this demonstration:

Change the message when the user toggles the caps-lock while on the password field.
Also change the message when the user changes the caps-lock state elsewhere (maybe in another application or browser tab, etc) and then comes back to this application.
Remove the events when component is destroyed, to prevent memory leaks.
Run change-detection when ChangeDetectionStrategy is OnPush.

Let's see about 1 & 2.

By the way, I am on @angular/cli 13.3.0 and @angular/material 13.3.6. For the message, I have used mat-hint on mat-form-field.

To achieve this, we grab the reference of the password field (using @ViewChild) and then add a couple of event handlers to the underlying HTMLInputElement - keyup and mousedown.

The keyup event handler will toggle the message when the user toggles the CAPS-LOCK button while being on the password field. This generates a KeyboardEvent.

The mousedown event handler will toggle the message when the user changes the state elsewhere and the navigates back to the application and clicks on the password field. This will be beneficial for the user since the information is now provided even before something is typed. This is done through a MouseEvent.

Some improvements:

To prevent memory leaks, we need to remove these event handlers once the component is destroyed.

If the ChangeDetectionStrategy is set to OnPush, we need to mark the component for a change detection whenever either of the above events are fired. So, at the end of the event handler, use

this.cdRef.markForCheck();

The browser's password manager may auto-fill the password data for you. This will also fire a keyup event, but this will not be an instance of KeyboardEvent and will thus not have the getModifierState method. So we will ignore this!

if (event?.type === 'keyup' && !(event instanceof KeyboardEvent)) {
  return;
}

Cheers!
Anirban Mukherjee

Angular material cross field form validation

Anirban Mukherjee — Mon, 21 Feb 2022 08:05:56 +0000

@angular/cli - 12.0.1
@angular/material - 12.0.1

anirbmuk / MaterialFormDemo

Angular material cross field form validation

This article talks about performing field-level validations across a reactive form using Angular material. The solution aims to perform cross-field form validation and then display the error as mat-error for a selected field.

This is how it would be:

Both the errors shown above are registered on the FormGroup. But the goal is to display them as mat-error on certain fields.

So how do we do this? To begin with, let's set up the form and the corresponding cross-field validations.

And we are set up in terms of the code required for the validation part. But how do we display the error as mat-error for a specific field? The mat-error only displays error when the specific field is in an error state. But our requirement is to mark it invalid when the form is invalid (and not just the specific field).

To achieve this, we use an interface called ErrorStateMatcher. This interface implements a method isErrorState, where we can write the logic to mark a form-control as invalid.

We create a class which implements this interface, and then create two instances of this class to use for the two validation methods.

Now we map these instances to the fields on which we would want to see the mat-errors.

The [errorStateMatcher] properties are mapped to the respective class instances, which allow the respective fields to be invalid and show mat-error once the form becomes invalid.

Cheers!
Anirban Mukherjee

Global error page in Angular

Anirban Mukherjee — Sun, 16 Jan 2022 12:55:24 +0000

This is a relatively small and simple article, but I felt it is still worth posting because of the utility of the topic.

anirbmuk / angular-error-handler

Angular 12 application to demonstrate global error handling against a REST-based backend

Any front-end application is all about serving data from a store, using end-points (REST/GraphQL or whichever you can think of). And a big part of your application's success is the way you can handle errors. The more gracefully you handle error situations, the better your users' experience will be.

On that note, let's talk about an approach to handle all sorts of errors in an Angular application.

The idea behind this article is to manage all possible errors in one location and allow the application to navigate to an error-page once any error is thrown. Now I would like to clarify that when I say error, I mean server side errors, emanating from your data end-points.

To do this, we will make use of the one place through which every HTTP request passes in an angular application - the interceptor. We usually make use of the interceptor to tap outgoing requests and append headers, tokens etc. But we can also tap onto the incoming response and handle the error situations.

When the next: HttpHandler handles the request, the request is sent to the back-end server. We can pipe the observable to tap onto the incoming response.

interceptor.service.ts:
intercept(
    req: HttpRequest<any>,
    next: HttpHandler
  ): Observable<HttpEvent<any>> {
    return next.handle(req).pipe(
      catchError((error) => {
        const { code, message } = error.error;
        this.errorService.addError({
          code: code || error?.status,
          message: message || error?.statusText,
        });
        this.router.navigate(['/error']);
        return EMPTY;
      })
    );
  }

We also navigate to our designated error page, which is designed to handle the error code and message and display it appropriately.

Additional improvisation: Use a resolver for the error component and check if the error observable has any value. If not then redirect to the home-page. This may be helpful when the user refreshes the error page; then it would make more sense to be taken to the home page to try again, instead of showing the same error once again.

error.resolver.ts:
resolve(route: ActivatedRouteSnapshot, state: RouterStateSnapshot) {
    return this.errorService.error$.pipe(
      take(1),
      tap((data) => {
        if (!data) {
          throw new Error('No error');
        }
      }),
      catchError(() => {
        this.router.navigate(['/']);
        return of(null);
      })
    );
  }

Cheers!
Anirban Mukherjee

Custom angular form component

Anirban Mukherjee — Sat, 14 Aug 2021 14:16:41 +0000

anirbmuk / CustomFormElement

Angular 12 application for custom form element

Most of our application requirements are fulfilled using standard HTML elements. However, we may sometimes need to stretch ourselves when we are working for large enterprise applications. In such cases, reusability becomes a strong factor which determines ease of development. Today's use case is one such custom requirement.

This article speaks about creating an Angular component which acts as a lookup - an input field with a search button. The button opens up a modal window, which shows a list of values from which the user may select one. Additionally, this new component should also angular-form-ready, which means, it should be capable enough to be registered as a template-driven or reactive form element.

Let's first talk about the component itself.

The app-lookup component takes in a couple of inputs - formConfig and lookupConfig. A sample implementation is shown below:

When user clicks on the search button, a modal window opens with data fetched from server (in my case a simple promise). Use selects a record and clicks select. The data gets populated on the input form.

If allowUnlistedValue is set as true, the user will be able to enter a value which does not exist in the list, and the value will be accepted. If not, then the form element will return empty value.

So this is all about describing the component.

Now let's see how to set it up

We need to extend this component so that Angular recognizes this as a valid form element. Since this element is of input type, I have implemented the interface ControlValueAccessor. This interface needs to implement 3 methods - writeValue, registerOnChange and registerOnTouched.
The writeValue method is the one which is responsible to writing your value to the view from your model.
registerOnChange is used to propagate changes from your model to the view. This is how the form knows that one of its members has changed its value.
registerOnTouched is used to let the wrapper form element know that one of its elements has been marked as touched.

Error handling

Question: Now that we are done with setting up the value read/write operations, how about error handling? How do we let the wrapping angular form know if our custom component has an error and needs to be marked as invalid?
Answer: To do this, we inject an instance of NgControl into the component, which gives us the FormControl instance. It is this form-control object which sets the errors in the component conditionally. Remember, it is a custom component, so everything needs to be set by us :-)
Note: The ErrorStateMatcher has nothing to do with this implementation, but it is more for the material input component. ErrorStateMatcher marks the component in red when it has an error.

As a result, if allowUnlistedValue is set as false, the user will not be able to enter a value which does not exist in the list, and the component (and subsequently the form) will be marked as invalid. This is demonstrated by disabling the Submit button when form is invalid!

Do note: A much more in-depth set of instructions for creating custom form elements can be found in a blog by Pascal Precht.

And there you go. You have your own angular component ready to be used in a form! You can download the source code from GitHub and play around with the configurations.

Cheers!
Anirban Mukherjee

Angular dynamic components with code-splitting

Anirban Mukherjee — Tue, 03 Aug 2021 15:53:16 +0000

anirbmuk / cms-components-demo

Angular 12 application to demonstrate code-splitting

A lot of times, angular components need to be determined and displayed on the fly. A very common use-case is when the components are determined from a content-management-system (CMS). This is particularly useful when we allow the customer to control the content and layout of the page.

Well we do have *ngIf for that, don't we? Depending on some CMS field value, we can use *ngIf to determine which component needs to be displayed. This is cool, but there is a major downside to this approach. The problem is, we usually have a large component library, which need to be loaded eagerly in its entirety through one or more modules. So even if only a fraction of these components may be needed by the customer, we would have to pre-load all of them, which is an unnecessary waste of resources.

So what are we talking about here? How about a way where we load only those components out of our library which are required by the customer? This is where the concept of code-splitting comes into use.

Using code-splitting, we conditionally import the required components at run-time.

The Setup

Let's see how to go about it. I have created a few simple custom angular components, which are to be conditionally loaded. So, as expected, these components are NOT part of any application module.

We need to remember that the entire operation is driven by CMS data. So we need some mechanism to evaluate this data at run-time to determine the components.

So we would need a custom structural directive for this. This directive would dynamically create the component instances and inject them into the DOM. Let's first look at the HTML needed at the implementation side, using this directive:

Now, let's take a look at the custom structural directive:

The most interesting bit is the import statement (line 25). Based on the CMS content, I only import that particular module and component. This is a huge advantage in terms of app-performance, since we do not have to load a module unless it is explicitly asked for, much like a lazily loaded route! When I place this directive on a designated location in the DOM (the ng-container in this case), I get access to that location's reference, through ViewContainerRef. I make use of angular's ComponentFactoryResolver API to build an instance of our required component and the viewContainerRef injects this component instance at that designated spot.

A small, but very important, GOTCHA!

Since our custom components are not included in any module, or any eager import statements, the angular compiler will exclude these .ts files from compilation. To forcefully compile them, so that they can be used at run-time, we need to tell tsconfig.app.json to include these files.

Cheers!
Anirban Mukherjee

Angular infinite scrolling using RxJS and NgRx

Anirban Mukherjee — Wed, 21 Jul 2021 14:51:21 +0000

anirbmuk / angular-scroll-demo

Angular 12 application to demonstrate infinite scrolling with RxJS and NgRx

I have seen multiple blog posts on this topic which make use of one method or the other. I just thought of putting everything together under one hood - RxJS, NgRx, Angular Material and in the end, pure document property access. This is what is leads to:

Let's quickly talk about the setup here - I am using an Angular CLI 12.1.0 project. I have NgRx state management set up, with a root state and a feature state. Of course, NgRx is in no way related to the purpose of this application, but I just thought it would not hurt to implement it. We have to admit, as your application grows in size, NgRx does give you some peace of mind :-)

The UI is built using angular material. I have used the mat-list and and the mat-spinner components. I have some hard-coded dummy data, which I have converted into an observable stream, with a delay of 1500 ms, which gives some feeling of having fetched data from a REST service.

The key logic is to calculate when the user has scrolled down to the edge of the page. I chose a simple formula derived from the document object. Of course there are other fancy approaches like using an IntersectionObserver, but that's something I felt was too much for me!

The above formula works great on a desktop, as well as a mobile - but feel free to drop me a note if it doesn't.

I set up the scroll action using RxJS fromEvent.

Once the scroll event is set up, whenever the above formula is satisfied, the next set of data is called for. For my sample use case, I have used a limit and skip value, which I have used to slice off a chunk from my dummy data set. Every time a new set is emitted by my data observable, I have made use of a reducer function to append it to my previous list of data.

This is where I store the next limit and skip values for the next data load, and also make a simple calculation of whether my data load is complete, and set it on my state. Once this flag becomes true, subsequent scroll actions do not trigger any more data fetch.

Cheers :-)
Anirban Mukherjee

Auto-complete with material and RxJS

Anirban Mukherjee — Sat, 03 Jul 2021 14:56:36 +0000

anirbmuk / AutocompleteDemo

Autocomplete feature with RxJS and angular material

This article talks about an efficient way to implement auto-complete feature using Angular concepts. The key components used in this demonstration are as follows:

Angular Material (v15) Autocomplete module.
RxJS for action and data binding.

I have used Dummy-JSON for getting fake JSON data.

Let us now see how we go about it:

The UI:

The front-end consists of an angular autocomplete module. The input event taps the user's keystrokes and emits a new value into an action subject.

Each key-stroke emits a new value into an action subject declared in the ProductService class.

The Service:

I selected a Subject, since I want it emit a value only when the user starts to type. The action$ is an observable built out of this subject.

Every time a new value is emitted into the action stream, it returns an observable from the http GET request. Since this is a higher-order observable (i.e., an observable returning an observable), we make use of one of the higher order functions like switchMap.

So why switchMap (and not other higher order functions like concatMap or mergeMap)? The reason is: switchMap unsubscribes from the previous observable once a new value is emitted by the parent observable.

What this means is - as soon as the user types in another letter or removes a letter, there is simply no need to subscribe and execute the rest call for the previous values. The user is only interested to see the results of the search according to his/her current input. And switchMap does this automatically, and thus gets rid of unwanted rest calls.

We can also get additional control on when to fire the rest service depending on the length of the user's input. For example, in this demo, I fire the rest call only when the user has entered at least 2 characters. If not, then I return an observable of empty array (using of([])).

Use distinctUntilChanged operator to exclude user inputs which have not changed during the debounce period. So the http call will only fire for new input values, and not if the user quickly changed the input and reverted to the old value.

Back to the Component:

We tap onto the above observable and use async pipe to subscribe to it. Since we are completely using observables, we can also use the OnPush change-detection-strategy.

And that is all :-)

@angular/cli - 15.2.8
@angular/material - 15.2.9

Source: GitHub

Cheers :-)
Anirban Mukherjee

Faster angular universal with PWA

Anirban Mukherjee — Thu, 01 Jul 2021 02:00:16 +0000

This article speaks about an interesting side-effect of mixing angular universal with progressive web application (pwa) - and that's a massive performance boost!

The Setup

--
Let's start by creating a standard angular-cli application (v12.1.0 in my case). I enable SSR (angular universal) on that.

ng add @nguniversal/express-engine

Once this is done, let's quickly check if SSR is working as per our expectation.

npm run build:ssr && npm run serve:ssr

Node server fires up on port 4000 and I check for my webpage's source.

view-source:http://localhost:4000/

Wonderful! Nothing fancy so far, and everything works great! CLI application works and universal works.

The next step is to add PWA support.

ng add @angular/pwa

No extra configurations so far, and that's how it will be. Let's build our universal application once again and serve it on localhost:4000.

But wait!!! Now when I view my webpage source on the browser, I get this:

So does this mean that my SSR is broken?

The answer is Nope! My SSR is perfectly fine :-) Let's run a quick check to prove this. Open up POSTMAN and run a GET request against http://localhost:4000. And voila! I see my server-side-rendered page once again!

So what is happening here?

The conclusion and explanation

--
The reason why we do not see the server-rendered content on the browser source is that, the index.html is now cached by service-worker at the browser. The browser does not need to wait for the server to render the content any more, and it simply serves the cached version, and Angular takes over thereafter, like a normal SPA. Open up ngsw-config.json and verify that index.html is one of the cached resources.

The search-engines/crawlers, on the other hand, would see your website just the way POSTMAN sees it, and will continue to have the entire generated HTML for search-engine-optimization. So this way, you gain the performance boost via service-worker caching, without losing the advantages of angular universal!

Note (and a small exercise): If you remove index.html from ngsw-config.json and re-build your universal, you would see that the server-rendered content is back on your browser source, since the HTML is now no longer being cached!

Cheers -:)
Anirban Mukherjee