Basic/obvious QP limitation

qp-limitation.md

Limitation regarding hrefs on non-route-driven controllers

TL;DR: lack of information about default values on non-route-driven controllers might force us to make href's overly verbose in some cases, or possible make us punt on non-route-driven-controller query params.

Scenario:

Router.map ->
  this.route('about')

// application.hbs
{{link-to 'about' (query-params displayFriends=true)}}
 
// about.hbs
<h1>About</h1>
{{render 'sidebar'}}

// about-controller.js
App.SidebarController = Ember.Controller.extend({
  queryParams: ['displayFriends'],
  displayFriends: true
});

Before about route has been entered, we have no way of knowing that it will {{render}} the sidebar template and controller. The same goes for if we'd used this.render('sidebar') in AboutRoute#renderTemplates instead.

The problem is with the link-to in the application template; we don't serialize default query param values into hrefs, so ideally we'd like that link-to to have an href of /about, as opposed to the needlessly verbose /about?displayFriends=true.

But because we don't know that sidebar will get rendered upon entry into about route, we have no idea which controller the displayFriends=true query param arg refers to, and therefore we have no idea what displayFriends' default value is, so it seems our choices are:

1. Serialize all unresolved query param args into the href, and then remove when those default values can be resolved (e.g. once we've entered about route for the first time and see that sidebar controller is rendered). Note that this shouldn't lead to different behavior b/w clicking a link and opening a link in a new tab; the temporary verbosity is just an aesthetic detail and shouldn't impact behavior.
2. Punt on subcontroller query paramas, tell people that if they want them, they need to move the query params definitions onto the parent route-driven controller and bind to those values.

What do you think we should do?

I vote for #2

#2 seems fine by me for now.