Router - passing an object with route params into handler

[ntgn81]

Currently, matched parameters are passed into the action as an array

routes: {
  "folder/:name-:mode": "openFolder"
},

openFolder: function(name, mode, queryString) {
  // do stuff
}

I would like the actions to be given an object with name, params, queryString instead, resembling express routing solution.

routes: {
  "folder/:name-:mode": "openFolder"
},

openFolder: function(routeData) {
  /* routeData is now
  {
    name: "openFolder",
    params: {
      name: "valueOfName",
      mode: "valueOfMode"
    },
    queryString: "query=string&a=b"
  }
  */
}

It could be an option that can be enabled on BB.Router.
Is it a good idea to have this functionality in base BB.Router? Or it can be an external library?

I have tried it out, and it seems to be working well, with a new set of tests cloned from current router test to make sure nothing breaks.

ntgn81@7b2c8b3

Thanks!

[akre54]

We could do that. Might be a nice addition for V2. Your implementation is a little heavyweight though. Any way we could slim it down?

[ntgn81]

Thanks, @akre54!

Can you please give me some pointers as to where the heavy code might be?

I think it could be cleaned up a bit if it was to replace the current logic. But this was done with backward compatibility in mind, so I just added the stuff on top of the existing logic.

[akre54]

I would guess (without looking too much into it) that it should be possible to combine some of the logic with what we already have. I'll respond on the diff.

[megawac]

Related v2 router changes #3660. /cc @jmeas

[jamesplease]

This is a great idea, I think!

For folks looking for this feature now, BaseRouter returns a hash for named params and query params, though I can't recall if it works with splats.

As is evident by the commit referenced in the OP, the DSL implementation in Backbone is the biggest hindrance to this feature. I wasn't planning on making any changes to the DSL implementation in #3660 to keep concerns separate, but I'm hugely in favor of updating it. I had a vague plan to do a subsequent PR focused solely on the DSL, but I'm not sure if/when I'll get a chance to do that anytime soon.

[ntgn81]

Sorry, @jmeas! I should have done better research. What I did is pretty much the same as what you already implemented in BaseRouter

Converting queryString to an object is also a great addition I think. Possibly have both queryString and objectified query in routeData, for the rare case someone needs to use raw queryString value?

[jamesplease]

Possibly have both queryString and objectified query in routeData, for the rare case someone needs to use raw queryString value?

That seems like a good idea to me. When it comes to the single point of entry for a router, I think giving the user as much information as possible is best. If you open a PR on BaseRouter I'll merge it in and cut a release : P

Query parameters are super interesting when it comes to a router. The two leading client-side router philosophies, UI-Router and Ember's router, take fairly different approaches. UI-router "blends" the query parameter with the rest of the route, in a sense, while Ember keeps them separate. It's also on my to-do list to evaluate the pros and cons of each approach, but I haven't reached any conclusions about which I prefer. The DSL that I've been working on for a client side router just ignores query params at the moment, for this reason :)

[jridgewell]

Moving to #3815.