fix(router): lazy routing tries loading destroyed module

[kewde]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Documentation content changes
[ ] angular.io application / infrastructure changes
[ ] Other... Please describe:

What is the current behavior?

The router can lazy load modules. It doesn't check whether that module has been destroyed or not.

Issue Number: #24962

What is the new behavior?

If it has been destroyed, it will create a new instance of it.

Does this PR introduce a breaking change?

[ ] Yes
[x] No

Other information

I'm a complete noob to angular and I need this change 😘

[alxhub]

LGTM

Please squash down to 2 commits, with detailed and scoped commit messages for both. The first should add destroyed() in core, the second should make use of the feature in `apply_redirects.ts.

[JoostK]

This affects public API surface, so you will need to update the golden files of the public API. See CircleCI logging:

CircleCI summary

FAIL: //tools/public_api_guard:core_core_api (see /home/circleci/.cache/bazel/_bazel_circleci/9ce5c2144ecf75d11717c0aa41e45a8d/execroot/angular/bazel-out/k8-fastbuild/testlogs/tools/public_api_guard/core_core_api/test.log)

INFO: From Testing //tools/public_api_guard:core_core_api:

==================== Test output for //tools/public_api_guard:core_core_api:
--- tools/public_api_guard/core/core.d.ts	Golden file
+++ tools/public_api_guard/core/core.d.ts	Generated API
@@ -530,8 +530,9 @@
 }
 
 export declare abstract class NgModuleRef<T> {
     abstract readonly componentFactoryResolver: ComponentFactoryResolver;
+    abstract readonly destroyed: boolean;
     abstract readonly injector: Injector;
     abstract readonly instance: T;
     abstract destroy(): void;
     abstract onDestroy(callback: () => void): void;


Accept the new golden file:
  bazel run //tools/public_api_guard:core_core_api.accept

[kewde]

@JoostK Thanks, fixed.

[kewde]

Travis-CI is having issues unrelated to this PR:

Error: ENOSPC: no space left on device, watch '/home/travis/build/angular/angular/aio/content/examples/upgrade-phonecat-2-hybrid'

[jasonaden]

Update on this issue: Overall this looks great. However, the change to the public API is a pretty big breaking change. It means any code implementing NgModuleRef needs to be updated. This is fine for the Angular repo of course, but it will break user code.

I'm looking at how we can get this rolled out so we can move forward and merge this PR. Thanks for the patience.

[kewde]

@jasonaden

Let me know if there is anything else I can do.

I don't like breaking user code either, if the general consensus is that this is not to be merged, then I would like to know an alternative proposals to fix this bug.

[jasonaden]

Discussed this one and it looks like we might be able to make this change by updating a couple internal Google users who are implementing this API. So I think we can move forward on this one. Doing internal testing here:

Presubmit

[kewde]

@jasonaden Is there any plan moving forward? We have a feature that depends on this fix

[kewde]

@jasonaden @alxhub is there anything left for me to do here? Please let me know, I would like this bug fixed.

[kewde]

I've added a test commit as it is the only way to retrigger CI, I will force delete it and force push.
The Travis PR only failed because ENOSPC (no space left).

[kewde]

Rebased the PR against the current master just to be a 100% sure.

[kewde]

Oh god, review hell.

I suppose it's not worth breaking the public API over this, so I think #28405 will also do the trick.

[petebacondarwin]

Closing in favour of #28405

[angular-automatic-lock-bot]

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