I had not noticed the removal of emitDecoratorMetadata. However, no, it still doesn't work.

Appears the reason here is that Angular places ngComponentDef generated code before all __decorate calls for class. ɵɵdefineComponent function takes onInit as a reference to Class.prototype.ngOnInit and overridding it later has no any effect.

Here's a pseudo-code of what happens:

class Test {
  ngOnInit() {
    console.log('original')
  } 
}

const hook = Test.prototype.ngOnInit;

Test.prototype.ngOnInit = () => {
  console.log(1);
}

hook(); // prints 'original'

In case of JIT compilation componentDef is created lazily as soon as getComponentDef gets called. It happens later.

Yeah, this is unfortunately WAI.

Angular's compiler btw has no say in the location of ngComponentDef vs the __decorate call - this is the way TypeScript naturally compiles static fields. See this example. The time at which the lifecycle hook is read off the class is an implementation detail of the runtime, and the way we do things now in Ivy is an optimization.

Transferring this to core as there's nothing we can do on this from the compiler side - the behavior in question is the snapshotting of ngOnInit prior to decorator execution.

Any update on this issue?
Is there a workaround so far?

Given a class decorator

function Mixin(value) {
    return function(target) {
        target.prototype.ngOnInit = function () {
            console.log("ngOnInit", value)
        }
    }
}

@Component({ ... })
@Mixin({ value: 123 })
export class AppComponent {}

This workaround should work in Ivy

const Extend = Mixin({ value: 123 })

@Component({ ... })
export class AppComponent {
    static mixins = Extend(AppComponent)
}

For ViewEngine compatibility, you also need to add a stub for ngOnInit

@Component({ ... })
export class AppComponent {
    public ngOnInit?()
    static mixins = Extend(AppComponent)
}

Assigning to a static property on the class forces the mixin to be executed before the runtime snapshots the class.

@kumaresan-subramani From within your empty lifecycle methods, you should delegate into the mixin field.

Hi @JoostK ,

Any update on this?

I have tried with latest v9.0.0-rc.4 but still not working

HI @JoostK ,

Can you please provide timeline for this issue?

@kumaresan-subramani the team doesn't normally provide ETAs or timelines for issue resolution. Based on the milestone, this is not being considered for version 9 final. It's possible that it could go into a 9.x minor or patch, be pushed to version 10, or it could be pushed even later.

If you feel like the priority needs to be raised, please provide a clear use case that demonstrates a significant issue that does not have a workaround. If this is a problem for a Syncfusion library, please explain the issue, impact, and workarounds attempted.

Appears the reason here is that Angular places ngComponentDef generated code before all __decorate calls for class. ɵɵdefineComponent function takes onInit as a reference to Class.prototype.ngOnInit and overridding it later has no any effect.

angular/packages/core/src/render3/definition.ts

Line 264 in 58be2ff

onInit: typePrototype.ngOnInit || null,

Here's a pseudo-code of what happens:

class Test {
  ngOnInit() {
    console.log('original')
  } 
}

const hook = Test.prototype.ngOnInit;

Test.prototype.ngOnInit = () => {
  console.log(1);
}

hook(); // prints 'original'

In case of JIT compilation componentDef is created lazily as soon as getComponentDef gets called. It happens later.

reason - #30818 (comment)

Hi @Splaktar , you can find reasons above

Workaround attempted

#31495 (comment)
#31495 (comment)

@JoostK

Thank you.
#35314 is closed, but I think the problem still exists.

My scenario is exactly like this

Add dynamic components to EntryComponents does not work anymore.

What should we do in this situation?

@abadakhshan Please see #35314 (comment) for how to resolve the problem. The issue is closed because the framework is working as intended.

It appears the issue I was running into was the same one that @abadakhshan describes here. My app makes heavy use of dynamically instantiated components that often times aren't referenced by the app other than in the NgModule declarations. It appears the reason my custom decorator isn't working is because those components are being tree-shaken from the build. So in my situation this isn't a defect of angular, but rather an education on Ivy...

Any updates on this? We cannot move our project to ng9.

This is a truly awful problem. Please fix it quickly as the version up of the internal project cannot be done.

#37068 (comment)

Please take a look at #35464. Hopefully this might resolve the issue for you?

See above, there is a PR on this problem.

Any update after v10 is out?

@khiami you can track progress in PR #35464

@Splaktar @pkozlowski-opensource Hello, it was written above that we need to specify a use case in order to increase the priority of this issue. Well as you can see, a typical use case is for decorators which override component life-cycle hooks handlers (ngOnInit, ngOnDestrory) in order to more easily and safely subscribe to and unsubscribe from various streams. As you can see above, this feature has been in demand. And it has ceased to work in Ivy. This is not a matter of "regression", but of (significant) "convenience", and safely.
So can you raise the priority of this issue?
TIA

I beg to differ on this not being a regression. It worked in previous versions, Ivy breaks it - regression. Furthermore, Ivy gets in the way of JS nature/features, like overwriting the prototype method. Make no mistake, this is not limited to the decorators only.

Another popular example is a custom takeUntilDestroy rxjs operator, which is nothing else than a function accepting an instance of component class.

This however should not reduce the priority of this issue.

In my custom operator I ended up relying on private ɵcmp property instead of prototype, in hope Angular will eventually fix this:

if (instanceConstructor.ɵcmp) {
  // Using private API until the corresponding Angular issues are resolved.
  // Issues:  https://github.com/angular/angular/issues/31495, https://github.com/angular/angular/issues/30497
  // PR:      https://github.com/angular/angular/pull/35464
  destroy = <Function>instanceConstructor.ɵcmp.onDestroy ?? noop;
  instanceConstructor.ɵcmp.onDestroy = __takeUntilDestroy__destroy__;
} else {
  destroy = <Function>instanceConstructor.prototype.ngOnDestroy ?? noop;
  instanceConstructor.prototype.ngOnDestroy = __takeUntilDestroy__destroy__;
}

I found out that this workaround create errors in JIT if your decorator is after @Component() like this:

@CustomDecorator()
@Component({ ...})
export class Comp {}

because (my guess from debugging it) ɵcmp in JIT is a getter that compiles the component. But when the decorators are executed the compiler is not ready (I think imported modules are not yet availables, as I had errors on ngIf not being an input on div).

So the workaround is to check that we are in AOT before getting the ɵcmp property :

export function getLifecycleHook(instanceConstructor: Function, hook: 'ngOnDestroy' | 'ngOnInit' | 'ngOnChanges') {
	const desc = Object.getOwnPropertyDescriptor(instanceConstructor, ɵNG_COMP_DEF);
	if (!!desc && !desc.get) { // check for ivy AND aot
		// Using private API until the corresponding Angular issues are resolved.
		// Issues:  https://github.com/angular/angular/issues/31495, https://github.com/angular/angular/issues/30497
		// PR:      https://github.com/angular/angular/pull/35464
		return instanceConstructor[ɵNG_COMP_DEF]['o' + hook.slice(3)];
	} else {
		return instanceConstructor.prototype[hook];
	}
}

And this works both in AOT and JIT.

Also if you put your decorators after @Component() (so that yours is executed first), it works because ɵcmp is not yet defined.

Needed this because AOT is still unusable for development with large project.

Using custom decorators with AoT and Ivy is also high priority for us.

@wsdt This was already fixed in Angular v10.0.5.

@hakimio Thank you ! :-)

Appears the reason here is that Angular places ngComponentDef generated code before all __decorate calls for class. ɵɵdefineComponent function takes onInit as a reference to Class.prototype.ngOnInit and overridding it later has no any effect.

angular/packages/core/src/render3/definition.ts

Line 264 in 58be2ff

onInit: typePrototype.ngOnInit || null,

Here's a pseudo-code of what happens:

class Test {
  ngOnInit() {
    console.log('original')
  } 
}

const hook = Test.prototype.ngOnInit;

Test.prototype.ngOnInit = () => {
  console.log(1);
}

hook(); // prints 'original'

In case of JIT compilation componentDef is created lazily as soon as getComponentDef gets called. It happens later.

reason - #30818 (comment)

Hi @Splaktar , you can find reasons above

Workaround attempted

#31495 (comment)
#31495 (comment)

HI @hakimio ,

I think issue not get fixed still facing same issue.

My angular packages:

dependencies": {
    "@angular/animations": "~10.0.9",
    "@angular/common": "~10.0.9",
    "@angular/compiler": "~10.0.9",
    "@angular/core": "~10.0.9",
    "@angular/forms": "~10.0.9",
    "@angular/platform-browser": "~10.0.9",
    "@angular/platform-browser-dynamic": "~10.0.9",

@kumaresan-subramani just use ngx-observable-lifecycle if you can not get it to work.

As reported by @hakimio, after over a year this issue was fixed in Angular v10.0.5. If there were other problems, I think more specific issues should be open, and therefore I am closing it.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}