RFC: Default URL generation for optional parameters

[christopherthielen]

Squashing URLs

With the addition of optional URL parameters, UI-Router can now generate friendlier URLs. For example, with the following states created with default parameter values:

.state('user', {
  url: '/user/:username',
  params: { username: function(SessionService) { return SessionService.username; }
}).state('user.photos', {
  url: '/gallery/:galleryid',
  params: { galleryid: 0 }
}).state('user.photos.photo', {
  url: "/:photoid"
});

This RFC hopes to determine the default url squashing behavior. When the user navigates to user ($state.go('user');), the full URL with parameter included would be #/user/christopherthielen. However, we can squash this URL down to: #/user/ or even #/user by omitting the parameter's default value.

When the user navigates to user.photos, the full URL with parameters would be #/user/christopherthielen/gallery/0, but we can squash this down to: #/user//gallery/ or even #/user/gallery/ which looks even nicer.

Of course, we can transition to the same user.photos state with non-default parameters too. Then, we cannot omit the parameter value; the URL must reflect the non-default parameters. For example, $state.go('user.photos', { username: 'someotheruser' }) will generate a full URL #/users/someotheruser/gallery/0 or a squashed version: #/users/someotheruser/gallery/.

Squashing slashes

Omitting the slashes from the URL can potentially generate ambiguous URLs

In the above example, if we navigate as follows: $state.go('user.photos.photo', { username: 'christopherthielen', galleryid: 0, photoid: 21872 }), the full URL (no squashing) would be: #/user/christopherthielen/gallery/0/21872, the squashed URL would be: /#user//gallery//21872, and the URL with slashes squashed would be: #/user/gallery/21872.

Note that #/user/gallery/21872 (slashes squashed) is ambiguous. Is 21872 the galleryid or is it the photoid? It was intended to be photoid 21872, but if the user hit reload in their browser, they would instead return to galleryid 21872.

Here is another example from #1487. It sets up a state with 3 parameters, each with defaults.

.state('test', { 
  url: '/:fooid/:barid/:bazid',
  params: { fooid: 123, barid: 456, bazid: 789 }
}

If we do $state.go('test', { bazid: 10000 }) and squash slashes, then the url generated is #/10000. After a reload, that url would load state test with param values of { fooid: 10000, barid: 456, bazid: 789 }.
#3 Parameter Squashing options

All three parameter squash options ("nosquash", "value", "slash") will likely be available for use in for 0.2.12. The code to process them is in a branch, pending merging to master. You can view the branch here: https://github.com/christopherthielen/ui-router/compare/angular-ui:master...master ...

You will be able to set UI-Router's default squash policy using $urlMatcherFactoryProvider.defaultSquashPolicy(). You will be also able to set the squash policy on individual parameters .state({ name: 'foo', url: '/foo/:fooid', params: { fooid: { value: 12345, squash: "nosquash" } } });

Default behavior? - Finally, getting to the point!

What behavior would you expect from UI-Router "Out of the box"

.state('user', {
  url: '/user/:username',
  params: { username: function(SessionService) { return SessionService.username; }
}).state('user.photos', {
  url: '/gallery/:galleryid',
  params: { galleryid: 0 }
}).state('user.photos.photo', {
  url: "/:photoid"
});

With the preceding states, when an optional parameter's default values is used, should the out-of-the-box policy be to:

• (A) squash both the default parameter value and one slash. The developer is responsible to organize state urls and parameters such that ambiguous URLs cannot happen. URLs are prettier, such as #/user/gallery/, but the developer may not notice that they generate ambiguous URLs such as #/user/gallery/21872.
• (B) squash default parameter values only. The default behavior generates unambiguous URLs (users can refresh and return to the same state/params). The developer must explicitly choose to squash the slashes around a default parameter value. URLs are less pretty, such as #/user//gallery//21872 but will generally map back to the state and parameters that they're generated for.
• (C) Do no squash default parameter values from the URL by default. The URL is updated with the default values such as #/user/christopherthielen/gallery/0/21872. This is the most verbose.

Which option for UI-Router would surprise you the least?

[nateabele]

cc: @niemyjski @RodolpheGohard @SimpleAsCouldBe @stereokai @marcghorayeb @kevinrenskers @jshado1 @amcdnl @eranimo @wlingke @yohairosen @Siyfion @bobmash @crisbeto.

[NevilleS]

Option B seems better for me, since I'm worried that pretty much all nested states where the parent had a default parameter defined would be, by definition, ambiguous.

For example, is the URL #/user/gallery referring to #/user/:userid' withuserId: 'gallery'`? I'm not sure how, as a developer, I can make removing the slashes non-ambiguous.

[christopherthielen]

@NevilleS that can be worked around in some cases using a regexp on the default parameter, which ensures the next segment doesn't match against the parameter. For instance, if :userid is always an integer value, then you could do "/user/{userid:[\\d+]}".

[NevilleS]

I'd say those are exceptions rather than the rule, so the default behaviour would be to assume that squashing the slashes is unsafe, no? Otherwise this breaks the refresh behaviour for the majority of existing apps, I'd think...

[cesarandreu]

I'd say squashing is a bad idea. What's the point?

It seems like it'd add complexity.
Expected behavior for me would be for the router to not do any of this.

[NevilleS]

It's nice that #/user/ would by default go to #/user/NevilleS, so you could generically say "Go to #/user/ to see your profile", for example.

[NevilleS]

By the way, I can't cite the RFC or anything, but I'm pretty sure most pages treat multiple slashes as irrelevant. In other words, https://github.com/angular-ui/ui-router/issues/1501 is the same as https://github.com/angular-ui/ui-router//////issues/1501, but in your proposal the latter would imply several squashed child states...

[wesleycho]

I think I like A over B since urls would look prettier - I tend to prefer prettier urls, and anything to help towards that end would be great.

[christopherthielen]

@wesleycho of course, you can still get squashed parameters with either scenario. With B you would have to add squash: true to the param.

[christopherthielen]

I added

(C) Do no squash default parameter values from the URL by default. The URL is updated with the default values such as #/user/christopherthielen/gallery/0/21872. This is the most verbose.

[ragefuljoe]

I think from a use standpoint not squashing by default will lead to less confusions. While useful, this seems like it should be an opt-in feature.

[wbk]

The potential ambiguity seems scary and bothersome. Couldn't the situation be detected and avoided? Consider this option D.

$state.go('user') understands that it needs to visit a state named user. If it creates a route which does not unambiguously resolve to the user state, certainly it could take some sort of preemptive action.

What if a special character, i.e. - or _, were introduced which would imply "I'm the default value!", but were only injected in cases of ambiguity, and were squashed entirely when targeting a route with the fewest sections among routes which could potentially match.

E.g. assume with two routes,/a/:b and /a/:b/:c, each with default values. /a/:b/c would require the near-fully-qualified /a/-/-, because it contains the most sections. /a/:b, on the other hand, could simply be /a. The only potential ambiguity would be if we were to resolve something like /a/-. I'd argue this should resolve to /a/:b, because it contains the fewest sections of any possible matching routes.

#/user/myuser/gallery/0/21872/, when targetting a photo, would become #/user/gallery/-/21872/.
#/user/myuser/gallery would become #/user/-/gallery.
#/user/myuser would be fully squashed to #/user.

I think this accomplishes the goal of creating pretty routes while remaining easy to understand and predict. It would allows multiple routes to resolve to the same state, with the same parameters, but I can't think of a simple case where you would be routed somewhere unexpected.

Is there a chance anyone is the wild is using a '-' as a path segment for anything meaningful?

[NevilleS]

Is there a chance anyone is the wild is using a '-' as a path segment for anything meaningful?

Yes 😄. URIs aren't a new thing (original RFC published in '98) and they mean a lot. For example, you can create a folder via mkdir ~/- and reference it from your browser like file:///Users/neville/-/. The RFC is pretty clear about what constitutes a path, query param, etc., and the character set is only partially restricted (e.g. ? is not permitted in a path since it denote the start of query params).

Given that handing the URL is part of what browsers do, personally I wouldn't want ui router to do anything fancy about squashing parameters, substituting special characters, etc., since it's unclear how the behaviour would vary between Chrome, FF, IE, etc., and I'm inclined to be defensive when it comes to this kind of thing (here be dragons). But that doesn't mean I'm going to try to stop you cowboys from redefining what a URL means, by all means go for it!

... just not in the defaults 😄