Expose query param defaults

[kellyselden]

Rendered

[workmanw]

We have this exact use case all over the place. However, it's not just limited to resetController, we often use this.transitionTo or {{link-to}} with query-params throughout the app. When query-params are sticky we have cases where we need to reset back to the default value as part of the transition.

So I suggest that we consider expanding the scope of the RFC to provide a mechanism for other routes / components to determine the default values.

We ended up making constants for these that could be exported from a single global file. Eg:

// app/constants.js
export const ROOM_QP_SORT = 'newest';
export const ROOM_QP_FILTER = 'all';
export const ROOM_QP_SEARCH = '';

// app/controllers/room.js
import { ROOM_QP_SORT, ROOM_QP_FILTER, ROOM_QP_SEARCH } from 'app/constants';

export default Ember.Controller.extend({
  queryParams: ['sort', 'filter', 'search'],

  sort: ROOM_QP_SORT,
  filter: ROOM_QP_FILTER,
  search: ROOM_QP_SEARCH
});

// app/routes/other-route.js
import { ROOM_QP_SORT, ROOM_QP_FILTER, ROOM_QP_SEARCH } from 'app/constants';

export default Ember.Route.extend({
  actions: {
    deleteThingAndGoToList() {
      this.currentModel.destroyRecord().then(() => {
        this.transitionTo('room', { 
          queryParams: {
            sort: ROOM_QP_SORT,
            filter: ROOM_QP_FILTER,
            search: ROOM_QP_SEARCH
          }
        });
      });
    }
  }
});

{{!-- x-routable/other-route.hbs }}
{{#link-to 'room' (query-params 
    sort=(c "ROOM_QP_SORT") 
    filter=(c "ROOM_QP_FILTER") 
    search=(c "ROOM_QP_SEARCH"))}}
  Show All
{{/link-to}}

[trentmwillis]

:+1: I'm onboard with this since I think, if designed properly, the API would be beneficial to asynchronous routing. Since default QP values are serialized in URLs, having some way of exposing them (ideally, separated from the controller) could enable pre-emptive loading ahead of the actual controller.

cc @nathanhammond

[kellyselden]

Since default QP values are serialized in URLs

@trentmwillis You mean "aren't" right?

From your link: "When a controller's query param property is currently set to its default value, this value won't be serialized into the URL"

[trentmwillis]

@kellyselden yeah, what I really meant was more along the lines of "are taken into consideration when serializing URLs".

[nathanhammond]

So today is the day where I finally learn query params. I've made it four years without doing anything more than trivial usage. The goal @trentmwillis mentions here is basically regarding this: https://github.com/dgeb/ember-engines/issues/6#issuecomment-180823082

Right now if you don't expose query param defaults for route targets in a global manner when constructing links in engines land you end up having the defaults appear in URLs (if they're passed). Suboptimal, but not the end of the world.

Because of this RFC and related issues it might make sense to reconsider how we do that, solve the engines problem, and solve this ergonomics problem all at once.

[wagenet]

I believe there is some router-related spiking happening around Polaris. That may eliminate the need for this RFC.

[wagenet]

Thanks for spending the time writing this RFC! Given the significant number of concerns around routing, we’re going to be completely revamping the router as part of Polaris. This RFC won’t directly apply to the new router so we’re going to move this PR to FCP to Close. But don’t worry, your work here was not in vain! We will be keeping track of this RFC and others like it to make sure that the concerns it aims to address will be covered in the new router. Your work here does a significant service to us in this regard!