Angular ngzone relations

[refactorTractor]

Hi!

Your article mentions that to avoid problems, one should share NgZone between angular microfrontends. What are those problems that could arise?

Would it be a good alternative to fork the host's zone, and make the remote use that? I imagine that the host's wrapper component could inject ngZone, call run, inside the run callback fork the zone and then append the angular element running in that zone. Looking through the code I see that NgZone of the mfe would just fork the current zone - which is itself a fork of the host's zone.

(Sadly I have a browser API to decorate for remotes only)

[refactorTractor]

As I read about it, forking the host's zone would not be good, because if I patch in the child zone that will decorate the parent zone's execution as well (not good if I want to patch only the remote's zone). My alternative is then forking from the host's parent (I could achieve that by creating and appending the remote's element in a runOutsideAngular callback). I'm guessing the downside to that might be that events between remote and host don't trigger each other's change detection? Or is there some other pitfall?

[Greech]

As I read about it, forking the host's zone would not be good, because if I patch in the child zone that will decorate the parent zone's execution as well (not good if I want to patch only the remote's zone). My alternative is then forking from the host's parent (I could achieve that by creating and appending the remote's element in a runOutsideAngular callback). I'm guessing the downside to that might be that events between remote and host don't trigger each other's change detection? Or is there some other pitfall?

Do you have working example where you initialise the child zone inside the unOutsideAngular?

I am not sure if you can entirely avoid zone collision, as both zones are working on the same window events. So that would be a pitfall.