Feature to bind Router information to component inputs

[atscott]

Adds ability for RouterOutlet to bind Router information to the routed
component's inputs. This commit also exposes some helpers for
implementers of custom outlets to do their own input binding if desired.

Resolves #18967

Edit to add some more color to the "required inputs" / no references / no compiler warning for the inputs:

• Some router data lives entirely in userspace and isn't known until runtime. This includes path parameters and query parameters. Only static data or resolve items can be known at compilation time.
• We considered requiring that bindings be defined in the data or resolve of the Route definitions. However, this would require developers to set the runGuardsAndResolvers option at least to 'pathParamsOrQueryParamsChange'. This was undesirable from a usability and discoverability standpoint.
• Required inputs are checked by the template type checking. Because these components are created dynamically by the RouterOutlet, required inputs cannot be checked by the compiler. This is also true of any other component created dynamically.
• We also considered yet another property on Route to define what bindings to set on the component. Similar to the point above, this was much more verbose than desired.
• There might be some compiler magic we could add to do some level of type checking. However, I feel the Router package should be developed in a way that isn't "special". That is, it's a library that doesn't use any private APIs or integrations that aren't available to any library author. This ensures that the capabilities in the Router can always be replicated in an alternate Routing library driven by the community; I think this is an important property to at least have as a goal for the health of community projects.

[GabrielBB]

If you do "find usages" in your IDE you will see nothing and think it can be removed, right ? This would reduce the confidence while doing code cleanups. I wouldn't go this hidden magical path. Spring Boot uses @QueryParam and @PathParam annotations for REST Controllers, maybe you can so @QueryInput and @PathInput ?

[atscott]

If you do "find usages" in your IDE you will see nothing and think it can be removed, right ? This would reduce the confidence while doing code cleanups. I wouldn't go this hidden magical path. Why not a @RoutedInput annotation ?

This would still result in the same behavior with typescript not finding references. You can just as easily add a comment or import {Input as RoutedInput} from '@angular/core'.

[GabrielBB]

If you do "find usages" in your IDE you will see nothing and think it can be removed, right ? This would reduce the confidence while doing code cleanups. I wouldn't go this hidden magical path. Why not a @RoutedInput annotation ?

This would still result in the same behavior with typescript not finding references. You can just as easily add a comment or import {Input as RoutedInput} from '@angular/core'.

People will miss doing both. Angular, as a framework, should advocate clarity. Because I think clarity brings confidence

[eneajaho]

If you do "find usages" in your IDE you will see nothing and think it can be removed, right ? This would reduce the confidence while doing code cleanups. I wouldn't go this hidden magical path. Why not a @RoutedInput annotation ?

This would still result in the same behavior with typescript not finding references. You can just as easily add a comment or import {Input as RoutedInput} from '@angular/core'.

This makes sense! Thanks.

[alxhub]

Reviewed-for: public-api

[jessicajaniuk]

LGTM

reviewed-for: fw-core, public-api

[github-actions]

Deployed aio for 9a018a4 to: https://ng-dev-previews-fw--pr-angular-angular-49633-dtzgtrva.web.app

Note: As new commits are pushed to this pull request, this link is updated after the preview is rebuilt.

[alxhub]

(same existing failures on TAP as other PRs)

[angular-robot]

This PR was merged into the repository by commit 81c9dd7.

[MunMunMiao]

If you do "find usages" in your IDE you will see nothing and think it can be removed, right ? This would reduce the confidence while doing code cleanups. I wouldn't go this hidden magical path. Why not a @RoutedInput annotation ?

This would still result in the same behavior with typescript not finding references. You can just as easily add a comment or import {Input as RoutedInput} from '@angular/core'.

Previously, 'Input' represented the value passed from the parent component. If the data comes from a Route, decorators such as "RouteParamInput", "RouteQueryInput", and "RouteStaticInput" should be provided to facilitate and strictly distinguish and control the source of the data.

When a sub component needs to pass data from the parent component and also requires query input, it can confuse the developer because they do not know whether the data comes from the parent component or the route.

I know I can set an alias, but it will increase user confusion and increase usage costs.

I think adding new decorators is a better choice.

If the user manually enters a query param on the route, it will cause the value of the Input to be overwritten. At this point, this value is not secure.

like:

I want

@Input() id: Observable<number>

But route is: /user?id=123

@Input() id: // this value is ???

If use RouteQueryInput or RouteParamInput I Know this value is string or undefined

@RouteQueryInput() id?: string
@RouteParamInput() type?: string
@RouteStaticInput() someRouteStaticValue?: unkonw

@atscott

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