Script Review page + SessionProvider

ic3w0lf22 commented

2025-07-08 19:38:04 +00:00

Member

The session provider reduces the copy & pasted code found in the header & mapfix page by sharing session data across pages/elements.

Hopefully I've implemented SWR correctly 😸

The session provider reduces the copy & pasted code found in the header & mapfix page by sharing session data across pages/elements. Hopefully I've implemented SWR correctly 😸

ic3w0lf22 added 4 commits 2025-07-08 19:38:04 +00:00

Script review page, server-side session fetching & no more manually fetching session information

continuous-integration/drone/push Build is passing

Details

5995737dc3

Build Succeed.

continuous-integration/drone/push Build is passing

Details

7cf0bc3187

Build Succeed - working script review page

continuous-integration/drone/push Build is passing

Details

continuous-integration/drone/pr Build is passing

Details

184795a513

diff

continuous-integration/drone/push Build is passing

Details

continuous-integration/drone/pr Build is passing

Details

3aedc4743f

ic3w0lf22 added a new dependency 2025-07-08 20:03:23 +00:00

#222 Fix thumbnails, reduce network activity, rate limiting, caching, script review page

Quaternions commented

2025-07-09 15:09:05 +00:00

Owner

Why is there web/src/app/_components/SessionContext.tsx and web/src/app/lib/session.ts? Are they multiple implementations of the same thing? This is easier to identify which code belongs to which feature, and thus what it might be used for, but there is still two features rolled into one PR here :P

Why is there `web/src/app/_components/SessionContext.tsx` and `web/src/app/lib/session.ts`? Are they multiple implementations of the same thing? This is easier to identify which code belongs to which feature, and thus what it might be used for, but there is still two features rolled into one PR here :P

ic3w0lf22 commented

2025-07-09 19:26:54 +00:00

Author

Member

session.ts handles the server-side fetching of session data. It's used in layout.tsx (server component), to load the user's info before the page renders, which helps avoid the "login flash" issue.
SessionContext.tsx is the way the client-side receives session info from the server using SWR. It initially uses the preloaded data from the server (via SWR's fallback) and re-fetches the user's roles every 60 seconds to keep things up to date.

Here's a diagram ChatGippity drew up:

┌────────────────────────────┐
│     Server-side Render     │
│    (e.g., layout.tsx)      │
└────────────┬───────────────┘
             │
             ▼
 ┌─────────────────────────────┐
 │ getSessionUser / Roles()    │ ←── from `session.ts`
 │  - Uses next/headers.cookies│
 │  - Fetches from API         │
 └────────────┬────────────────┘
              │
              ▼
 ┌───────────────────────────────┐
 │   SWRConfig fallback setup    │ ←── passes fetched data
 │ "/api/session/user" = user    │
 │ "/api/session/roles" = roles  │
 └────────────┬──────────────────┘
              │
              ▼
┌────────────────────────────────────────┐
│      Client-side React Components      │
│       (wrapped in <SessionProvider>)   │
└────────────────┬───────────────────────┘
                 │
                 ▼
      ┌────────────────────────────┐
      │ SessionContext.tsx         │
      │ - useSWR to fetch session  │
      │ - Reads from fallback first│
      │ - Refreshes every 60s      │
      └────────────┬───────────────┘
                   │
                   ▼
         ┌────────────────────┐
         │ useSession() hook  │ ←── used in any client component
         └────────────────────┘

there is still two features rolled into one PR here :P

yea um, this was implemented randomly while I was writing the script review page, I saw that different pages were manually requesting the user's roles so that's how it ended up in this PR

`session.ts` handles the server-side fetching of session data. It's used in `layout.tsx` (server component), to load the user's info before the page renders, which helps avoid the "login flash" issue. `SessionContext.tsx` is the way the client-side receives session info from the server using SWR. It initially uses the preloaded data from the server (via SWR's `fallback`) and re-fetches the user's roles every 60 seconds to keep things up to date. Here's a diagram ChatGippity drew up: ```pgsql ┌────────────────────────────┐ │ Server-side Render │ │ (e.g., layout.tsx) │ └────────────┬───────────────┘ │ ▼ ┌─────────────────────────────┐ │ getSessionUser / Roles() │ ←── from `session.ts` │ - Uses next/headers.cookies│ │ - Fetches from API │ └────────────┬────────────────┘ │ ▼ ┌───────────────────────────────┐ │ SWRConfig fallback setup │ ←── passes fetched data │ "/api/session/user" = user │ │ "/api/session/roles" = roles │ └────────────┬──────────────────┘ │ ▼ ┌────────────────────────────────────────┐ │ Client-side React Components │ │ (wrapped in <SessionProvider>) │ └────────────────┬───────────────────────┘ │ ▼ ┌────────────────────────────┐ │ SessionContext.tsx │ │ - useSWR to fetch session │ │ - Reads from fallback first│ │ - Refreshes every 60s │ └────────────┬───────────────┘ │ ▼ ┌────────────────────┐ │ useSession() hook │ ←── used in any client component └────────────────────┘ ``` > there is still two features rolled into one PR here :P yea um, this was implemented randomly while I was writing the script review page, I saw that different pages were manually requesting the user's roles so that's how it ended up in this PR

Quaternions commented

2025-07-10 00:52:20 +00:00

Owner

Re-fetching roles every 60 seconds is rather pointless considering they are cached for 30 minutes.