Skip to content
This repository has been archived by the owner on May 29, 2019. It is now read-only.

replace use of polygit in routing blog post with glitch #2649

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

replace use of polygit in routing blog post with glitch #2649

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 8 additions & 12 deletions app/blog/routing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,10 +12,8 @@ title: "Encapsulated Routing with Elements"
}
</style>


## Introduction


Polymer is designed with a set of principles in mind: **encapsulation**, **composition**, and **separation of concerns**. When we set out to tackle routing, we knew we wanted to do it in a way that adheres to these principles.

Most client side routers are monolithic black boxes that require a complete and centralized route configuration with perfect knowledge of every routable location in the app. It’s also common for routing to be conflated with other concerns, like loading data or transitioning between views.
Expand Down Expand Up @@ -56,28 +54,27 @@ Note also, how little actual routing there is here. Almost all of the work is be

You can see the core of the idea here, but we’ve jumped ahead a bit. I mean, where does the route in `route="{{route}}"` come from? What’s that `pattern` property doing, and how is it related to `data`?


## &lt;app-route>
## app-route

Let’s walk back a bit and consider the routing problem, one piece at a time, beginning with just a `<app-route>`. What does it do, and how does it work?

`<app-route>` simply matches an input path against a specified pattern. Here's a simple demo of a standalone `<app-route>`. Instead of being hooked up to the page URL, it's hooked up to inputs, so you can change the path and pattern by hand.

<iframe src="/2.0/samples/routing/demo1" style="height: 840px;"></iframe>
<a href="/2.0/samples/routing/demo1" target="_blank">Open demo in new window</a>
<iframe src="https://polymer-2-0-routing-demo-1.glitch.me" style="height: 840px;"></iframe>
<a href="https://glitch.com/edit/#!/polymer-2-0-routing-demo-1" target="_blank">Open demo in new window</a>

`<app-route>` deals with hierarchical, slash separated paths. You give it a pattern, and it tells you when the input matches.

If the pattern contains any variables, like `/:tabName` then the `<app-route>` extracts that portion of the matched URL and exposes it via the `data` object. It also exposes the rest of the path that it didn’t match, but we’ll get to that later.

We're still iterating on the syntax of `pattern`. The most surprising thing to notice is that `/foo` will match `/foo`, `/foo/`, and `/foo/bar/baz`. The pattern `/foo/` with a trailing slash however will only match `/foo/`.

## &lt;app-location>
## app-location

`<app-route>` doesn't know about the URL, it just knows about paths. While you’ll have many `<app-route>` elements in your app, there’s only one URL bar. The URL is global. So we’ve got an element whose single responsibility is connecting the URL to your app. We call this element `<app-location>`, and it exposes a `route` property suitable for binding into a `<app-route>`, like so:

<iframe src="/2.0/samples/routing/demo2" style="height: 745px;"></iframe>
<a href="/2.0/samples/routing/demo2" target="_blank">Open demo in new window</a>
<iframe src="https://polymer-2-0-routing-demo-2.glitch.me" style="height: 840px;"></iframe>
<a href="https://glitch.com/edit/#!/polymer-2-0-routing-demo-2" target="_blank">Open demo in new window</a>

Notice however that if you open the demo in its own window and change the path,
refreshing will give you a 404. That's because the server doesn't know what
Expand All @@ -99,9 +96,8 @@ Ok, so that’s how to get a `<app-route>` hooked up to the URL. However, the be

`<app-route>` exposes a property named `tail` that can be passed in as the the `route` of another `<app-route>`. The `tail` represents the rest of the path that comes after the part that `pattern` matches. When the `tail` route changes, those changes propagate up, so the bidirectional data binding is still working its magic.

<iframe src="/2.0/samples/routing/demo3#/" style="height: 955px;"></iframe>
<a href="/2.0/samples/routing/demo3#/" target="_blank">Open demo in new window</a>

<iframe src="https://polymer-2-0-routing-demo-3.glitch.me" style="height: 955px;"></iframe>
<a href="glitch.com/edit/#!/polymer-2-0-routing-demo-3" target="_blank">Open demo in new window</a>

### Why chain routes?

Expand Down