Support for native async await when using noop zone js
🚀 Feature request
Command (mark with an x)
- [ ] new
- [x] build
- [ ] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] extract-i18n
- [ ] run
- [x] config
- [ ] help
- [ ] version
- [ ] doc
Description
A way to enable native async/await. We have a large Angular 13 project running absolutely fine without zone.js
Have the ability to remove the plugin-transform-async-to-generator from the transpile stage. I’ve removed manually for now and everything works. The debugging experience is very nice in a no zone.js native async/await Angular project.
Could this be achieved with a new build option?. Or maybe there is a better way to remove the plug-in that I haven't found.
Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.
Find more details about Angular's feature request process in our documentation.
Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.
Is there a way to remove the plugin-transform-async-to-generator using some kind of webpack / babel configuration for specific libraries?
It seems that we introduced an async-await in the worker code and importing this library in Angular completely breaks the library (maplibre-gl) and the angular app.
See the following discussion:
https://github.com/maplibre/maplibre-gl-js/discussions/3210
Any help would be approceicated! cc: @JeanMeche
@alan-agius4 , this Feature Request didn't get enough votes two years ago, but when a recent issue was opened with the same request, you closed it as a duplicate of this, without giving it a chance to get the needed votes (it's likely more popular request now due to much higher browser support for await/async). Does it mean that this is already on the roadmap?
considering that zone.js might be optional https://angular.io/guide/roadmap#improve-runtime-performance-and-developer-experience-with-a-new-reactivity-model using native async-await in Angular might be even more natural than before 🚀
@ranma42 , right, it'll be very convenient, but it's not working yet as of the latest v17.0.0-next.8. Using Signals, and removing zone.js, doesn't pass the reactive system to Signals - instead it's still mandated to add the manual calls for change detection.
IMO this voting process deadline doesn't accomodate the idea that most people that use angular don't search for an issue until they encounter it. There are very few angular developers that continually scan the issue list for ideas to vote on.
IMO issues should be re-opened when they exceed 20 votes, if they were closed due to not enough votes.
Is it possible to use this feature while still using zone? While there's a big hype and comment around why zone.js is bad and that I shouldn't be using it, there is almost zero documentation on how to really remove it from my app (without almost doing a full rewrite, which for me is counter productive as bundle size is a lot less important than code that actually works well)...
The following library is using zone.js heavily so removing it will require a lot of work, this library is the main reason I commented in this issue: https://github.com/maplibre/ngx-maplibre-gl
P.S. this is almost the only documentation I found about zone.js and it is describing a super super simple case, and it is obvious that even for this super super simple case, there is a lot of (risky) work that needs to be done: https://github.com/manfredsteyer/articles/blob/master/angular-elements-without-zonejs.md
Is it possible to use this feature while still using zone
No, in order for ZoneJS to work properly, it needs to patch all async microtasks. Mixing zone-patched tasks with native tasks will result in them executing in the wrong order.
The uses of NgZone in the library you mentioned do not look problematic. There should be no problem using it in a Zoneless application.
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.