Activities of "pjanda"

Hi, that's a great news, that is exactly what I was hoping for. Thank you. We are currently fixing generated proxy manually but as you can imagine, it is quite annoying especially when working on a project with a group of developers where we re-generate proxies frequently.

Thanks for the update.

Pavel

Hi,

I am sorry, but I am not really happy with your answer. We are a paying customer and as such I would expect similar issues to be considered for fixing rather than being advised to disable type checking. Disabling strict type checking is only hiding the issue but not resolving it!

You you are saying that it is correct that DTOs in Angular and .NET are different and they are not going to get fixed? Have a look at definitions of ExtensibleLimitedResultRequestDto both .NET and Angular side. Is that really such a big issue to change the following definition in abp-ng.core.d.ts:

declare class ExtensibleEntityDto<TKey = string> extends ExtensibleObject { id?: TKey; constructor(initialValues?: Partial<ExtensibleEntityDto<TKey>>); }

so id column is defined as id?: TKey | null; to correspond to the way your proxy generator has been updated to in ABP 10.x?

Or to update the following definition in the same file so ExtensibleLimitedResultRequestDto does not have id column at all same way it is in .NET? I still consider this to be an issue as having different columns in DTOs server and client side is not correct, no matter what other purpose it has been done for!

declare class ExtensibleLimitedResultRequestDto extends ExtensibleEntityDto { maxResultCount: number; constructor(initialValues?: Partial<ExtensibleLimitedResultRequestDto>); }

This really prevents us from extending pretty much any ABP.IO base class as the is no way to direct proxy generator to ignore some methods and once we extend IdentityAppService, it will generate models for all existing methods and then we will get a compilation error.

Thanks, Pavel

Hi,

you can easily test it by creating a blank application and adding a single AppService inheriting from IdentityUserAppService. No need to override anything. See the service below:

using System; using System.Linq; using System.Threading.Tasks;

using Microsoft.AspNetCore.Identity; using Microsoft.Extensions.Options;

using Volo.Abp.Application.Dtos; using Volo.Abp.Authorization.Permissions; using Volo.Abp.Caching; using Volo.Abp.EventBus.Distributed; using Volo.Abp.Identity; using Volo.Abp.Threading;

namespace Test.Identity;

public class MyIdentityUserAppService : IdentityUserAppService { public MyIdentityUserAppService( IdentityUserManager userManager, IIdentityUserRepository userRepository, IIdentityRoleRepository roleRepository, IOrganizationUnitRepository organizationUnitRepository, IIdentityClaimTypeRepository claimTypeRepository, IdentityProTwoFactorManager twoFactorManager, IOptions<IdentityOptions> identityOptions, IDistributedEventBus eventBus, IOptions<AbpIdentityOptions> abpIdentityOptions, IPermissionChecker permissionChecker, IDistributedCache<IdentityUserDownloadTokenCacheItem, string> userDownloadTokenCache, IDistributedCache<ImportInvalidUsersCacheItem, string> importInvalidUsersCache, IdentitySessionManager sessionManager, IdentityUserTwoFactorChecker userTwoFactorChecker, ICancellationTokenProvider cancellationTokenProvider) : base( userManager, userRepository, roleRepository, organizationUnitRepository, claimTypeRepository, twoFactorManager, identityOptions, eventBus, abpIdentityOptions, permissionChecker, userDownloadTokenCache, importInvalidUsersCache, sessionManager, userTwoFactorChecker, cancellationTokenProvider) { } }

Once you have this, compile it and generate client proxies in Angular. If you then set script flag to true (to ensure TypeScript properly checks data types), you will get an error described in the original post.

My comment from 2 days ago then describes why it is happening and the differences between base DTOs in Angular packages and in .NET. This was not an issue in ABP.IO 9.3.7.

Thanks, Pavel

Hi,

our issue is not with isolatedModules configuration in TypeScript so perhaps we should concentrate on the original issue. Changing isolatedModules configuration has no effect on our issue.

The issue is really in ABP.IO npm packages that do not have types defined correctly. Would it be possible to fix those so they correspond to server side DTOs and current logic for proxy class generation? I would consider this to be a bug in the framework.

Thanks, Pavel

Hi,

I don't really agree that the issue is caused by the TypeScript options. These options are used for strict type checking in our code and we do want to keep them. These flags will only make the describe issue to transpire.

The issue is really in ABP.IO npm packages that do not have types defined correctly. Would it be possible to fix those so they correspond to server side DTOs and current logic for proxy class generation?

Thanks, Pavel

ok, sure. Below is our tsconfig.json file:

/* To learn more about this file see: https://angular.io/config/tsconfig. */ { "compileOnSave": false, "compilerOptions": { "baseUrl": "./", "outDir": "./dist/out-tsc", "strict": true, "noImplicitOverride": true, "noPropertyAccessFromIndexSignature": true, "noImplicitReturns": true, "noFallthroughCasesInSwitch": true, "skipLibCheck": true, "isolatedModules": true, "esModuleInterop": true, "experimentalDecorators": true, "moduleResolution": "bundler", "importHelpers": true, "target": "ES2022", "module": "ES2022", //"sourceMap": true, "declaration": false, "lib": ["ES2022", "dom", "esnext.disposable"], "paths": {}, "useDefineForClassFields": false }, "angularCompilerOptions": { "enableI18nLegacyMessageIdFormat": false, "strictInjectionParameters": true, "strictInputAccessModifiers": true, "strictTemplates": true } }

Our TypeScript version 5.9.3 and we use npm-installed version of the packages. We should be on the latest versions as of last Wednesday.

Thanks, Pavel

Hi,

I don't think this is related to TypeScript configuration but rather to the changes made in proxy class generation logic in ABP 10.x as described in https://abp.io/support/questions/10400/ABP-10-Angular-proxy-required-C-fields-generated-as-optional-in-TypeScript

Id field in GetIdentityUsersInput in .NET (Volo.Abp.Identity.Pro.Application.Contracts) is defined as: public Guid? Id

However, it TypeScript, it is defined in a base class ExtensibleEntityDto (abp-ng.core.d.ts) as id?: TKey. This does not correspond to .NET definition where Id field is not present on same DTO but also it does not correspond to changes made to proxy class generation.

So when GetIdentityUsersInput interface is generated using proxy class generation, it will generate Id field as id?: string | null;. Since it is inheriting from ExtensibleEntityDto, it will fail to compile.

I can see two different issues:

• DTOs between .NET and Angular are not the same (in ABP.IO packages) - this is what is causing the issue described above
• DTOs in Angular are not following the pattern used by proxy generator (in ABP.IO packages) - this is what might be causing issues but not a direct cause of the above.

Thanks, Pavel