$location.search() unreliable when not using routing

[kzar]

I'm having trouble using $location.search() to get / set query parameters. I'm not using Angular's routing at all and I think that might be the trouble.

Without HTML5 mode

  http://localhost/example/?a=b
  $location.search() => {}

  http://localhost/example/#?a=b
  $location.search() => {a: 'b'}

(With HTML5 mode both work but then when using my app from legacy browsers the URL's path is replaced with something like #!/example which complete breaks it.)

I had a go at fixing this myself but got stuck rather, here's a test I wrote for the html5 history is disabled part of locationSpec.js:

it('should handle search properly even without hashbang', function() {
  initService(false, '!');
  inject(
    initBrowser('http://domain.com/base/index.html?a=b', '/base/index.html'),
    function($rootScope, $location, $browser) {
      expect($browser.url()).toBe('http://domain.com/base/index.html?a=b');
      expect($location.search()).toEqual({ a: 'b'});
      $location.search({ a: 'c'});
      $rootScope.$apply();
      expect($browser.url()).toBe('http://domain.com/base/index.html?a=c');
    }
  );
});

(People are talking about the issue at the bottom here but that one has long since closed and I think originally was about something else.)

I got this problem originally with 1.0.7 but I've since tried 1.2.0rc3 and it still happens.

Cheers, Dave.

[dbkang]

This confused me greatly at first, but $location.search() is only supposed to handle query parameters in the client-side URL - if you disable HTML5 mode, none of the url http://localhost/example/?a=b is client-side - this is just a hard url and changing it would force the browser to move to another page, at which point the AngularJS app loses control. So in order for you to use query parameters through $location.search(), you have to use the hashbang.

[kzar]

What you're saying makes sense and I agree but let's think this through. Supposing I hadn't realised the distinction you mention (like I hadn't!), my query parameters weren't in the client-side URL and AngularJS allowed me to use .search() anyway:

If I changed a query parameter it would have been immediately clear what was going wrong when the page refreshed if it no longer worked. In my application the page refreshing with the new "hard" URL would have not broken anything, but supposing it had I would have very quickly realised what was happening.

If I only wanted to read the query parameters I wouldn't have to understand the distinction, it would just work.

On the other side, with the current behaviour, it's really confusing as to what's going on. You're given pretty much no clues what's happening and it's not really talked about in the $location documentation. You try to read or write the parameters and they're just not there, it looks like a bug on first glance and it probably means you have to re-implement a subset of $location.search() which really sucks.

Therefore I purpose that $location.search() be changed to support the query parameters no matter how the URL is structured, I think it would be much more intuitive and useful.

Cheers, Dave.

[dbkang]

But what happens if your URL is:

http://localhost/example/?a=b#/clientroute/a=c

Which is quite possible in the hashbang mode?

Hmm I was thinking maybe window.location.search has what you need but it doesn't look like that's the case.

The easiest way, I think if you're using query-strings in the server side URL, is probably to have the server-side framework parse those for you somewhere.

[kzar]

Good point, fair enough!