Support query parameters

[bpatram]

Add another option to the go function for a query object (for defining query parameters) and pass the query object along to the route action.

It is already built into urlComposer https://github.com/RasCarlito/url-composer#usage

Example:

history.route({
  name: 'my-route',
  path: 'items/:id',
  action(state) {
    console.log(state.params, state.query);
    state.resolve();
  }
});

history.go({ name: 'my-route', params: { id: 1 }, query: { search: 'foo' });
// items/1?search=foo

[bpatram]

@toddbluhm It seems you've added query param support in your fork! Are you planning on submitting a PR?

via https://github.com/toddbluhm/backbone-highway/commit/1dcac5d9ebd371b5dabe199fc25c489b443d4e96

[toddbluhm]

Yeah I did add query param support. I also changed few other things and made the lib more promise compliant. I can see about PR'ing the Query Param stuff though if you like?

[ghost]

Hi @toddbluhm and @bpatram ! Thanks for your interest in this piece of code :)

I have been working on this router for years and it has seen many changes over time. The support for query parameters is a nice add and yes my url-composer lib does support it already.

@toddbluhm if you already have an implementation in your fork i would be more than happy to integrate it via a PR.

Cheers

[ghost]

@toddbluhm I've checked out the modifications in your fork, very nicely done :)

[toddbluhm]

I will go ahead then and parse out my changes and submit some separate PRs for them.

My current list of changes is the following:

• Added support for query params via .go({ query: { paramName: "value" } }) and in the action function function({ params, query: { paramName } }) (currently there is no easy way to declaratively define query params within the route string itself, but that could be changed)
• Removed the resolve/reject from the action callback params and instead just returning an A+ Promise compliant promise from the action function (or nothing at all if async is not needed).
• If your action function throws an error (or rejects a promise), by default the user will be given the 404 page if defined.
• When initializing the lib, you can pass in an optional error function that can handle any errors returned from an action method. This gives the user one central location for which to config how general action errors are handled. When overriding this error method, the user will no longer be redirected 404 by default
• Implemented the ability of an action function to throw a custom Redirect error at anytime to redirect the user to a new location. Redirect error handling occurs before the custom error handler is called on initialize
• General promise/code clean up
• Added/updated debug param that can be passed on initialize to see debug logging when enabled

[ghost]

Awesome :metal: