Hi i have the same problem adding to angular js legacy app, ng-if breaks the angular web component.

To make sure we are on the same page, here is what the intention is with the current implementation:

• When the custom element is removed from the DOM, the underlying component is scheduled for destruction after a short timeout (currently 10ms).
• If the custom element is inserted back into the DOM before the timeout expires, then the component destruction is canceled and we keep the same component instance.
• If the custom element is inserted back into the DOM after the timeout, then the component has been destroyed and we should create a new component instance.

This last bullet point is what we are failing to do at the moment, as mentioned in the previous comment (which is a bug), but that was the intention.

The reason we destroy the component instance is that there is some Angular-specific cleaning up that needs to happen when the element (and thus the underlying component instance) is no longer necessary (i.e. removed from the DOM for good).

The reason we have the short delay between removing the custom element from the DOM and destroying the component instance is to account for cases where you want to “move” the element around (i.e. remove it from its current location in the DOM and immediately insert it at a new location). In that case, it would be a waste to destroy the component synchronously, only to re-instantiate it right after.

From a quick look, it seems that fixing the current bug (i.e. allowing the component to be re-instantiated when the host element is re-inserted into the DOM) is not trivial. For example, how do we handle content projection. The original nodes have been extracted from the host element the first time, so they are no longer there for us to extract. (We could cache them and re-use the same nodes, but I wouldn’t be surprized if this broke in some edge cases.)

Even if we managed to fix this and allow the component to be re-instantiated, the internal state of the original component instance would not have been retained. This would lead to unexpected UI differences.

The main problem here is that there is no good way to automatically infer whether a removed element is intended to be re-used some time in the future (and thus the underlying component instance should be retained) or whether it is not needed any more (and thus the underlying component instance should be destroyed).

Therefore, we have to resort to unreliable heuristics (“if you haven’t added it back after 10ms you probably don’t need it”).

An alternative approach would be to provide a way for people to denote that they intend to re-use a particular custom element and therefore the underlying component instance should not be destroyed after the element has been removed from the DOM. Something like:

myCustomElement.remove();

// I might reuse this in the future. Do not destroy the underlying component.
myCustomElement.ngRetainComponentInstance();

As a work-around, you can basically do this manually today (by using some private properties 😇):

myCustomElement.remove();

myCustomElement.ngElementStrategy.scheduledDestroyFn()
myCustomElement.ngElementStrategy.scheduledDestroyFn = null;

https://github.com/angular/angular/issues/38778#issuecomment-697931683

The work-around at the bottom of https://github.com/angular/angular/issues/38778#issuecomment-690433315 does not work for us for 2 reasons: (1) the component is destroyed by the @angular/animations package (I’ve filed https://github.com/angular/angular/issues/38962 for that) and (2) the inputs are not reinitialized from the HTML attributes when it reconnects.

I also bumped into this recently, we found that using a setter seems to give consistent results when trying to assign values from inputs on any subsequent initializations of an angular/elements web component.

private _myValue = '';

@Input()
set myValue(value: string) {
  if (value) {
    this._myValue = value;
  }
}

The caveat is that the setters seem to run after the child component loaded in the router-outlet tries to access the value, which was solved with a boolean that’s set to true in the afterViewInit function.

Something like this in the AppComponent:

<div *ngIf="isInit">
 <router-outlet></router-outlet>
</div>

public isInit = false;

// allows the setters to execute
ngAfterViewInit(): void {
 this.isInit = true;
}

Doesn’t solve the root issue, but has unblocked our work thus far.

This bug is so severe that basically prevents Angular Elements from being used for developing a component library, unless developers are asked to avoid detaching and reattaching elements - which is a totally ludicrous request.

I’ve fiddled around this problem using a custom NgElementStrategyFactory class, basically copying the original ComponentNgElementStrategyFactory (this is not good DX, folks… I hope it’ll get there) but removing the return in the connect method (also references to Zone.js). That seemed fine and the component would get recreated, but… then it crashes as soon as ShadowDomRenderer tries to reattach the Shadow DOM without checking if there’s one already (note: this is also incompatible with Declarative Shadow DOM) and eventually reusing or removing its content.

I don’t know if it’s worth considering making a PR out of this, since many other things are out of my comprehension of the problem, but let me know. I haven’t even checked if the other encapsulation modes are fine.

Anyway, I’d like to say that it’s natural to compare the life cycle of Web Components to the one of Angular components, so that ngOnInit/ngAfterViewInit are basically the equivalent of connectedCallback, while ngOnDestroy is basically disconnectedCallback. As developers, I think we need to rely on this.

The work-around at the bottom of https://github.com/angular/angular/issues/38778#issuecomment-690433315 does not work for us for 2 reasons: (1) the component is destroyed by the @angular/animations package (I’ve filed https://github.com/angular/angular/issues/38962 for that) and (2) the inputs are not reinitialized from the HTML attributes when it reconnects. Furthermore, we would prefer to not couple Angular Element removal logic with our host application.

My main goal when filing this bug was to see if we could get removing and re-adding an Angular Element to work. I don’t mind if the element needs to re-render or reinitialize. I solely want the host application to be capable of removing and re-adding the element and the element to be in the correct state when re-added.

[Deleted comment as I was incorrectly thinking that there could be multiple elements assigned to a single strategy instance]

Disregard the part about the race condition - I think I was wrong about that. The comments below stand.