NoopZone implementation: make onMicrotaskEmpty() and onStable() emit in the next microtask about angular HOT 8 CLOSED

Realistically, however, it will take years for all popular libraries and existing apps to migrate, that’s why I proposed this temporary solution

That’s certainly a concern. To that, we’ll just have to see. We have to go through the exercise of moving the entire components repository off of the NgZone interface and we’ll see how that goes.

At this point in the process, faking the emits is making an assumption about what libraries are expecting from that API. What we do might not satisfy that use-case at all. For example, SSR relies on zone stability to know when to serialize the page. The fake event emits are nowhere close to satisfying this requirement. For other use-cases, afterNextRender might be a drop-in replacement. The library author does need to make a choice here. Waiting for support would be the same for any breaking change released in a major version.

As a side note, your “hack” in the other issue isn’t exactly required to accomplish your goal. BootstrapApplication gets NgZone from providers so you can just provide your NgZone implementation after provideZonelessChangeDetection and it would override like any other provider.

from angular.

NoopNgZone is exactly that: a no-op. There won’t be any updates to its implementation to be more than that.

from angular.

Maybe create one more NgZone implementation with a different name but what would let apps work in a zoneless mode?

from angular.

Maybe create one more NgZone implementation with a different name but what would let apps work in a zoneless mode?

As mentioned in #54125 (comment), this is a consideration as a temporary compatibility solution (but rather unlikely to happen, in all honesty). Bringing the NgZone interface forward into the Zoneless world is not a good fit.

There’s no way to make the zone-based events have the same meaning without zones (and the differences do matter). Further, the best-effort fake emits would effectively mirror what would be available to libraries with other APIs (afterNextRender). We would want to move the community in this direction instead so they have the same behavior in Zone and Zoneless applications.

from angular.

That all makes perfect sense, I understand your plan.
Realistically, however, it will take years for all popular libraries and existing apps to migrate, that’s why I proposed this temporary solution. A solution that could work for a few years is useful enough to maintain, I think.

from angular.

I understand you better now, thank you.

What would be a solution for a service? (where you can’t use afterNextRender())

Thank you for the hint about that hack - you are right, I didn't think about that.

from angular.

What would be a solution for a service? (where you can’t use afterNextRender())

I think what you need is this: 80b953a

This brings up another reason we want to avoid the proposed stop-gap solution: doing that would make it possible to ignore the compatibility problem for longer. We can use the lack of the fake NgZone as a forcing function to drive feedback and development of better replacement APIs. There have been several discoveries through our own explorations here that have led to changes in how the afterRender hooks work to better serve as an NgZone replacement.

from angular.

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.}

from angular.