DEV Community: Victor Shelepen

A TypeScript Utility for Type-Safe Angular Forms

Victor Shelepen — Fri, 08 Aug 2025 11:28:08 +0000

Hello, I'd like to share a code snippet that helps keep your Angular forms strongly typed and consistent with your data interfaces. I'm working on a full-stack TypeScript project where a single set of interfaces serves as the foundation for the database models, services, DTOs, and UI components. The following snippet of code implements this concept.

import { FormArray, FormControl, FormGroup } from "@angular/forms";

export type GForm<IInterface> = FormGroup<{
  [Key in keyof IInterface]: 
    IInterface[Key] extends Array<infer ArrayItem>
      ? FormArray<GForm<ArrayItem>> | FormControl<ArrayItem[]> 
      : IInterface[Key] extends Date
        ? FormControl<Date | null>
        : IInterface[Key] extends object
          ? GForm<IInterface[Key] | null> | FormControl<IInterface[Key] | null>
          : FormControl<IInterface[Key] | null>
}>;

Here's how I use it:

export interface ICar {
  brand: string,
  model: string,
}

form: GForm<ICar> = new FormGroup({
  brand: new FormControl<string>('', [Validators.required, Validators.minLength(2)]),
  model: new FormControl<string>('', [Validators.required, Validators.minLength(2)]),
});

export interface IDrivingLicence {
  fullname: string;
  car: ICar
}

form = new FormGroup({
  fullname: new FormControl<string>(''),
  car: new FormControl<ICar>(defaultCar, { nonNullable: true }),
},) as GForm<IDrivingLicence>;

I'm wondering if a similar utility already exists in the Angular library—I may have missed it. I'd appreciate it if someone could point me to a ready-made solution if one exists. My solution isn't perfect, either. It doesn't cover every edge case I've encountered. I would be grateful for any comments or suggestions on how to improve this snippet.

Notes

The null type is included because a form's controls can become null when the form is reset. You can still use validators to make null values invalid.
FormControl<T[Key] | null> is used for complex objects when you want to manage that object's value with a single custom form control rather than a nested FormGroup.

Avoid ObjectId Type for Ambiguous Typing System Across Tiers by Ditching ObjectId in Favor of Strings

Victor Shelepen — Tue, 20 May 2025 08:31:37 +0000

The recipe first

Avoid using ObjectId Type for Ambiguous Typing System Across Tiers by favoring Strings instead. This will result in simpler backend types and DTOs that are reusable at the front end without requiring any special tools. The main disadvantage of this approach is a slight decrease in performance, as strings are larger than ObjectIds and can impact fast sorting operations.

My story

This scenario originated from a real application. It seems we followed the basic rules in different steps but ultimately failed. It would be great if we had changed the architecture at the start. Our application has a stack consisting of NestJS, Angular, and Mongoose, all written in TypeScript.

We successfully implemented reusing typings across tiers, but it appeared complicated. Each tier had its own typing system, which could have been optimized. A clue to the problem is that the type of the primary field _id is ObjectId, a complex type present only on the backend. This made it unnatural for it to be used on both the frontend and backend.

Some tools were implemented to reuse these types on ObjectId. New UI types were created, which seemed to improve the application's typing system. However, the application became convoluted, and we didn't want to research the case of using plain string IDs because we thought our approach was correct and it worked everywhere except for MeteorJS projects.

If we refused to use the ObjectId type, we could eliminate the need for these tools, new UI types, and even DTOs that work on both frontend and backend. To test this idea, we created a separate project where I implemented the concept. The only disadvantage is the potential impact on MongoDB performance, which I couldn't measure.

Additionally, we experimented with meaningful primary IDs where demanded custom solutions where string type is demanded.

Start server and test scripts - NPM script - ready solution.

Victor Shelepen — Mon, 01 Nov 2021 09:53:52 +0000

Summary I have made my alternative finding different pitfalls. Meanwhile We were applying the library start-server-and-test to our solution. Surprisingly start-server-and-test covered all pitfalls. The solution solves the problem.

It is a simple script and we need to understand it. It does how it is written. It runs the server and then tests it. For details check the documentation page of start-server-and-test

Pitfalls:

All processes have to be ordered.
Pipes have to be disposable to be finished.
Tests need to know when the server starts to start testing.
The script has to know when tests are finished to terminate all processes.

It takes only three parameters:

The first: To run the server.
The second: Server path. Address to wait for its availability.
The third: Test commands.

How it works
The script runs the first to start the main development server and waits until it is up. The second parameter is the server path that the script checks if the development server is available. The development server continues running. The script runs tests that are set in the third parameter. The script waits for the finish of the tests. When tests are passed the script terminates the development server and disposes of the main thread.

P.S. It should help you to start using the script faster.