GeezerVison

Thx for putting together a pull request, @yefim!

I am still wary of getting down the path of trying to re-create the component instance, because there are too many concerns/edge cases to account for, including:

1. How do we recreate the destroyed component's state?

   For regular Angular components (not Angular elements), this is easy because the component's inputs come through templates and other components' properties. For Angular elements however, people might in addition have interacted with the host element directly (both via setting attributes and properties).

   For example, it is hard to know what value to initialize an input to. Should we use the value from the host element attribute, the host element property or the previous component instance's property? (The component could be updating these values internally without reflecting the changes on the host element attributes/properties. Or the host element properties could have been updated with new values after the component has been destroyed.)

2. Even if we managed to re-create the component's external state, its internal/UI state could be different. This might be expected when explicitly re-creating a component in an Angular all (e.g. via a structural directive such as ngIf). However, in an Angular element setup, people interacting with a custom element would expect it to behave like most regular HTML elements, which don't lose their internal state when detached from the DOM for a brief time.

3. How do we handle projected nodes?

   Do we clone the originally projected nodes and re-insert them into the host element? This would break any external references to the nodes?

   Do we keep references to the originally projected nodes (and their assigned projection slots) and use those when instantiating the new component? What if the nodes have been replaced in the meantime (e.g. by a structural directive)?

I am not saying this is impossible to get right, but it is definitely an uphill battle (and a maintenance burden). But I would rather explore other approaches first.

Basically, the problem we are trying to solve is this: Keep a removed component intact when it is going to be used again in the future, but allow it to be garbage-collected when not needed any more.

The difficulty arises from the fact that Angular itself does not know what the intention is when an Angular element is removed from the DOM. Possible solutions (off the top of my head):

• Have a way to "suspend" a component (i.e. detach it from the app's internal processing, such as change detection), but otherwise keep its internal state. But do this in a way that would allow the component (and associated data) to be garbage-collected if its host element is not referenced any more. This way, the component would remain intact as long as we have a reference to its host element (because we intend to add it back to the DOM later), but could be garbage-collected if we don't hold onto the host element.

  One caveat is that when unsuspending the component it's inputs should be populated with the latest values.

• Have an (opt-in) way to give the app developer the power (and responsibility) to decide if/when a component will be destroyed (see #38778 (comment) for how to hack your way to this today). This way, component's would be destroyed by default when removed from the DOM, but the user could choose to keep them around and manually trigger their destruction when needed.

  For example, there could be a method on the element to skip destroying the component. Or there could be a new NgElementStrategy that does not destroy components when removed from the DOM. In both cases, there would be a method to call when you want to destroy an Angular element component.

@yefim, wdyt?