docs(sessions): Correction about commitSession in non-cookie sessions

[penx]

Closes: #9444

• Docs
• n/a Tests

The docs for createCookieSessionStorage state:

With other session storage strategies you only have to commit it when it's created

https://remix.run/docs/en/main/utils/sessions#createcookiesessionstorage

When we moved from createCookieSessionStorage to another storage solution (createKvSessionStorage from @vercel/remix), we followed this advice and removed calls to commitSession (assuming it was not needed, and that session.set would be all that is required) but it resulted in sessions not being saved.

Elsewhere in the docs for createSessionStorage:

updateData will be called from commitSession

https://remix.run/docs/en/main/utils/sessions#createsessionstorage

Which seems to imply that anything based on createSessionStorage will require a call to commitSession in order to update the session, and I'm fairly sure explains why we would have bugs when removing calls to commitSession.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 149997c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[penx]

@brophdawg11 anything needed to get this merged? 🙏

[brophdawg11]

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).