Difference between $routeProvider and $urlRouterProvider

[angular-ui]

Difference between $routeProvider and $urlRouterProvider

I speak malayalam, my neighbouring state speaks tamil, my country speaks more than 1600 languages...... dare not to learn any one of those... or you will end up hearing words those are bolder than that you have ever heard in your lifetime...
This 26 letter language of yours, is not our mother tongue, yet we have mastered it so well.. so respect that you MF

[nateabele]

LOL

[ksperling]

$routeProvider is a shim the implements the current AngularJS $route / $routeProvider API on top of $stateProvider, to make it easier for people to transition applications to $stateProvider step by step -- it simply fudges the route definition into a state definition by making up a name, and some other small things.

Current AngularJS $routeProvider is also monolithic, it that it handles everything internally that in our code is split up into multiple services:

• watching $location and triggering something when it matches a pattern / rule -> $urlRouterProvider
• defining the syntax for url patterns and parameter placeholders -> $urlMatcherFactory
• loading templates via $http / $templateCaache -> $templateFactory
• managing and exposing the current route -> $stateProvider
• asynchronous resolving of view dependencies and making the result available to the view directive -> currently $stateProvider, maybe factor out into separate $view service?

So $urlRouterProvider simply has the responsibility of watching $location, and when it changes running through a list of rules one by one until one matches. How exactly "matching" is defined and what happens when a rule matches is up to that rule; at the lowest level its just a function that returns true if it has handled the URL. However there is support built on top of this for rules that are RegExps, as well as path patterns with placeholders (as used by state.url) that are compiled into rules via $urlMatcherFactory. $urlRouterProvider also supports redirects.

As it stands $urlRouterProvider should already be faster than the corresponding code in $routeProvider, because it doesn't re-parse url patterns on every location change, but instead hangs on to the compiled UrlMatcher objects.

(I've got a TODO in the code to improve this further by taking static prefixes into account to be able to skip blocks of rules -- for example if there is a sequence of 8 URL patterns that all start with "/contacts/", but the current $location starts with "/users/", there's clearly no point in attempting to match those 8 rules. Static prefixes also allow rules to be re-ordered for further optimizations. I'm not sure these optimizations are actually necessary yet, but a moderately complex application can easily have hundreds of rules that need to be processed every time $location changes.)

[rjmunro]

@jakekemple "Shim" and "Fudges" are the correct developer words. They make perfect sense to me.

@ksperling, I am still having trouble understanding your comment though.

It opens with:

$routeProvider is a shim the implements ...

("the implements" should be "that implements")

Then it continues:

Current AngularJS $routeProvider is also monolithic ...

So is it monolithic, or is it a shim (meaning a very thin layer mostly emulating something else)?

I think you may mean "$urlRouterProvider is a shim that implements the current AngularJS $route / $routeProvider API...".

So we should probably use $urlRouterProvider in preference to $route / $routeProvider, but even better would be to just stick to $stateProvider only.

[timkindberg]

Ok that clears it up, so in the sample app you are just using each one to
show them off but in a real app users may not use either.

[udayms]

If in a real app, I do not need to use '$routeProvider', '$urlRouterProvider', then with just '$stateProvider', how can I do stuff like -

.when('/', {
template: 'hello'
}

or

.when('/', {
redirectTo: '/helloWorld'
}

[ksperling]

You need to use $urlRouterProvider for doing redirects. This is all done with $urlRouterProvider.when(match, handler). Match can be

• a RegExp
• a UrlMatcher
• a String (gets compiled into a UrlMatcher via $urlMatcherFactory)
  The handler is generally a function, this function gets invoked if $location matches. It can return
• falsy to indicate that the rule didn't match after all, then $urlRouter will continue trying to find another one that matches
• a String, which is treated as a redirect and passed to $location.url()
• nothing or any truthy value tells $urlRouter that the url was handled
  The handler can also be a string, which is treated as a redirect, and is interpolated according to the syntax of match (i.e. like String.replace() for RegExp, or like a UrlMatcher pattern otherwise)

There's also a lower-level function $urlRouterProvider.rule() that takes an arbitrary function that gets passed $location. Probably best to look at the source at this point; documenting all this is still on my todo list.

[ksperling]

See my comment on the other issue where you posted this question -- urlRouter rules are tested against $location in the order they are registered.

[chenhui5416]

so, How can I find the api document ?? I couldn't find it in angualrJs.org

[timkindberg]

I should probably write some wiki for urlRouter :/

[nateabele]

@timkindberg Let me know if you need help. I'm usually idling on #angularjs.

[timkindberg]

@ksperling and @nateabele please review my docs for $urlRouterProvider and $urlMatcherFactory.

https://github.com/angular-ui/ui-router/wiki/URL-Routing#urlrouterprovider

https://github.com/angular-ui/ui-router/wiki/URL-Routing#urlmatcherfactory-and-urlmatchers

[nateabele]

Looks good!

[nateabele]

So is it monolithic, or is it a shim (meaning a very thin layer mostly emulating something else)?

@rjmunro The comment refers to two different things. The former is the implementation in Angular core. The latter was UI Router's (no-longer-supported) compatibility layer for people migrating from ngRoute.

Since $routeProvider no longer ships with any supported version of UI Router, I think this thread is moot at this point.