Route functions (no templates)

[gaiottino]

Hi,

I've committed a change that gives us the possibility to add routes that will just evaluate a function when matched instead of rendering a template. I hope you find it useful and bring it into master as it really helped us when refactoring a project into angular and I'm surprised it something that hasn't been implemented yet (if it has, please show me how)

One could basically do something like

angular.module('example', [], function($routeProvider) {
  $routeProvider.when('/foo', {fn: function() {
    console.log('foo!')
  }});
  $routeProvider.when('/bar/:id', {fn: function(params) {
    console.log('bar! with params ' + params)
  }});
});

Regards

[lrlopez]

It's already supported: #1524

If you define a template function that doesn't return anything, the behaviour should be the same...

[gaiottino]

It's not quite the same. Using the template attribute, it expects one to return a string which it will try to render. When not returning anything from the function, it will still clear the ng-view node which is something I specifically do not want to happen. Using the fn-attribute should just call the function and leave the DOM intact (unless one manually updates it in the function itself ofc).

[gaiottino]

Realised that .otherwise was handled a bit differently but added another commit to sort that out.

[IgorMinar]

I'm not sold on this change as it goes against the existing behavior of angular's routing (especially that the ngView doesn't get cleared when a new route is matched), but I'm happy to be convinced otherwise.

@mhevery @vojtajina @jbdeboer @petebacondarwin @pkozlowski-opensource can you weigh in?

[pkozlowski-opensource]

I'm uneasy with this PR (but as @IgorMinar - I'm open to be convinced).

The trouble for me is that as soon as it becomes part of the router I can have a URL that ... points to a function call.

Now let's say that function executes and I can see roughly 3 things it could do:

• execute some logic without DOM changes -> might be confusing to users as there will be little (no?) clue that something changed, visually speaking
• do DOM changes - this would encourage putting DOM manipulation in this function which is probably something we don't want to do
• redirect - in this case maybe the existing redirect capability should be extended?

I don't know, at the moment it just feels fishy, I guess I don't fully see the use-case that @gaiottino is covering here.

@gaiottino, is it primarily for the migration / co-existence scenarios where you rely on the AngularJS routing for your app and call other frameworks from this route-level function?

[johnnyelwailer]

If there's a handler, shouldn't this handler at least be called on a Controller and not in the route Definition?

[petebacondarwin]

Without a concrete use case it is difficult to have a positive view on this PR.

If there is a template associated with each view then this situation if fully solved by putting the functionality into a Controller associated with the route, which has the added benefit of being to able to be injected, not only with the $scope of the ng-view element but also any resolves from the route.

I can imagine, though, a situation where one ones to use the pattern matching of the route provider but have a more sophisticated mapping to views (i.e. hierarchical or multiple views). Perhaps this could be supported by factoring out the route matching into its own service that could be used by application developers service. Their service could simply watch $location, then use the route matching then do whatever they wanted with the result. One could even, in the future, allow $routeProvider to swap in a different route matching engine if an application had different requirements. Any thoughts on that?

[mhevery]

I don't think this feature is consistent with the angular philosophy. Currently we can already execute behavior by putting it into the constructor function. No need for fn. The fact that the view does not get cleared means that the URLs are no longer bookmark-able, since how you got to a URL wil determine what you have rendered, rather then the URL being the whole truth.

Vote: -1

[IgorMinar]

@petebacondarwin making route matching and parameter extraction configurable is an option, but I don't see too many people asking for that. I think that there are areas in routing that could use our attention a lot more than this one.

[IgorMinar]

I'm going to close this PR. Please reopen if you feel strongly against this decision and have good arguments for us to consider.

thanks!

[gaiottino]

I'm fine with this pull request being closed. I spent a bit of time during the day to refactor the way I use the routing with the help of the controller option and setting reloadOnSearch to false. Thanks for your inputs!