Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
Currently, the ABP Framework uses standard string/number enums in the Angular TypeScript codebase. Taking the eLayoutType enum from the @abp/ng.core package as an example, standard enums present critical limitations for frontend developers. I propose migrating all framework enums (including but not limited to eLayoutType) to hybrid enums (enum + type union) for better developer experience, type safety, and compatibility with modern Angular/TypeScript workflows.
Standard enums in ABP (such as eLayoutType) have the following limitations:
- No strict type checking for raw string/number values (only enum members are type-validated, making it error-prone when handling API responses or dynamic values).
- Poor compatibility with IDE auto-completion, template literals, and strict type checking in Angular templates.
- Inconvenient for dynamic value usage (e.g., parsing string values from URLs or API payloads) and integration with third-party libraries that expect raw string/number types.
Hybrid enums solve all these issues while retaining full backward compatibility and the utility of standard enums (object access, iteration, and existing usage patterns).
Describe the solution you'd like
Replace standard ABP enums with the hybrid enum pattern (enum + matching type union) across the Angular frontend codebase, using eLayoutType from@abp/ng.core as the reference example.
Example (Current Standard Enum in @abp/ng.core)
// Current implementation in @abp/ng.core
export enum eLayoutType {
Application = 'application',
Account = 'account',
Empty = 'empty'
}
Example (Proposed Hybrid Enum for eLayoutType)
// Proposed hybrid enum pattern in @abp/ng.core
export enum eLayoutTypeEnum {
Application = 'application',
Account = 'account',
Empty = 'empty'
}
// Type union to support both enum members and raw string values
export type eLayoutType = eLayoutTypeEnum | keyof typeof eLayoutTypeEnum;
// Retain backward compatibility by re-exporting the enum under the original name
export const eLayoutType = eLayoutTypeEnum;
Benefits
- Enhanced Type Safety: Supports both enum members (e.g., eLayoutType.Application) and raw string values (e.g., 'application') with full TypeScript validation, eliminating type casting errors.
- Better IDE Auto-Completion: Improves intellisense for eLayoutType and other enums in Angular components, templates, and services, reducing developer friction.
- Full Backward Compatibility: Existing code using eLayoutType.Application (or any other enum member) will continue to work without modification, as we re-export the enum under its original name.
- Modern TypeScript Best Practice: Aligns with official Angular/TypeScript recommendations for enum usage, especially in strict mode.
- Flexible API Integration: Seamlessly works with API response values (which often return raw strings/numbers) without extra type casting. For example, parsing a raw 'account' string from an API into eLayoutType is now type-safe.
- Template Compatibility: Works perfectly in Angular templates with strict mode enabled, avoiding common template type errors related to enum values.
Use Case (Using eLayoutType)
Developers can use the hybrid eLayoutType enum both ways safely, without breaking existing code:
// Original usage (enum member) - works as before
const layout = eLayoutType.Application;
// New usage (raw string, strictly typed) - no type errors
const layout: eLayoutType = 'application';
const layout: eLayoutType = 'account';
// Dynamic usage (e.g., from API response) - type-safe
const apiResponse = 'empty';
const layout: eLayoutType = apiResponse; // No type casting needed
// Iteration and object access - retains enum utility
Object.values(eLayoutType).forEach(type => console.log(type));
Affected Modules
All Angular frontend packages in the ABP Framework that use TypeScript enums, with priority given to core modules like:
- @abp/ng.core (including eLayoutType, eThemeSharedActions, etc.)
- @abp/ng.theme.shared
- @abp/ng.account
- @abp/ng.identity
- All other feature modules with TypeScript enums
Additional context
- This change is non-breaking and fully backward compatible—existing projects will not require any code changes.
- Minimal refactoring effort for the framework team: the hybrid pattern only adds a type union and re-export, without modifying existing enum values.
- Massive improvement for frontend developers using ABP Angular, especially those working with strict type mode and API integration.
- Compliant with TypeScript 4.0+ and all modern Angular versions supported by the ABP Framework.
Is there an existing issue for this?
Is your feature request related to a problem? Please describe the problem.
Currently, the ABP Framework uses standard string/number enums in the Angular TypeScript codebase. Taking the eLayoutType enum from the @abp/ng.core package as an example, standard enums present critical limitations for frontend developers. I propose migrating all framework enums (including but not limited to eLayoutType) to hybrid enums (enum + type union) for better developer experience, type safety, and compatibility with modern Angular/TypeScript workflows.
Standard enums in ABP (such as eLayoutType) have the following limitations:
Hybrid enums solve all these issues while retaining full backward compatibility and the utility of standard enums (object access, iteration, and existing usage patterns).
Describe the solution you'd like
Replace standard ABP enums with the hybrid enum pattern (enum + matching type union) across the Angular frontend codebase, using eLayoutType from@abp/ng.core as the reference example.
Example (Current Standard Enum in @abp/ng.core)
// Current implementation in @abp/ng.core
export enum eLayoutType {
Application = 'application',
Account = 'account',
Empty = 'empty'
}
Example (Proposed Hybrid Enum for eLayoutType)
// Proposed hybrid enum pattern in @abp/ng.core
export enum eLayoutTypeEnum {
Application = 'application',
Account = 'account',
Empty = 'empty'
}
// Type union to support both enum members and raw string values
export type eLayoutType = eLayoutTypeEnum | keyof typeof eLayoutTypeEnum;
// Retain backward compatibility by re-exporting the enum under the original name
export const eLayoutType = eLayoutTypeEnum;
Benefits
Use Case (Using eLayoutType)
Developers can use the hybrid eLayoutType enum both ways safely, without breaking existing code:
// Original usage (enum member) - works as before
const layout = eLayoutType.Application;
// New usage (raw string, strictly typed) - no type errors
const layout: eLayoutType = 'application';
const layout: eLayoutType = 'account';
// Dynamic usage (e.g., from API response) - type-safe
const apiResponse = 'empty';
const layout: eLayoutType = apiResponse; // No type casting needed
// Iteration and object access - retains enum utility
Object.values(eLayoutType).forEach(type => console.log(type));
Affected Modules
All Angular frontend packages in the ABP Framework that use TypeScript enums, with priority given to core modules like:
Additional context