feat: accept UrlTree in navigate and initialRoute

[gabrielmethot]

Hello,

This pull request adds new signatures to navigate and initialRoute to allow passing instances of UrlTree. This makes query params easier to configure because Angular handles the serialization. It also lets us pass a route fragment, which wasn't supported with string paths.

String paths work the same as before, but they behave differently from a UrlTree because they go through the library's own parser, which doesn't decode values or handle fragments. This can be surprising, so I documented it in the JSDoc.

It might be worth considering using Angular's parser as the default, because that's probably what most developers expect. The custom query params parser could then be deprecated. Since this would be a breaking change, it might fit better in a future major version. I'd love to hear your thoughts about this.

Thanks for taking the time to review this, and for your work on the library!

[timdeschryver]

Thanks for addressing this, @gabrielmethot.

Do you think this should also be added to the zoneless API (public_api.ts)?

I’m asking because I’d like to keep it as minimal as possible. Since this is essentially just router.navigate([path]), I’m not sure it’s needed there. AFAIK, most component tests aren’t concerned with routing logic itself.

You can ignore the failed build, I will look into it.

[gabrielmethot]

Thanks for addressing this, @gabrielmethot.

Do you think this should also be added to the zoneless API (public_api.ts)?

I’m asking because I’d like to keep it as minimal as possible. Since this is essentially just router.navigate([path]), I’m not sure it’s needed there. AFAIK, most component tests aren’t concerned with routing logic itself.

You can ignore the failed build, I will look into it.

Thanks for the feedback! I wasn't aware of the ongoing work to define a smaller API and lean more on Angular's own testing utilities.

RouterTestingHarness only offers navigateByUrl, which only accepts a string URL and not a UrlTree, so there's a gap. That said, I'm not sure it's ATL's responsibility to fill it. I'll open an issue on the Angular repo to see if the team is open to the idea, and if so, I'll submit a PR there.

As for this PR, I would understand not wanting to grow the API surface of something that's headed for deprecation, so I'll leave it up to you whether to merge it. If you do, I agree it doesn't need to go into the zoneless API.