Symbols for Relative and Absolute URLs

[timkindberg]

@ksperling said here: #174 (comment):

I haven't really seen anybody use absolute URLs, so making that the default seems counter intuitive... ...We could even encourage using both "^/abs" and "&/rel"

I like your logic here, but I'm wondering if having two symbols ('^' and '&') just adds back in complexity.Now people would have to remember which symbol does what. I think by only using a symbol when appending, we actually make things more clear. Since appending a url to a parent is more peculiar than just providing a vanilla url, I think the appending should use the symbol to flag its "specialness". Who cares if appending is more popular, it only means that using the '&' symbol will be more prevalent than not using it, but it helps make things more clear.

[adambabik]

I agree with that.

I believe that many users of ui-router are familiar with routing in Rails, express (node.js web framework) or other and you almost always specify absolute routes there. Such a pattern is widely spread in many environments and here it works totally different.

[ksperling]

Fair enough. Let's do this with the next release -- I've got another breaking change planned to replace the to, toParams, from, fromParams parameters in onEnter / onExit hooks with a single transition object (which then contains those and other things as properties).

It will be less annoying if we bundle all the breaking changes into on release rather than staggering them.

[timkindberg]

Awesome

[ksperling]

What syntax do other frameworks use, is '&' common? I've seen it in less as Tim mentioned... What about e.g. rails?

[adambabik]

In rails there is no such an option as far as I know. You always need to specify route as an absolute path or use some declarative way.

I think that the ampersand is the best choice and it actually means something in this context.

[timkindberg]

Comparing to Emberjs is our best one-to-one comparison. They do not use '&' but they also do nested routes much differently. I still think they have a leg up on us from a ease of use perspective.

[laurelnaiad]

Ember uses naming convention shortcuts to a fault, IMO. It also makes a lot of assumptions that feel like you're supposed to use rails with it. Talk about confusing.

[laurelnaiad]

Sorry, my mouse and keyboard have minds of their own, literally ghost in the machine stuff... anyway, I wasn't quite finished. railing on ember.

One thing that always bothered me about ember's router is that it assumes and pretty much demands, IIRC, that your urls be hierarchically tied to your views and controllers... I'm so much happier that state URLs don't demand any strict hierarchy.

One thing that occurs to me: usage of & looks sort of like @ for views... not that they're related nor do the same thing.

I can't recall what I was initially in favor of, but I think absolute URLs should be the norm, whether that means that the documentation promotes them by using them in most examples, or whether there's a syntactical push in that direction.

[adambabik]

It seems to me that Ember's concept of nested routes is similar to the current implementation of ui-router, i.e. nested definitions create routes by appending them to the parent route implicitly. This opinion is based on example from Ember's docs. It may look a little bit clearer as the code structure follows routes' inheritance. On the other hand, as @stu-salsbury mentioned, Ember makes a lot of assumptions and it works totally different. I don't think it's a perfect example to relate to.

Personally, I'm not convinced that the current implementation of nested routes is wrong or misleading and introduction of a new symbol won't change much. Maybe improving the docs would suffice...

[laurelnaiad]

Just to clear I oove thqt the states are hierarchical yet the urls are in our control. Best of both worlds!

[ksperling]

Maybe we should start by just adding the '&' prefix for relative, and discourage use of un-prefixed URLs. Both ^ and & should be pretty clear to anybody reading state definitions (^ probably more so to anybody familiar with regexps)

[timkindberg]

I'm fine with that.

[timkindberg]

closing, not a good idea anymore