$cookies need callback once cookie value is set. #6411

Closed
manishtpatel opened this Issue Feb 23, 2014 · 4 comments

Projects

None yet

8 participants

@manishtpatel

Right now if you set $cookies values then call $http immediately, cookie is not updated in the request. if $cookies returns before saving the cookie in the browser then we need callback to execute code that relies on cookie.

$cookies.myName = 'foo'

// request headers are missing myName cookie update from above line
$http.get('/api/getmystar')

To workaround this issue i have to use setTimeout to wait for some time before i can proceed.

It either need to not set the cookie asynchronously or provide a call back function, call back is not possible with $cookies but $cookieStore atleast should solve this issue.

summary

cookie writes are flushed asynchronously, which makes it hard to predict when the cookie will be picked by other browser apis like XMLHttpRequest used by $http

@bfricka
bfricka commented Feb 27, 2014

Maybe what should be addressed is the fact that ngCookies works via polling instead via some other customary Angular pattern ($digest, promises, etc).

When I first saw the way the API was broken down in $cookies and $cookieStore, I thought $cookies was an object that just updated (i.e. did read/write to document.cookie) on $digest, and $cookieStore was essentially a direct wrapper around document.cookie. I.e. $cookieStore.put('key', 'value'); splits and serializes the cookie and adds your value.

When I looked at the actual implementation, I found it really surprising to find that it updates on a poll function. This is a really odd choice.

I think adding a callback to $cookieStore is poor idea, b/c it doesn't really jive w/ Angular well. But I do think this should be addressed (e.g. by returning a promise).

@IgorMinar IgorMinar added the gh: issue label Mar 6, 2014
@IgorMinar IgorMinar added the type: bug label Jul 24, 2014
@IgorMinar IgorMinar added this to the Backlog milestone Jul 24, 2014
@btford btford removed the gh: issue label Aug 20, 2014
@shahata shahata added a commit to shahata/angular.js that referenced this issue Dec 19, 2014
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411, #7631
dbcf943
@shahata shahata added a commit to shahata/angular.js that referenced this issue Dec 19, 2014
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411, #7631
3f89d91
@shahata shahata added a commit to shahata/angular.js that referenced this issue Dec 19, 2014
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411, #7631
5b5cb7c
@shahata shahata added a commit to shahata/angular.js that referenced this issue Jan 5, 2015
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411
Closes #7631
234e63b
@shahata shahata added a commit to shahata/angular.js that referenced this issue Feb 28, 2015
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411
Closes #7631
072dcd8
@shahata shahata added a commit to shahata/angular.js that referenced this issue Feb 28, 2015
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411
Closes #7631
d1bc67f
@shahata shahata added a commit to shahata/angular.js that referenced this issue Feb 28, 2015
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411
Closes #7631
500349e
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 1, 2015
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411
Closes #7631
ad5c182
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 1, 2015
@shahata shahata refactor($cookieStore): use $browser directly instead of $cookies
This is important in order to avoid the current mechanism where polling is required to get the latest cookies and digest is required to flush the latest changes.

Closes #6411
Closes #7631
b080151
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
@shahata shahata fix($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly call `get` or `getObject` to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
67eaae3
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
@shahata shahata feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly call `get` or `getObject` to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
b078df5
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
@shahata shahata feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly call `get` or `getObject` to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
77d88a4
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
@shahata shahata feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly the methods described above to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
9ecf91e
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
@shahata shahata feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly the methods described above to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
b8aa0a4
@shahata shahata added a commit to shahata/angular.js that referenced this issue Mar 2, 2015
@shahata shahata feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly the methods described above to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
61dbacc
@shahata shahata added a commit that closed this issue Mar 2, 2015
@shahata @petebacondarwin shahata + petebacondarwin feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly the methods described above to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
38fbe3e
@shahata shahata closed this in 38fbe3e Mar 2, 2015
@hansmaad hansmaad pushed a commit to hansmaad/angular.js that referenced this issue Mar 10, 2015
@shahata shahata + hansmaad feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly the methods described above to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
e401139
@netman92 netman92 added a commit to netman92/angular.js that referenced this issue Aug 8, 2015
@shahata @netman92 shahata + netman92 feat($cookies): move logic into $cookies and deprecate $cookieStore
The new API on `$cookies` includes:

 * `get`
 * `put`
 * `getObject`
 * `putObject`
 * `getAll`
 * `remove`

The new API no longer polls the browser for changes to the cookies and no longer copy
cookie values onto the `$cookies` object.

The polling is expensive and caused issues with the `$cookies` properties not
synchronizing correctly with the actual browser cookie values.

The reason the polling was originally added was to allow communication between
different tabs, but there are better ways to do this today (for example `localStorage`).

DEPRECATION NOTICE:

`$cookieStore` is now deprecated as all the useful logic
has been moved to `$cookies`, to which `$cookieStore` now simply
delegates calls.

BREAKING CHANGE:

`$cookies` no longer exposes properties that represent the current browser cookie
values. Now you must explicitly the methods described above to access the cookie
values. This also means that you can no longer watch the `$cookies` properties for
changes to the browser's cookies.

This feature is generally only needed if a 3rd party library was programmatically
changing the cookies at runtime. If you rely on this then you must either write code that
can react to the 3rd party library making the changes to cookies or implement your own polling
mechanism.

Closes #6411
Closes #7631
b5eecdc
@darkbasic

The bug has been closed but $cookies.get() on AngularJS 1.4.7 still doesn't return a promise: how am I supposed to do?

@darkbasic darkbasic referenced this issue in gsklee/ngStorage Nov 10, 2015
Closed

$sessionStorage should return a promise #185

@ZachMoreno

@darkbasic +1

$cookies.get('authentication').then(function(authCookie) {
    var userID = authCookie.id;
});

returns

TypeError: $cookies.get(...).then is not a function

in AngularJS v1.4.7

@lgalfaso
Member

@ZachMoreno $cookies.get('authentication') is a synchronous function

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment