docs(router): Deprecate canLoad guards in favor of canMatch #48180
+36
−45
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As mentioned in angular#46021, `canMatch` guards can replace `canLoad`. There are slight differences between the two but the purpose of preventing user access to feature modules is still achievable. There are several reasons keeping `CanLoad` around is detrimental to the API surface: * Lazy loading should not be an architectural feature of an application. It's an optimization you do for code size. That is, there should not be an architectural feature in the router to directly specifically control whether to lazy load something or not based on conditions such as authentication. This is a slightly nuanced difference between the proposed `canMatch` guard: this guard would control whether you can use the route at all and as a side-effect, whether we download the code. `CanLoad` only specified whether the code should be downloaded so `canMatch` is more powerful and more appropriate. * The naming of `CanLoad` will be potentially misunderstood for the `loadComponent` feature. Because it applies to `loadChildren`, it feels reasonable to think that it will also apply to `loadComponent`. This isn’t the case: since we don't need to load the component until right before activation, we defer the loading until all guards/resolvers have run. * Unnecessary API surface bloat where two features (CanMatch and CanLoad) do essentially the same thing. This affects code size for supporting two nearly identical features as well as the learning and teaching journey for them both. DEPRECATED: CanLoad guards in the Router are deprecated. Use CanMatch instead.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
As mentioned in #46021,
canMatchguards can replacecanLoad. There are slight differences between the two but the purpose of preventing user access to feature modules is still achievable. There are several reasons keepingCanLoadaround is detrimental to the API surface:Lazy loading should not be an architectural feature of an application. It's an optimization you do for code size. That is, there should not be an architectural feature in the router to directly specifically control whether to lazy load something or not based on conditions such as authentication. This is a slightly nuanced difference between the proposed
canMatchguard: this guard would control whether you can use the route at all and as a side-effect, whether we download the code.CanLoadonly specified whether the code should be downloaded socanMatchis more powerful and more appropriate.The naming of
CanLoadwill be potentially misunderstood for theloadComponentfeature. Because it applies toloadChildren, it feels reasonable to think that it will also apply toloadComponent. This isn’t the case: since we don't need to load the component until right before activation, we defer the loading until all guards/resolvers have run.Unnecessary API surface bloat where two features (CanMatch and CanLoad) do essentially the same thing. This affects code size for supporting two nearly identical features as well as the learning and teaching journey for them both.