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
Working with large-scale applications, a fairly common problem when using vue-router is trying to avoid inline string constants for link definitions and programmatic navigation. For example:
Inline constants like these are subject to rot over time, human error when refactoring multiple documents and other similar errors. As an application grows in size, these issues become more prominent.
What does the proposed API look like?
As a solution, our shop often uses a mapping from route name to a route definition. Sample implementation:
This means that changing a route's path requires a single change in the route definition itself and no further refactoring is necessary. Route names are internal and aren't subject to change over time as route paths often can be.
Adding a similar mapping (or exposing existing internals) to vue-router's public API would provide a standardized solution to the given problem and allow all vue-router consumers to reap the benefits.
The text was updated successfully, but these errors were encountered:
I see the point but there is a major flaw and it's that not all routes can be passed like that: A route with a param will have a path (there is no location in a record) value with a colon in it.
This won't be a problem once we have more props on router-link: #2818
As for router.push, it's very easy to add a custom function:
VueRouter.prototype.pushNamed=functionpushNamed(name, ...args){returnthis.push({ name }, ...args)}
What problem does this feature solve?
Working with large-scale applications, a fairly common problem when using vue-router is trying to avoid inline string constants for link definitions and programmatic navigation. For example:
and
Inline constants like these are subject to rot over time, human error when refactoring multiple documents and other similar errors. As an application grows in size, these issues become more prominent.
What does the proposed API look like?
As a solution, our shop often uses a mapping from route name to a route definition. Sample implementation:
Links and navigation can then simply use the resulting mapping:
and
or
This means that changing a route's path requires a single change in the route definition itself and no further refactoring is necessary. Route names are internal and aren't subject to change over time as route paths often can be.
Adding a similar mapping (or exposing existing internals) to vue-router's public API would provide a standardized solution to the given problem and allow all vue-router consumers to reap the benefits.
The text was updated successfully, but these errors were encountered: