Providing default values for optional route parameters?

[jaxley]

It didn't seem like there was a way to provide default values for optional route parameters. Were there thoughts on providing this capability at some point? Seems like if a route is matched it is often useful to provide some defaults so that you can simplify the callback code by avoiding lots of null checking and default setting and you can universally provide those values rather than repeating that logic in multiple callbacks listening to the same route.

[jaxley]

Looking closer, it appears as if the way to do this would be to write a rules.normalize_ function that would ensure default values are returned to the signals.

It would be nice if addRoute() was able to configure a route entirely from a single object rather than relying on later adding data to a created route via changing the Route object. e.g. if addRoute() checked the type of object passed in, it could consider an Object to be a configuration object that it could pull relevant values from. e.g. ````

var setDefaultValues = function(request, vals) {
    return {
      type: vals.type || "foo",
      view: vals.view || "bar",
      id: vals.id || ""
    };
};
    myrouter.addRoute({
      id:'foo', 
      pattern:'/{foo}/{bar}', 
      rules: { normalize_:setDefaultValues} 
    });````

Only downside is that the default normalizeFn is bypassed. Would be nice to be able to pipe them for chaining perhaps.  Guess you could call them directly as they are statics.

[millermedeiros]

that could be an useful feature and shouldn't be hard to implement, need to basically update the Route#_getParamsObject to check if value is undefined (and parameter is optional) and use the default value instead.

I think this is a change we can do before v2.0 but I probably won't have time to work on it for the next couple weeks. PR is highly appreciated.

[jaxley]

Cool! I implemented a workaround in a POC similar to my OP above to provide this. I'll note this issue so who picks up the baton on the project I'm on can contribute that code.

How about the declarative addRoute() API? Seems like most of the code requires so much synchronous invocations and diddling with the Route object after it's created that addRoute() doesn't provide too much value on its own except for registering the route with the internal array. If the config were more declarative, it would be easier to consume within wirejs for bootstrapping, for example. Since you know ahead of calling addRoute() what you want the values to be, you should not have to wait until after that is done to configure the other settings IMO and have the factory method do it all for you in a single shot.