-
Notifications
You must be signed in to change notification settings - Fork 27.5k
$cookies need callback once cookie value is set. #6411
Comments
Maybe what should be addressed is the fact that When I first saw the way the API was broken down in 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 |
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 angular#6411 Closes angular#7631
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 angular#6411 Closes angular#7631
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 +1
returns
in AngularJS v1.4.7 |
@ZachMoreno |
I confirm this issue. It must be an async function. It refreshes too late. |
Any update on this? Having a timeout is the only workaround? |
As already mentioned, the |
Here is a reproduction of the problem. Loading this server creates a login/registration application but the page must be refreshed after clicking Login or Logout before the new Partial will be loaded. |
@WolfElkan, this does not demonstrate that |
I run into this issue if I have an interceptor. So the basic code goes like so:
The interceptor expects the cookie to exist, however, it does not always. This drove us a little nuts trying to figure out why the cookie was appearing, however unavailable. Throwing $state into a timeout of about 250ms resolves this. Although the timeout could vary I'm sure. |
As already mentioned, all calls and expression that happen as part of Again, without a reproduction of the issue, there is nothing we can do. Happy to investigate if someone can provide a repro. |
I was able to reproduce, but my problem was a bug on my end. The interceptor was a factory and we accidentally set the $cookie result outside the response function. Since that variable was not accessible, it was really a shot in the dark regarding when the $cookie would be set. By setting a timeout, it would guarantee the $cookie was set BEFORE the request function was called. Basically, the $cookie was not updating due to it sitting in a factory as a private variable which didn't propagate to the function expecting it, but it WAS eventually set so it looked like it was set, but in reality it wasn't updated before the request. Resolution: Set the cookie in the same function as it's being used (or get). |
still happening. Anyone got an update on that callback? |
This was indeed an issue because I clearly remember I had to workaround it a couple of years ago. Since I don't use AngularJS anymore I'm no more interested to see it fixed. |
Well it appears that it is not isolated to this angular lib. https://github.com/gsklee/ngStorage also experiences and recommends a solution to this issue. (read at the bottom of the readme) |
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
The text was updated successfully, but these errors were encountered: