Disable UI-Router interaction with the window.

Question

This is a long shot, but the UI router is so popular that maybe someone here will have an idea about this problem.

I am porting a project to Angular JS. A project consists of a page with several different panels, each of which is loaded from the server as HTML using AJAX, injected into the page using Javascript and linked to its own href, which is controlled by jQuery History .

The jQuery history monitored browser states and updated window.href accordingly after each panel was added with Javascript. For instance:

Panel 1: window.location.href // http://myapp.com/panel1 History.getLocationHref() // http://myapp.com/panel1 History.getPageUrl() // http://myapp.com/panel1 Panel 2: window.location.href // http://myapp.com/panel2 History.getLocationHref() // http://myapp.com/panel2 History.getPageUrl() // http://myapp.com/panel2 Panel 3: window.location.href // http://myapp.com/panel3 History.getLocationHref() // http://myapp.com/panel3 History.getPageUrl() // http://myapp.com/panel3 

etc. etc.

Since each of these panels is introduced rather than compiled using Angular after injection into the DOM, I download separate AngularJs applications for each of them. So far, this has worked fine.

Now I am using the AngularJs UL router in Panel 2, so I can display data in alternative templates. The problem is that the UI-Router must somehow corrupt the browser history and / or the href window. Since after this application has been created, let's say I start with Panel 1, then on Panel 2, then on Panel 3, I have this problem:

 Panel 1: window.location.href // http://myapp.com/panel1 History.getLocationHref() // http://myapp.com/panel1 History.getPageUrl() // http://myapp.com/panel1 Panel 2: window.location.href // http://myapp.com/panel2 History.getLocationHref() // http://myapp.com/panel2 History.getPageUrl() // http://myapp.com/panel2 Panel 3: window.location.href // http://myapp.com/panel2 History.getLocationHref() // http://myapp.com/panel2 History.getPageUrl() // http://myapp.com/panel3 

basically, as soon as the UI-Router is created using the application, the jQuery history no longer works, and the href location is stored at the url of the ui-router application.

Is there anything I can do to disable ui-router interaction with the href window location? Or is it an integral part of the module?

Here is my panel2.states.js file if it helps:

 angular.module("panel2") .config(["$stateProvider", function($stateProvider) { $stateProvider .state('table', { views: { index: { // controller: "TableController as at", templateUrl: "table.html" } } }) .state('tiles', { views: { index: { // controller: "TilesController as tc", templateUrl: "tiles.html" } } }); }]); 

Update (4/27/2015)

I solved my problem by simply getting rid of the jQuery history and the functions that it adds beyond what we need. Instead, I just interact directly with window.history :

  window.history.pushState({panel: "panel3"}, document.title + " | " + 'panel3', window.location.href + "/panel3"); 

I'm still interested to know what caused this interaction, and if Angular or Angular ui-router interacts directly with window.location?

Answer 1

Angular provides the $location service with interaction with the window.location object, and I am sure that ui-router uses this object and not the window.location object directly. You can decorate the $location service from your config function to intercept all calls to the $location service and provide your own implementation, which does not use window.location .

eg. (very simplified):

 $provide.decorate('$location', function($delegate) { var currentUrl = ''; //we base the proxy on the original var locationProxy = Object.create($delegate); //and overwrite what we need locationProxy.url = function(newUrl) { if (newUrl) { $rootScope.$broadcast('$locationChangeStart' /* other event args here*/); currentUrl = newUrl; $rootScope.$broadcast('$locationChangeSuccess' /* other args here */); } else { return currentUrl; } }; }); 

This requires that you implement all the functions in a compatible way with the original $location service, so it will probably be quite a lot of work.