One of the interfaces in use is malfunctioning, despite being identical to the other interface in TypeScript

Question

One of the interfaces in use is malfunctioning, despite being identical to the other interface in TypeScript

I have been working on the IDocumentFilingDto.ts file.

import { DocumentOrigin } from "./IDocumentFilingDto";

export interface IDocumentFilingDtoGen {
    UniqueId?: any;
    Title?: string;
    DocumentId?: string;
    Binder?: any;
    CommunicationType?: any;
    Origin?: DocumentOrigin;
    CompanyId?: any;
    DocumentCategoryId?: any;
    DocumentTypeId?: any;
    CompanyOriginal?: string;
    SiteUrl?: string;
    hasSubmitted?: boolean;
    isModified?: boolean;
    IsLocalOnly?: boolean;
}

Everything is functioning correctly without any type errors.

Now, I will deactivate the local DocumentOrigin interface and activate the imported DocumentOrigin.

//import { DocumentOrigin } from "./IDocumentFilingDto";

export const enum DocumentOrigin {
    Original,
    Kopie,
    OverenaKopie,
    DS,
    DSSKonverzi,
    Elektronicky,
}

export interface IDocumentFilingDtoGen {
    UniqueId?: any;
    Title?: string;
    DocumentId?: string;
    Binder?: any;
    CommunicationType?: any;
    Origin?: DocumentOrigin;
    CompanyId?: any;
    DocumentCategoryId?: any;
    DocumentTypeId?: any;
    CompanyOriginal?: string;
    SiteUrl?: string;
    hasSubmitted?: boolean;
    isModified?: boolean;
    IsLocalOnly?: boolean;
}

After this change, I am no longer utilizing the imported DocumentOrigin interface, but instead relying on the local DocumentOrigin interface. This is the only adjustment made.

Both the imported and local interfaces for DocumentOrigin are identical. However, switching to the local interface triggers an error message.

[07:20:52] Error - typescript - src\webparts\documentUploadWebPart\components\DocumentHeader\DocumentHeader.tsx(462,60): error TS2345: Argument of type '{ UniqueId?: any; Title?: string; DocumentId?: string; Binder?: any; CommunicationType?: any; Ori...' is not assignable to parameter of type 'IDocumentFilingDtoGen'. [07:20:52] Error - typescript - src\webparts\documentUploadWebPart\components\Dtos\DocumentFilingDtoGen.ts(28,12): error TS90010: Type 'DocumentOrigin' is not assignable to type 'DocumentOrigin'. Two different types with this name exist, but they are unrelated.

This behavior seems illogical. The two interfaces are identical in structure, yet one works while the other does not. Why is that?

Additional Information:

In response to a comment request, here is the code snippet from the IDocumentFilingDto.ts file as well.

export const enum DocumentOrigin {
    Original,
    Kopie,
    OverenaKopie,
    DS,
    DSSKonverzi,
    Elektronicky,
}

export interface IDocumentFilingDto {
    UniqueId: any;
    Title: string;
    DocumentId: string;
    Binder?: any;
    CommunicationType: any;
    Origin?: DocumentOrigin;
    CompanyId: any;
    DocumentCategoryId: any;
    DocumentTypeId:any;
    CompanyOriginal?: string;
    SiteUrl?: string;
}

typescript

Answer 1

Answer №1

The reason for the error lies in TypeScript treating the local DocumentOrigin differently from the imported one, despite being identical. To resolve this issue, simply import DocumentOrigin in IDocumentFilingDtoGen.ts and ensure that you are utilizing enums solely from this source.

Ensure that any usage of this interface also involves enums from the same origin.

Answer 2

The reason for the error lies in TypeScript treating the local DocumentOrigin differently from the imported one, despite being identical. To resolve this issue, simply import DocumentOrigin in IDocumentFilingDtoGen.ts and ensure that you are utilizing enums solely from this source.

Ensure that any usage of this interface also involves enums from the same origin.

Answer 3

Answer №2

Distinctive attributes define TypeScript enums uniquely. One key characteristic is the one-way equivalence between enum members and their actual values. For instance, an enum member with the value "foo" can serve as a string, but a variable (or another enum's member) with the same value cannot fulfill the requirement for a member of another enum.

In situations where using an enum member is obligatory, only that specific enum's members are valid. Merely sharing the same value or having an identical member from a different enum does not suffice.

For example:

enum MyEnum {
  EXAMPLE = 'example',
}

enum MyOtherEnum {
  EXAMPLE = 'example',
}

function useMyEnum(arg: MyEnum): void {}

useMyEnum(MyEnum.EXAMPLE); // Acceptable

useMyEnum('example'); // Rejected, although it has the same value
useMyEnum(MyOtherEnum.EXAMPLE); // Rejected, despite having the same value and being part of a different enum

function useValue(arg: 'example'): void {}

useValue(MyEnum.EXAMPLE); // Acceptable
useValue('example'); // Permissible
useValue(MyOtherEnum.EXAMPLE); // Also permissible

TypeScript Playground

If a new enum replicates the initial enum in name and members, TypeScript distinguishes them as distinct entities. They cannot be interchanged.

This particular enum is also a const enum. During compilation, the enum values are substituted directly with their real values, essentially erasing the existence of the enum. Nevertheless, TypeScript mandates accessing these values through the enum even though they are replaced.

To create an enum-like interface without this constraint, utilize an as const assertion on a standard JavaScript object. This produces something akin to an enum that can be employed similarly. However, TypeScript will not generate additional enum features like types; hence, it's a useful alternative:

export const MyEnum = {
  FOO: 'foo',
  BAR: 'bar',
} as const;
export type MyEnum = typeof MyEnum[keyof typeof MyEnum]; // 'foo' | 'bar'

TypeScript Playground

While this approach comes with its pros and cons, it closely emulates enums created using the enum keyword, making it a viable option in various scenarios.

Answer 4

Distinctive attributes define TypeScript enums uniquely. One key characteristic is the one-way equivalence between enum members and their actual values. For instance, an enum member with the value "foo" can serve as a string, but a variable (or another enum's member) with the same value cannot fulfill the requirement for a member of another enum.

In situations where using an enum member is obligatory, only that specific enum's members are valid. Merely sharing the same value or having an identical member from a different enum does not suffice.

For example:

enum MyEnum {
  EXAMPLE = 'example',
}

enum MyOtherEnum {
  EXAMPLE = 'example',
}

function useMyEnum(arg: MyEnum): void {}

useMyEnum(MyEnum.EXAMPLE); // Acceptable

useMyEnum('example'); // Rejected, although it has the same value
useMyEnum(MyOtherEnum.EXAMPLE); // Rejected, despite having the same value and being part of a different enum

function useValue(arg: 'example'): void {}

useValue(MyEnum.EXAMPLE); // Acceptable
useValue('example'); // Permissible
useValue(MyOtherEnum.EXAMPLE); // Also permissible

TypeScript Playground

If a new enum replicates the initial enum in name and members, TypeScript distinguishes them as distinct entities. They cannot be interchanged.

This particular enum is also a const enum. During compilation, the enum values are substituted directly with their real values, essentially erasing the existence of the enum. Nevertheless, TypeScript mandates accessing these values through the enum even though they are replaced.

To create an enum-like interface without this constraint, utilize an as const assertion on a standard JavaScript object. This produces something akin to an enum that can be employed similarly. However, TypeScript will not generate additional enum features like types; hence, it's a useful alternative:

export const MyEnum = {
  FOO: 'foo',
  BAR: 'bar',
} as const;
export type MyEnum = typeof MyEnum[keyof typeof MyEnum]; // 'foo' | 'bar'

TypeScript Playground

While this approach comes with its pros and cons, it closely emulates enums created using the enum keyword, making it a viable option in various scenarios.

One of the interfaces in use is malfunctioning, despite being identical to the other interface in TypeScript

Answer №1

Answer №2

Similar questions

What is the best way to create a case-insensitive sorting key in ag-grid?

Strategies for redirecting search queries when adding a new path

Issue with Angular 10 Web Worker: Unable to locate the main TypeScript configuration file 'tsconfig.base.json'

When attempting to pass an array of objects to a child component, TypeScript raises an error regarding types

Guidelines on declining a pledge in NativeScript with Angular 2

Is it recommended for TypeScript to automatically resolve the index.ts file as the default module file?

Using React Native to dynamically change color based on API response

How to handle form-data in NestJS Guards?

Create a full type by combining intersecting types

What are the steps for creating and deploying a project that utilizes asp.net core on the server-side and Angular on the client-side

Angular - Issue with Function Observable<number> in Development

Transforming Angular 4's folder structure for improved architecture simplicity

Embedded Facebook SDK posts appearing only after performing a hard refresh

The Angular checked functionality is not working as expected due to the presence of ngModel

Enhanced string key indexer type safety in TypeScript

Switch from Gulp-TSLint to Gulp-ESLint for enhanced code analysis!

In Angular Google Maps, here's a step-by-step guide on how to zoom in

In the latest version of Angular, accessing document.getelementbyid consistently returns null

Tips on utilizing the `arguments` property in scenarios where Parameters<...> or a similar approach is anticipated

Challenges faced when using an array of objects interface in Typescript