This repository has been archived by the owner on Dec 12, 2023. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Refactor session handling #48
base: main
Are you sure you want to change the base?
Refactor session handling #48
Changes from 20 commits
5138f30
a34d5d8
4dc1d99
1a261b7
99ac27f
efc7dc2
3629aa8
8fbed4a
1cb0215
dbd6bf4
46d9d1f
59b3b09
79eaf84
9d39b4d
293ad80
50cd690
0621975
477769f
b98f67e
8238d43
7b55c78
90d68bc
65a5f34
0b5b25a
0418846
dd4b7b3
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
expressjs/session
recommends false by defaultThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
expressjs/session
recommends false, but the current behavior of@sidebase/nuxt-session
is true, so I've chosen to not change the default behavior. It is also recommended to setresave
to false.We can change it if you want.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to move copying logic this into the
getSession
soensureSession
either creates a new one or returns a copy of the oldThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving the copying logic to
getSession
would not work, as theoldSession
object has to be different from the one saved to the event context. We could return a copy of the session after saving a reference to the event context inensureSession
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's get confusing here, as you got too many session names:
session
,oldSession
,newSession
andstoredSession
(whereoldSession
is in actuality can be newly created or existing one)Please propose a better naming for those
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overwriting standard node js methods is obviously not recommended. Is there a better way doing that?
res.end
can be async, since it is expected to returnthis
according to the docs I don't think it's being awaited. Was it at least tested with long timeouts?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems that there is no alternative, as already mentioned in #41. There is no hook at the end of all event handlers, and no event that fires just before sending the response.
res.end
returns always aServerResponse
, and here it returns aPromise<ServerResponse>
. Also there are multiple overloads, andres.end
also accepts a callback. In express session this leads to problems, so they decided to ditch the callback, as it is very rarely used.res.end
being async, but it works perfectly. I tested with long timeouts with various conditions, so it must be awaited, but I didn't check it in the node source code.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you need to typecast it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
res.end.call()
returnsany
, notServerResponse