Skip to content

docs(utils/sessions): Correction about commitSession in non-cookie sessions #9445

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from
Closed

docs(utils/sessions): Correction about commitSession in non-cookie sessions #9445

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
c0dc8e3
Update sessions.md - note about commitSession
penx May 16, 2024
7d4813e
Update docs/utils/sessions.md
penx May 16, 2024
bf64b0d
Update docs/utils/sessions.md
penx May 17, 2024
1bc8c88
Apply suggestions from code review
penx May 17, 2024
0aed7c6
Update docs/utils/sessions.md
penx May 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 7 additions & 1 deletion docs/utils/sessions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -277,7 +277,13 @@ For purely cookie-based sessions (where the session data itself is stored in the

The main advantage of cookie session storage is that you don't need any additional backend services or databases to use it. It can also be beneficial in some load-balanced scenarios. However, cookie-based sessions may not exceed the browser's max-allowed cookie length (typically 4kb).

The downside is that you have to `commitSession` in almost every loader and action. If your loader or action changes the session at all, it must be committed. That means if you `session.flash` in an action, and then `session.get` in another, you must commit it for that flashed message to go away. With other session storage strategies you only have to commit it when it's created (the browser cookie doesn't need to change because it doesn't store the session data, just the key to find it elsewhere).
The downside is that you have to `commitSession` and send a "Set-Cookie" header from every loader and action that changes the session. This means, for example, that if you `session.flash` in an action, and then `session.get` in another, you must commit it for that flashed message to go away.

This can cause complications if loaders or actions are writing to the same session at the same time.

With other session storage strategies you only have to send a "Set-Cookie" header when the session is created (the browser cookie doesn't need to change because it doesn't store the session data, just the key to find it elsewhere).

Note that you still need to call `commitSession()` when you change the session for anything based on `createSessionStorage`, you just don't need to send an updated header.
Comment on lines +280 to +286
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the confusion in the original docs is that the phrase "commit" is being used when it really means "set header". So we mean to say "with others you don't need to set the header every time" but we instead incorrectly imply that with others scenarios "you don't need to commitSession every time".

What about this slight update to the original wording? Instead of re-iterating that you need to commitSession after changes (which is only needed because of the incorrect implication that you don't) - we can just remove the misleading implication otherwise and indicate the true difference which relates to the Set-Cookie header:

Suggested change
The downside is that you have to `commitSession` and send a "Set-Cookie" header from every loader and action that changes the session. This means, for example, that if you `session.flash` in an action, and then `session.get` in another, you must commit it for that flashed message to go away.
This can cause complications if loaders or actions are writing to the same session at the same time.
With other session storage strategies you only have to send a "Set-Cookie" header when the session is created (the browser cookie doesn't need to change because it doesn't store the session data, just the key to find it elsewhere).
Note that you still need to call `commitSession()` when you change the session for anything based on `createSessionStorage`, you just don't need to send an updated header.
The downside is that you have to update the cookie via a `Set-Cookie` header in almost every loader and action. If your loader or action changes the session at all, it must be sent back as an updated cookie. That means if you `session.flash` in an action, and then `session.get` in another, you must update it for that flashed message to go away. With other session storage strategies you only have to send the `Set-Cookie` header it when it's created (the browser cookie doesn't need to change because it doesn't store the session data, just the key to find it elsewhere).


```ts
import { createCookieSessionStorage } from "@remix-run/node"; // or cloudflare/deno
Expand Down