Replies: 1 comment
-
What I usually do is to keep the session in a httpOnly cookie, then at the begging of the app I use SWR to fetch the logged in user data (something like /api/me), if this request fails (because user is not logged in) I redirect to login, if it works I keep rendering the app. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I recently looked a some of my code and it looked repetitive like this:
All calls require a session (which can expire).
So seeing this code I thought I might refactor the code to have the session hook export the
get
,post
etc functions argumented with the session ID. Then the session hook could also check for expired session server responses and refresh the session accordingly without the caller knowing about it. I also can't to the session handling on API level, because there the business logic of sessions is unknown.So the refactored code would look like this:
Then whenever an API method exposed by the useSession() runs into an expired session it can transparently refresh the session and performing the request again with the new session id. It lifts the burden of doing that from each individual API request.
Is this an actual pattern for using swr and accompanied manipulation functions?
Beta Was this translation helpful? Give feedback.
All reactions