fix(router): Allow undefined inputs on routerLink #39151
Conversation
Hi @PowerKiKi, thanks for the PR. Just a couple notes:
- Please fix the lint failure by running
yarn ng-dev format files packages/router/src/directives/router_link.ts - Please fix the test failure by running
yarn bazel run //packages/router:router_api.accept - On the surface, this is a really good quality of life change. These types should have been aligned from the very beginning. Unfortunately, we have to consider this a breaking change because this could produce new TS errors (i.e.
Object is possible 'null' or 'undefined') in locations that access these public fields. I'll need to run a global presubmit to see how often this generally occurs in user code. If it causes a lot of breakages, we'll need to think about adding a migration to automatically add the null assertion operator for those. - Because of the note above, please add a
BREAKING CHANGE:footer to your commit message and just quickly highlight what changed and what needs to be done to fix the build failure if devs see this when upgrading to v11 - Lastly, the feature freeze for v11 is next week so depending on the results of the testing, it's quite likely that this is going to miss the cut-off and will need to be pushed back until v12
☹️ Hopefully testing goes smoothly though!🤞
|
initial presubmit (no failures due to this change |
|
global presubmit shows now breakages due to this change. @PowerKiKi This means there's a pretty strong indication that the change here will not break user code in the vast majority of cases. I think it'd still be a good idea to add the breaking change note to the commit message as mentioned above. The message can be pretty minimal, given that this is rare / will never happen. |
PowerKiKi
force-pushed
the
relax-router-link
branch
2 times, most recently
from
179ce30
to
65b4bbd
Compare
|
Thank you for the review, I fixed the code style, commit message and accepted the API changes in the golden files. Hopefully that should be enough for merging. |
This make it coherent with typing of Router.createUrlTree to which those inputs are directly forwarded to. And hence it allow to pass `undefined`, `null` or a value to the routerLink directive. BREAKING CHANGE: in most cases this should not break, but if you were accessing the values of `queryParams`, `fragment` or `queryParamsHandling` you might need to relax the typing to also accept `undefined` and `null`. Signed-off-by: Adrien Crivelli <adrien.crivelli@gmail.com>
Reviewed-for: public-api
Anyone expecting these to be defined is probably in trouble any way, right?
Since the inputs are not required on the directive they could indeed be undefined at runtime.
|
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. |
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
When compiling in the most strict mode, the following will throw error, but it is should be valid:
The error would be similar to:
What is the new behavior?
This make it coherent with typing of Router.createUrlTree to which those inputs are directly forwarded to. And hence it allow to pass
undefined,nullor a value to the routerLink directive.Does this PR introduce a breaking change?
Other information