Transforming a TypeScript data type into a comparable type

Question

Transforming a TypeScript data type into a comparable type

I'm facing a challenge with two interfaces that represent the data returned by an API and the actual data itself.

interface APIModelCommon {
    id: number
    createdAt: string
    updatedAt: string
}

interface ModelCommon {
    id: number
    createdAt: Date
    updatedAt: Date
}

I've been struggling to write a function that properly converts the API model to the correct type. Previously, I had to resort to type assertions with eslint-disable comments, but I want to handle this issue more effectively.

The goal is to convert

interface APIArchive extends APIModelCommon

to

interface Archive extends ModelCommon

, for instance.

Every attempt I've made so far has resulted in errors, and I haven't been able to find a solution.

function correctScrapedModel<A extends APIModelCommon, T extends ModelCommon>(apiModel: A): T {
    const clone: T = (({ createdAt: _, updatedAt: __, ...o }) => ({
        ...o,
        createdAt: new Date(),
        updatedAt: new Date(),
    }))(apiModel)
    clone.createdAt = new Date(apiModel.createdAt)
    clone.updatedAt = new Date(apiModel.updatedAt)
    return clone
}

Currently, the function is generating this error:

TS2322: Type 'Omit<A, "createdAt" | "updatedAt"> & { createdAt: Date; updatedAt: Date; }' is not assignable to type 'T'. 'Omit<A, "createdAt" | "updatedAt"> & { createdAt: Date; updatedAt: Date; }' can be assigned to the constraint of type 'T', but 'T' might use a different subtype of constraint 'ModelCommon'.

The temporary fix involves using:

function correctScrapedModel<A extends APIModelCommon, T extends ModelCommon>(apiModel: A): T {
    const clone = (({ createdAt: _, updatedAt: __, ...o }) => ({
        ...o,
        createdAt: new Date(),
        updatedAt: new Date(),
    } as unknown as T))(apiModel)
    clone.createdAt = new Date(apiModel.createdAt)
    clone.updatedAt = new Date(apiModel.updatedAt)
    return clone
}

However, I prefer avoiding as unknown as TYPE statements if possible.

Is there a better approach to resolve this? If there's a way to inform Typescript that

Omit<APIModelCommon, 'createdAt' | 'updatedAt'> & { createdAt: Date, updatedAt: Date}

is equal to ModelCommon, that would likely solve the issue, but I am unaware of how to do that.

typescript

Answer 1

Answer №1

If you want to avoid repetition in your code, consider using generics and conditional types.

For different scenarios based on whether the generic is "Json" or "Native", specify JSON-compatible types (e.g. string) or native types (e.g. Date) accordingly. You can simplify the process by implementing a default generic parameter for one of the variations to reduce verbosity. Take a look at this example:

Check out the code in action on TS Playground

type SerializationFormat = "Native" | "Json";

type ModelCommon<Format extends SerializationFormat = "Native"> = {
  id: number;
  createdAt: Format extends "Native" ? Date : string;
  updatedAt: Format extends "Native" ? Date : string;
};

function deserializeModel(input: ModelCommon<"Json">): ModelCommon {
  return {
    id: input.id,
    createdAt: new Date(input.createdAt),
    updatedAt: new Date(input.updatedAt),
  };
}

function serializeModel(input: ModelCommon): ModelCommon<"Json"> {
  return {
    id: input.id,
    createdAt: input.createdAt.toISOString(),
    updatedAt: input.updatedAt.toISOString(),
  };
}

Answer 2

If you want to avoid repetition in your code, consider using generics and conditional types.

For different scenarios based on whether the generic is "Json" or "Native", specify JSON-compatible types (e.g. string) or native types (e.g. Date) accordingly. You can simplify the process by implementing a default generic parameter for one of the variations to reduce verbosity. Take a look at this example:

Check out the code in action on TS Playground

type SerializationFormat = "Native" | "Json";

type ModelCommon<Format extends SerializationFormat = "Native"> = {
  id: number;
  createdAt: Format extends "Native" ? Date : string;
  updatedAt: Format extends "Native" ? Date : string;
};

function deserializeModel(input: ModelCommon<"Json">): ModelCommon {
  return {
    id: input.id,
    createdAt: new Date(input.createdAt),
    updatedAt: new Date(input.updatedAt),
  };
}

function serializeModel(input: ModelCommon): ModelCommon<"Json"> {
  return {
    id: input.id,
    createdAt: input.createdAt.toISOString(),
    updatedAt: input.updatedAt.toISOString(),
  };
}

Answer 3

Answer №2

The root of the issue you're facing lies in the lack of a common type between APIArchive and Archive, or any other generic types that extend APIModelCommon and ModelCommon.

interface APIArchive extends APIModelCommon {
    foo: string;
}

interface Archive extends ModelCommon {
    foo: string;
}

This problem is exacerbated by the constraint specified on the method:

<A extends APIModelCommon, T extends ModelCommon>

When omitting "createdAt" and "updatedAt," TypeScript cannot establish the equivalence between type A and type T.

A suggested solution is to revise your models so they can have shared attributes. In the meantime, one workaround is to rely on type inference for the return type.

interface APIModelCommon {
  id: number;
  createdAt: string;
  updatedAt: string;
}

interface ModelCommon {
  id: number;
  createdAt: Date;
  updatedAt: Date;
}

interface APIArchive extends APIModelCommon {
  foo: string;
}

interface Archive extends ModelCommon {
  foo: string;
}

function correctScrapedModel<A extends APIModelCommon, T extends ModelCommon>({
  createdAt,
  updatedAt,
  ...o
}: A &
  Omit<T, "createdAt" | "updatedAt">) {
  return {
    ...o,
    createdAt: new Date(createdAt),
    updatedAt: new Date(updatedAt),
  };
}

const a : APIArchive = {} as any; // trick compiler, actual value not relevant here
const b : Archive = {} as any; // trick compiler, actual value not relevant here

const c : Archive = correctScrapedModel(a);

Answer 4

The root of the issue you're facing lies in the lack of a common type between APIArchive and Archive, or any other generic types that extend APIModelCommon and ModelCommon.

interface APIArchive extends APIModelCommon {
    foo: string;
}

interface Archive extends ModelCommon {
    foo: string;
}

This problem is exacerbated by the constraint specified on the method:

<A extends APIModelCommon, T extends ModelCommon>

When omitting "createdAt" and "updatedAt," TypeScript cannot establish the equivalence between type A and type T.

A suggested solution is to revise your models so they can have shared attributes. In the meantime, one workaround is to rely on type inference for the return type.

interface APIModelCommon {
  id: number;
  createdAt: string;
  updatedAt: string;
}

interface ModelCommon {
  id: number;
  createdAt: Date;
  updatedAt: Date;
}

interface APIArchive extends APIModelCommon {
  foo: string;
}

interface Archive extends ModelCommon {
  foo: string;
}

function correctScrapedModel<A extends APIModelCommon, T extends ModelCommon>({
  createdAt,
  updatedAt,
  ...o
}: A &
  Omit<T, "createdAt" | "updatedAt">) {
  return {
    ...o,
    createdAt: new Date(createdAt),
    updatedAt: new Date(updatedAt),
  };
}

const a : APIArchive = {} as any; // trick compiler, actual value not relevant here
const b : Archive = {} as any; // trick compiler, actual value not relevant here

const c : Archive = correctScrapedModel(a);

Transforming a TypeScript data type into a comparable type

Answer №1

Answer №2

Similar questions

Using Angular's [ngIf], [ngIfElse], and [ngIfElseIf] functionalities enables dynamic content rendering

Type narrowing is ineffective for discriminated unions in most cases

Make an http.patch request to the server using a Nativescript application

Activation of Angular SwUpdate deprecation

Error: Trying to modify a property that is set as read-only while attempting to override the toString() function

Keep track of the input values by storing them in an array after they are

WebStorm is not auto-completing the Emotion Styled Components

Encountering a TypeScript error within the queryFn while implementing Supabase authentication alongside React Toolkit Query

Angular // binding innerHTML data

Using curly braces in a fat arrow function can cause it to malfunction

Using Vue 2 with a personalized Axios setup, integrating Vuex, and incorporating Typescript for a robust

What is the proper way to validate a property name against its corresponding value?

What is the relationship between an odd number and the value 1 in JavaScript that results in a 'true' outcome?

Tips for testing SSM's GetParameter with aws-sdk-client-mock in typescript

Issue with rest operator behavior in TypeScript when targeting es2018

Create a randomized item for experimentation in NodeJs using an interface

Connecting Ag Grid with modules

Optimizing Node.js and Express routes by separating them into individual files: a

Omit select dormant modules when building (Angular5)

Beginner: Add "shared" module elements to app.module and include them in app.component.html as part of the app's layout