You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One thing I’ve been thinking about recently is the interaction between RSCs, concurrent rendering and cookies. It’s a complex area but I’ll try to be concise, I’m happy to follow up with clarifications if the questions doesn't make sense.
Some of this spans across React and the framework level.
Essentially it boils down to: Cookies can not fork, but are sent as part of the request to RSCs. Because these requests can be made both in the WIP-render and in the current fiber (if a sync update interrupts), does that mean setting cookies client side can not be part of a transition if they are also read on the server, as regardless if you set it early or late, one of these calls would send the wrong cookie for its fork of the world?
Moving the setting of cookies to a server function, so we can re-render and return the RSCs as part of the action seems like it might match more closely with the paradigm. Now the cookie is set in a Set-Cookie header though, meaning the browser sets it when the response returns, not necessarily when that concurrent render commits (or are there guarantees I'm missing here)? If so, this also seems like it might have race conditions?
Does this mean setting cookies needs to pair with synchronous updates, not concurrent ones? I acknowledge I might be thinking about this all wrong, I’m specifically looking for guidance for what the mental model is here. 😄 When, where and under what conditions is it safe to set cookies?
I haven’t seen this addressed elsewhere but might have missed it, so any pointers to previous discussions are also most welcome, even if they don’t directly answer the questions.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi!
One thing I’ve been thinking about recently is the interaction between RSCs, concurrent rendering and cookies. It’s a complex area but I’ll try to be concise, I’m happy to follow up with clarifications if the questions doesn't make sense.
Some of this spans across React and the framework level.
Essentially it boils down to: Cookies can not fork, but are sent as part of the request to RSCs. Because these requests can be made both in the WIP-render and in the current fiber (if a sync update interrupts), does that mean setting cookies client side can not be part of a transition if they are also read on the server, as regardless if you set it early or late, one of these calls would send the wrong cookie for its fork of the world?
Moving the setting of cookies to a server function, so we can re-render and return the RSCs as part of the action seems like it might match more closely with the paradigm. Now the cookie is set in a Set-Cookie header though, meaning the browser sets it when the response returns, not necessarily when that concurrent render commits (or are there guarantees I'm missing here)? If so, this also seems like it might have race conditions?
Does this mean setting cookies needs to pair with synchronous updates, not concurrent ones? I acknowledge I might be thinking about this all wrong, I’m specifically looking for guidance for what the mental model is here. 😄 When, where and under what conditions is it safe to set cookies?
I haven’t seen this addressed elsewhere but might have missed it, so any pointers to previous discussions are also most welcome, even if they don’t directly answer the questions.
Beta Was this translation helpful? Give feedback.
All reactions