Gathering detailed insights and metrics for @npm-polymer/app-route
Gathering detailed insights and metrics for @npm-polymer/app-route
Gathering detailed insights and metrics for @npm-polymer/app-route
Gathering detailed insights and metrics for @npm-polymer/app-route
npm install @npm-polymer/app-route
Typescript
Module System
Node Version
NPM Version
69.2
Supply Chain
97.9
Quality
73.6
Maintenance
100
Vulnerability
98.7
License
HTML (56.7%)
JavaScript (43.3%)
Built with Next.js • Fully responsive • SEO optimized • Open source ready
Total Downloads
1,657
Last Day
1
Last Week
6
Last Month
9
Last Year
88
147 Stars
294 Commits
66 Forks
34 Watchers
27 Branches
38 Contributors
Updated on Jun 19, 2025
Latest Version
2.0.0
Package Id
@npm-polymer/app-route@2.0.0
Size
23.85 kB
NPM Version
4.1.1
Node Version
6.9.2
Cumulative downloads
Total Downloads
Last Day
0%
1
Compared to previous day
Last Week
500%
6
Compared to previous week
Last Month
350%
9
Compared to previous month
Last Year
-66.2%
88
Compared to previous year
2
app-route
is an element that enables declarative, self-describing routing
for a web app.
n.b. app-route is still in beta. We expect it will need some changes. We're counting on your feedback!
In its typical usage, a app-route
element consumes an object that describes
some state about the current route, via the route
property. It then parses
that state using the pattern
property, and produces two artifacts: some data
related to the route
, and a tail
that contains the rest of the route
that
did not match.
Here is a basic example, when used with app-location
:
1<app-location route="{{route}}"></app-location> 2<app-route 3 route="{{route}}" 4 pattern="/:page" 5 data="{{data}}" 6 tail="{{tail}}"> 7</app-route>
In the above example, the app-location
produces a route
value. Then, the
route.path
property is matched by comparing it to the pattern
property. If
the pattern
property matches route.path
, the app-route
will set or update
its data
property with an object whose properties correspond to the parameters
in pattern
. So, in the above example, if route.path
was '/about'
, the value
of data
would be {"page": "about"}
.
The tail
property represents the remaining part of the route state after the
pattern
has been applied to a matching route
.
Here is another example, where tail
is used:
1<app-location route="{{route}}"></app-location> 2<app-route 3 route="{{route}}" 4 pattern="/:page" 5 data="{{routeData}}" 6 tail="{{subroute}}"> 7</app-route> 8<app-route 9 route="{{subroute}}" 10 pattern="/:id" 11 data="{{subrouteData}}"> 12</app-route>
In the above example, there are two app-route
elements. The first
app-route
consumes a route
. When the route
is matched, the first
app-route
also produces routeData
from its data
, and subroute
from
its tail
. The second app-route
consumes the subroute
, and when it
matches, it produces an object called subrouteData
from its data
.
So, when route.path
is '/about'
, the routeData
object will look like
this: { page: 'about' }
And subrouteData
will be null. However, if route.path
changes to
'/article/123'
, the routeData
object will look like this:
{ page: 'article' }
And the subrouteData
will look like this: { id: '123' }
app-route
is responsive to bi-directional changes to the data
objects
they produce. So, if routeData.page
changed from 'article'
to 'about'
,
the app-route
will update route.path
. This in-turn will update the
app-location
, and cause the global location bar to change its value.
app-location
is an element that provides synchronization between the
browser location bar and the state of an app. When created, app-location
elements will automatically watch the global location for changes. As changes
occur, app-location
produces and updates an object called route
. This
route
object is suitable for passing into a app-route
, and other similar
elements.
An example of the public API of a route object that describes the URL
https://elements.polymer-project.org/elements/app-location
:
1{ 2 prefix: '', 3 path: '/elements/app-location' 4}
Example Usage:
1<app-location route="{{route}}"></app-location> 2<app-route route="{{route}}" pattern="/:page" data="{{data}}"></app-route>
As you can see above, the app-location
element produces a route
and that
property is then bound into the app-route
element. The bindings are two-
directional, so when changes to the route
object occur within app-route
,
they automatically reflect back to the global location.
By default app-location
routes using the pathname portion of the URL. This has
broad browser support but it does require cooperation of the backend server. An
app-location
can be configured to use the hash part of a URL instead using
the use-hash-as-path
attribute, like so:
1<app-location route="{{route}}" use-hash-as-path></app-location>
There is no standard event that is fired when window.location is modified.
app-location
fires a location-changed
event on window
when it updates the
location. It also listens for that same event, and re-reads the URL when it's
fired. This makes it very easy to interop with other routing code.
So for example if you want to navigate to /new_path
imperatively you could
call window.location.pushState
or window.location.replaceState
followed by
firing a location-changed
event on window
. i.e.
1window.history.pushState({}, null, '/new_path'); 2window.dispatchEvent(new CustomEvent('location-changed'));
app-route-converter
provides a means to convert a path and query
parameters into a route object and vice versa. This produced route object
is to be fed into route-consuming elements such as app-route
.
n.b. This element is intended to be a primitive of the routing system and for creating bespoke routing solutions from scratch. To simply include routing in an app, please refer to app-location and app-route.
An example of a route object that describes
https://elements.polymer-project.org/elements/app-route-converter?foo=bar&baz=qux
and should be passed to other app-route
elements:
1{ 2 prefix: '', 3 path: '/elements/app-route-converter', 4 __queryParams: { 5 foo: 'bar', 6 baz: 'qux' 7 } 8}
__queryParams
is private to discourage directly data-binding to it. This is so
that routing elements like app-route
can intermediate changes to the query
params and choose whether to propagate them upstream or not. app-route
for
example will not propagate changes to its queryParams
property if it is not
currently active. A public queryParams object will also be produced in which you
should perform data-binding operations.
Example Usage:
1<iron-location path="{{path}}" query="{{query}}"></iron-location> 2<iron-query-params 3 params-string="{{query}}" 4 params-object="{{queryParams}}"> 5</iron-query-params> 6<app-route-converter 7 path="{{path}}" 8 query-params="{{queryParams}}" 9 route="{{route}}"> 10</app-route-converter> 11<app-route route='{{route}}' pattern='/:page' data='{{data}}'> 12</app-route>
This is a simplified implementation of the app-location
element. Here the
iron-location
produces a path and a query, the iron-query-params
consumes
the query and produces a queryParams object, and the app-route-converter
consumes the path and the query params and converts it into a route which is in
turn is consumed by the app-route
.
Provides bidirectional mapping between path
and queryParams
and a
app-route compatible route
object.
For more information, see the docs for app-route-converter
.
No vulnerabilities found.