use case: support for non-navigation hash changes

[spencerwi]

In my org's app, we frequently have pages whose URLs contain filters. For example:

viewGroceryList/:groceryListId
viewGroceryList/:groceryListId/:storageLocationId
viewListItem/:itemId

...allowing users to go back and forth between storage locations (stuff users keep in their pantry, stuff in the fridge, etc). Ideally, the controller could, on switching storage locations, go fetch the right set of items, then update the URL to preserve deep-linkability without creating a bunch of history entries (so that the "back" button takes them out of the current page rather than out of the current storage location) while allowing the user to go "back" (via browser back) from viewListItem to the correct storage location.

However, in ngRoute 1.x, we are unable to do this because any URL changes trigger navigation -- which means tearing down the controller and DOM and setting up new copies of the controller and DOM.

So I suppose I have two questions:

1.) Will such a use-case be supported by the 2.x router, and/or
2.) Are we simply doing things incorrectly (even for 1.x) with our current approach?

[btford]

@spencerwi – this seems like a good use case, and something I'd like the new router to support. Thanks for the write-up!

[tkrotoff]

in ngRoute 1.x, [...] any URL changes trigger navigation

Check angular/angular.js#1699, there are some tricks to allow this with ngRoute

Related issue: #341