Allow route viewport to be passed by the caller

[jwahyoung]

I'm submitting a feature request

• Library Version:
  1.1.0

Please tell us about your environment:

• Operating System:
  Windows 7

• Node Version:
  4.1.2

• NPM Version:
  3.5.1

• JSPM OR Webpack AND Version
  JSPM 0.16.15

• Browser:
  all

• Language:
  all

Current behavior:

Currently, viewports must be defined as part of the route config for a given router. Different routes can specify different viewports (or omit viewport configuration), but a viewport cannot be chosen dynamically by the caller making the navigation request.

Expected/desired behavior:

The desired behavior is to be able to specify a viewport in the route-href binding, like so:

<a route-href="route: documents; params.bind: { id: document.id }; viewport: 'my-viewport'">Link</a>

Alternate methods could possibly look like this:

<a route-href="route: documents; params.bind: { id: document.id };" target.bind="my-viewport">Link</a>

<a route-href="route: documents; params.bind: { id: document.id };" viewport.bind="my-viewport">Link</a>

• What is the expected behavior?
  Routes can be defined at a high-level to match modules to routes, while the caller can then specify where the module should be loaded.

• What is the motivation / use case for changing the behavior?
  The use case is a viewport in a main application that can be reopened in a new window. For instance, the "compose email" window in Gmail could be implemented as a separate viewport in a larger app, with a link to a generic "compose" module. Clicking a "New Email" link within the larger application would open the "compose" module within the target viewport, but a user could open the same module in a new window by opening a browser pointed directly to the route.

[jwahyoung]

A few thoughts.

• route-href is in the templating-router module, but this functionality would require changes to the underlying router structure.
• Routing should probably be deterministic. Letting the caller specify the viewport may be problematic in some ways. (I believe determinism is already an issue if we allow routes to omit viewports in the configuration.) However, I believe that specifying a viewport through a separate attribute (such as "target") could allow us to make the route itself deterministic in terms of content and not target - similar to the way that hyperlinks work now.
• I think that this method could coexist with the current static viewport method. I would imagine that viewport instructions from the caller would override viewport instructions in the route configuration.
• This may only work with routes that define a module for one viewport. Calling a route from a link with a target attribute that doesn't define viewport arguments for all necessary viewports would result in undefined behavior.
• Not sure how this will affect history. I'm not sure, but I think for this to work correctly with history, we would have to save the target with the history entry?

The main issue here is deep linking using the href attribute.

This enhancement may depend upon support for optional viewports. At the moment, to accomplish this, we may have to dynamically generate a one-time usage route that is populated with the target route, target viewport, and all of the current modules for all of the currently-rendered viewports.

[Alexander-Taran]

separation of concerns
and deep linking

alternate behavior (pop up window for new message w/o folder structure) can be defined with just another route using the same module

IMO can be closed..
unless further discussion magically erupts after this (-: