angular/angular.js — pull request #10530 by shahata (2014-12-19 18:55:51+00:00)
Title: ng-cookies

This is an initial suggestion for dealing with the current issues with angular cookies. The main things added by this:
1. An `options` parameter was added to `$cookieStore` service which supports passing `path`, `domain`, `expires` and `secured` parameters.
2. `$cookieStore` was refactored so it will use `$browser.cookies()` directly instead of going through `$cookies`. This was in order to allow direct update/read of cookies instead of going through polling/digest mechanism.
2. `$cookies` was deprecated in order to stop using the polling/digest mechanism and instead `getRaw`, `getAll` and `putRaw` methods were added to `$cookieStore` in order to accommodate some of the stuff that were previously available only when using `$cookies`

This is obviously just my take on this and completely open for discussion.

Some open issues:
1. The cookie setting logic is currently located in `$browser` although it is not used internally by angular (angular only uses the cookie reading logic for `XSRF-TOKEN`). It might be better to just move it into `ngCookies`. On the other hand maybe it should be left in `$browser` for balance, I don't know.
2. Theoretically it is possible to leave `$cookies` alive and make its properties getters/setters using `Object.defineProperty` (assuming everyone else agrees that polling/digest mechanism is bad), but we would still need some sort of polling for learning about new cookies. I think we'd better just deprecate it.
3. I'm somewhat uncomfortable with the `getRaw`/`get` and `putRaw`/`put` duplication. Another option can be to use something like `isJsonLike` in `$http` or add a flag to `get`/`put` or use `try`/`catch`, but I don't like it very much. Since `getRaw`/`putRaw` are consistent with `getAll` (which must be raw imo), I like this option best.