You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which scope/s are relevant/related to the feature request?
router
Information
Background
Angular has recently exposed the router parsing/serialization API (ref: angular/angular#47307).
This finally makes it possible to provide custom router parser/serializer implementations and therefore to navigate with any kind of data, not just strings — as long as you define how it is serialized to and revived from the URL.
In my Angular projects, I use https://github.com/kruschid/typesafe-routes to build and parse URLs.
It provides strong typing for paths and params, and it works with Angular, but its main focus is enforcing type-safe URLs, not handling custom serialization strategies.
Context with Analog / file-based routing
In Analog (and similarly in Expo), routes — and therefore URLs — are guaranteed to be valid because they are derived from the filesystem.
This makes it virtually impossible to navigate to an invalid path, which is great.
However, in real-world applications, I often need to pass something more complex than simple strings or primitive params.
A common example is passing complex filters, structured objects, or other non-string data.
With Angular exposing the parser/serializer logic, it is now technically possible to:
generate a string URL,
but attach arbitrary typed data to it,
and revive that data on navigation using a custom serializer/parser.
What is missing
What I would really need is a system that combines:
File-based route generation (Analog-style)
Strong typing for paths and params (like typesafe-routes)
Ability to declare per-route custom serializers/parsers
for any kind of complex data
Automatic code generation of a strongly typed route builder
Ideally, each route (derived from the file structure) could define its metadata, including custom serialization logic, for example:
typesafe-routes works beautifully, but it remains an entirely separate URL builder/parser/serializer, disconnected from Angular’s router.
Angular routes cannot currently be used as a type-safe source of truth (without a preprocessing step), because route definitions rely on decorators, which TypeScript cannot interpret statically.
Bringing all of these together — file-based routes, typed builders derived from required component inputs, custom serializers/parsers, and Angular’s navigation — would allow a unified, strongly-typed link builder directly aligned with the filesystem hierarchy and the actual runtime router behavior.
Describe any alternatives/workarounds you're currently using
Right now, I’m working around the problem by implementing my own navigator service, which acts as a typed link builder on top of Angular’s router.
The URL itself is enforced and constructed using typesafe-routes.
My navigator exposes methods for each page in my application. These methods accept the typed objects I want to pass (filters, complex params, etc.).
The result is a link object with a small API:
link.toUrl() → returns the final URL string
link.go() → performs the navigation
link.parent() → returns the parent link in the route hierarchy
…and so on.
However, once navigation happens, I still need to parse the data back on the target page.
And here’s where Angular alone becomes limiting:
In Angular, the same component can be used by multiple routes, which makes it impossible to rely on static typing unless each route explicitly defines its own parameter contract.
I can use withComponentInputBinding with a transform function, but typing this consistently is extremely painful.
Or I can read the full URL and let typesafe-routes perform the parsing/validation on my behalf.
In all cases, without route–page–parameter coupling, there is no way to achieve fully compile-time-safe navigation.
This is exactly why having a generated, typed link builder based on the file hierarchy + per-route serializers would be a major win.
I would be willing to submit a PR to fix this issue
This discussion was converted from issue #1952 on November 20, 2025 04:12.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Which scope/s are relevant/related to the feature request?
router
Information
Background
Angular has recently exposed the router parsing/serialization API (ref: angular/angular#47307).
This finally makes it possible to provide custom router parser/serializer implementations and therefore to navigate with any kind of data, not just strings — as long as you define how it is serialized to and revived from the URL.
In my Angular projects, I use https://github.com/kruschid/typesafe-routes to build and parse URLs.
It provides strong typing for paths and params, and it works with Angular, but its main focus is enforcing type-safe URLs, not handling custom serialization strategies.
Context with Analog / file-based routing
In Analog (and similarly in Expo), routes — and therefore URLs — are guaranteed to be valid because they are derived from the filesystem.
This makes it virtually impossible to navigate to an invalid path, which is great.
However, in real-world applications, I often need to pass something more complex than simple strings or primitive params.
A common example is passing complex filters, structured objects, or other non-string data.
With Angular exposing the parser/serializer logic, it is now technically possible to:
What is missing
What I would really need is a system that combines:
File-based route generation (Analog-style)
Strong typing for paths and params (like typesafe-routes)
Ability to declare per-route custom serializers/parsers
Automatic code generation of a strongly typed route builder
Ideally, each route (derived from the file structure) could define its metadata, including custom serialization logic, for example:
From this, the system would generate a fully typed builder:
The URL would still be a string on the wire, but the builder and parser would ensure that:
Additional considerations
A few things are still unclear or difficult today:
[withComponentInputBinding](https://angular.dev/api/router/withComponentInputBinding)feature, where we are supposed to supply a transform function. But typing this end-to-end — from the link builder, through the URL, down to component inputs — is extremely hard in practice.typesafe-routesworks beautifully, but it remains an entirely separate URL builder/parser/serializer, disconnected from Angular’s router.Describe any alternatives/workarounds you're currently using
Right now, I’m working around the problem by implementing my own
navigatorservice, which acts as a typed link builder on top of Angular’s router.The URL itself is enforced and constructed using typesafe-routes.
My
navigatorexposes methods for each page in my application. These methods accept the typed objects I want to pass (filters, complex params, etc.).The result is a link object with a small API:
link.toUrl()→ returns the final URL stringlink.go()→ performs the navigationlink.parent()→ returns the parent link in the route hierarchy…and so on.
However, once navigation happens, I still need to parse the data back on the target page.
And here’s where Angular alone becomes limiting:
withComponentInputBindingwith a transform function, but typing this consistently is extremely painful.In all cases, without route–page–parameter coupling, there is no way to achieve fully compile-time-safe navigation.
This is exactly why having a generated, typed link builder based on the file hierarchy + per-route serializers would be a major win.
I would be willing to submit a PR to fix this issue
Beta Was this translation helpful? Give feedback.
All reactions