fix(upgrade): fix HMR for hybrid applications#40045
fix(upgrade): fix HMR for hybrid applications#40045gkalpak wants to merge 5 commits intoangular:masterfrom
Conversation
|
You can preview 204e21e at https://pr40045-204e21e.ngbuilds.io/. |
jelbourn
left a comment
There was a problem hiding this comment.
LGTM
Reviewed-for: public-api
There was a problem hiding this comment.
nit: could probably use a JsDoc description on this function and on destroy app (which IDEs will pick up)
atscott
left a comment
There was a problem hiding this comment.
Reviewed-for: public-api
AndrewKushnir
left a comment
There was a problem hiding this comment.
Reviewed-for: public-api
petebacondarwin
left a comment
There was a problem hiding this comment.
Can you explain why this is the case?
For "ngUpgradeLite" apps (i.e. those using
downgradeModule()), HMR
will only work if there is at least one Angular component present on the
page.
There was a problem hiding this comment.
| // other usecases where desposing of an Angular/AngularJS app is necessary (such | |
| // other use-cases where disposing of an Angular/AngularJS app is necessary (such |
There was a problem hiding this comment.
| // other usecases where desposing of an Angular/AngularJS app is necessary (such | |
| // other use-cases where disposing of an Angular/AngularJS app is necessary (such |
This commit removes a couple of unused variables.
This commit moves the code for cleaning jqLite/jQuery data on an element to a re-usable helper function. This way it is easier to keep the code consistent across all places where we need to clean data (now and in the future).
Previously, trying to apply a change via Hot Module Replacement (HMR) in a hybrid app would result in an error. This was caused by not having the AngularJS app destroyed and thus trying to bootstrap an AngularJS app on the same element twice. This commit fixes HMR for hybrid apps by ensuring the AngularJS app is destroyed when the Angular `PlatformRef` is [destroyed][1] in the [`module.hot.dispose()` callback][2]. NOTE: For "ngUpgradeLite" apps (i.e. those using `downgradeModule()`), HMR will only work if the downgraded module has been bootstrapped and there is at least one Angular component present on the page. The is due to a combination of two facts: - The logic for setting up the listener that destroys the AngularJS app depends on the downgraded module's `NgModuleRef`, which is only available after the module has been bootstrapped. - The [HMR dispose logic][3] depends on having an Angular element (identified by the auto-geenrated `ng-version` attribute) present in the DOM in order to retrieve the Angular `PlatformRef`. [1]: https://github.com/angular/angular-cli/blob/205ea2b638f154291993bfd9e065cd66ff20503/packages/angular_devkit/build_angular/src/webpack/plugins/hmr/hmr-accept.ts#L75 [2]: https://github.com/angular/angular-cli/blob/205ea2b638f154291993bfd9e065cd66ff205033/packages/angular_devkit/build_angular/src/webpack/plugins/hmr/hmr-accept.ts#L31 [3]: https://github.com/angular/angular-cli/blob/205ea2b638f154291993bfd9e065cd66ff205033/packages/angular_devkit/build_angular/src/webpack/plugins/hmr/hmr-accept.ts#L116 Fixes angular#39935
204e21e to
885710a
Compare
Expanded on this in the commit message. (Also updated the PR description.) Thx for the reviews. I have addressed the comments. Marking for merging... |
|
You can preview 885710a at https://pr40045-885710a.ngbuilds.io/. |
This commit removes a couple of unused variables. PR Close #40045
Previously, trying to apply a change via Hot Module Replacement (HMR) in a hybrid app would result in an error. This was caused by not having the AngularJS app destroyed and thus trying to bootstrap an AngularJS app on the same element twice. This commit fixes HMR for hybrid apps by ensuring the AngularJS app is destroyed when the Angular `PlatformRef` is [destroyed][1] in the [`module.hot.dispose()` callback][2]. NOTE: For "ngUpgradeLite" apps (i.e. those using `downgradeModule()`), HMR will only work if the downgraded module has been bootstrapped and there is at least one Angular component present on the page. The is due to a combination of two facts: - The logic for setting up the listener that destroys the AngularJS app depends on the downgraded module's `NgModuleRef`, which is only available after the module has been bootstrapped. - The [HMR dispose logic][3] depends on having an Angular element (identified by the auto-geenrated `ng-version` attribute) present in the DOM in order to retrieve the Angular `PlatformRef`. [1]: https://github.com/angular/angular-cli/blob/205ea2b638f154291993bfd9e065cd66ff20503/packages/angular_devkit/build_angular/src/webpack/plugins/hmr/hmr-accept.ts#L75 [2]: https://github.com/angular/angular-cli/blob/205ea2b638f154291993bfd9e065cd66ff205033/packages/angular_devkit/build_angular/src/webpack/plugins/hmr/hmr-accept.ts#L31 [3]: https://github.com/angular/angular-cli/blob/205ea2b638f154291993bfd9e065cd66ff205033/packages/angular_devkit/build_angular/src/webpack/plugins/hmr/hmr-accept.ts#L116 Fixes #39935 PR Close #40045
Previously, trying to apply a change via Hot Module Replacement (HMR) in a hybrid app would result in an error. This was caused by not having the AngularJS app destroyed and thus trying to bootstrap an AngularJS app on the same element twice. This commit fixes HMR for hybrid apps by ensuring the AngularJS app is destroyed when the Angular `PlatformRef` is [destroyed][1] in the [`module.hot.dispose()` callback][2]. NOTE: For "ngUpgradeLite" apps (i.e. those using `downgradeModule()`), HMR will only work if the downgraded module has been bootstrapped and there is at least one Angular component present on the page. The is due to a combination of two facts: - The logic for setting up the listener that destroys the AngularJS app depends on the downgraded module's `NgModuleRef`, which is only available after the module has been bootstrapped. - The [HMR dispose logic][3] depends on having an Angular element (identified by the auto-geenrated `ng-version` attribute) present in the DOM in order to retrieve the Angular `PlatformRef`. [1]: https://github.com/angular/angular-cli/blob/205ea2b638f154291993bfd9e065cd66ff20503/packages/angular_devkit/build_angular/src/webpack/plugins/hmr/hmr-accept.ts#L75 [2]: https://github.com/angular/angular-cli/blob/205ea2b638f154291993bfd9e065cd66ff205033/packages/angular_devkit/build_angular/src/webpack/plugins/hmr/hmr-accept.ts#L31 [3]: https://github.com/angular/angular-cli/blob/205ea2b638f154291993bfd9e065cd66ff205033/packages/angular_devkit/build_angular/src/webpack/plugins/hmr/hmr-accept.ts#L116 Fixes #39935 PR Close #40045
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Previously, trying to apply a change via Hot Module Replacement (HMR) in a hybrid app would result in an error. This was caused by not having the AngularJS app destroyed and thus trying to bootstrap an AngularJS app on the same element twice.
This commit fixes HMR for hybrid apps by ensuring the AngularJS app is destroyed when the Angular
PlatformRefis destroyed in themodule.hot.dispose()callback.NOTE:
For "ngUpgradeLite" apps (i.e. those using
downgradeModule()), HMR will only work if the downgraded module has been bootstrapped and there is at least one Angular component present on the page. The is due to a combination of two facts:NgModuleRef, which is only available after the module has been bootstrapped.ng-versionattribute) present in the DOM in order to retrieve the AngularPlatformRef.Fixes #39935.