go-guess/frontend/README.md

164 lines
8.5 KiB
Markdown
Raw Permalink Normal View History

2026-09-19 20:31:14 +02:00
# Go Guess frontend
React and TypeScript recruitment workspace built with Vite.
## Commands
```bash
npm install
npm run dev
npm run typecheck
npm run lint
npm run format
npm run format:check
npm test
npm run build
```
Run one test:
```bash
npm test -- src/app/App.test.tsx -t "filters jobs by title"
2026-09-19 20:31:14 +02:00
```
## Source structure
- `src/app` contains the application shell, providers, routes, and route-level tests.
- `src/features` groups pages and components by business capability.
- `src/components` contains UI shared by multiple features.
- `src/config/navigation.ts` defines configurable footer sitemap and useful-link groups.
- `src/api/client.ts` is the typed HTTP boundary.
- `src/types` contains API and domain types.
- `src/styles/global.css` contains shared tokens and layout styles.
Keep feature-only UI close to its feature instead of adding more screens to the
application shell.
2026-09-19 20:31:14 +02:00
## API integration
feat: avatar, account menu, and single sign-on from Go Loose Signing in now starts at the sign-in screen and one button that hands the browser to Go Loose, which returns to the welcome page. Nothing redirects to the identity provider on its own any more: that fired on every anonymous visit and read as a redirect loop rather than as a choice to sign in. The password form remains only where the API reports that Go Loose login is not configured for the host, because otherwise the application is unreachable on a bare localhost. A person's picture is carried through from the Go Loose identity and rendered in the account menu and on the profile page, with their initials as the fallback. Two things make that fallback necessary rather than decorative: Go Loose retires a picture key when a picture is replaced, so a link cached in a browser can be dead, and most people have not uploaded one. The URL is deliberately not persisted locally, since a stored key would keep failing after the picture changed. The account menu is a disclosure rather than a hover menu: a real button with aria-expanded, Escape and outside clicks closing it, and focus returning to the trigger. It is not an ARIA menu, because its actions are a link and a button and menuitem roles would strip the link semantics from one of them for no gain. The account URL of the Go Loose identity is resolved on each sign-in and is read from the live identity provider every time, which is also what makes it correct after a picture change. Depends on the Go Loose revision that serves avatar_url through /connect/userinfo, so the picture URL reaches this application at all.
2026-10-05 21:50:06 +02:00
For tenant hosts such as `nmbs.guess-dev.urpi.be` locally and
`nmbs.guess.urpi.be` in production, `src/api/client.ts` derives tenant `nmbs`,
calls same-origin `/api` through the shared HTTPS proxy, and sends
`X-Tenant-Id: nmbs` on every JSON, multipart, file-download, and event-stream
feat: avatar, account menu, and single sign-on from Go Loose Signing in now starts at the sign-in screen and one button that hands the browser to Go Loose, which returns to the welcome page. Nothing redirects to the identity provider on its own any more: that fired on every anonymous visit and read as a redirect loop rather than as a choice to sign in. The password form remains only where the API reports that Go Loose login is not configured for the host, because otherwise the application is unreachable on a bare localhost. A person's picture is carried through from the Go Loose identity and rendered in the account menu and on the profile page, with their initials as the fallback. Two things make that fallback necessary rather than decorative: Go Loose retires a picture key when a picture is replaced, so a link cached in a browser can be dead, and most people have not uploaded one. The URL is deliberately not persisted locally, since a stored key would keep failing after the picture changed. The account menu is a disclosure rather than a hover menu: a real button with aria-expanded, Escape and outside clicks closing it, and focus returning to the trigger. It is not an ARIA menu, because its actions are a link and a button and menuitem roles would strip the link semantics from one of them for no gain. The account URL of the Go Loose identity is resolved on each sign-in and is read from the live identity provider every time, which is also what makes it correct after a picture change. Depends on the Go Loose revision that serves avatar_url through /connect/userinfo, so the picture URL reaches this application at all.
2026-10-05 21:50:06 +02:00
request. `ypto.guess-dev.urpi.be` behaves identically for tenant `ypto`. Other
hostnames use same-origin `/api`; Vite retains its `/api` proxy for that case.
2026-10-02 21:44:26 +02:00
feat: avatar, account menu, and single sign-on from Go Loose Signing in now starts at the sign-in screen and one button that hands the browser to Go Loose, which returns to the welcome page. Nothing redirects to the identity provider on its own any more: that fired on every anonymous visit and read as a redirect loop rather than as a choice to sign in. The password form remains only where the API reports that Go Loose login is not configured for the host, because otherwise the application is unreachable on a bare localhost. A person's picture is carried through from the Go Loose identity and rendered in the account menu and on the profile page, with their initials as the fallback. Two things make that fallback necessary rather than decorative: Go Loose retires a picture key when a picture is replaced, so a link cached in a browser can be dead, and most people have not uploaded one. The URL is deliberately not persisted locally, since a stored key would keep failing after the picture changed. The account menu is a disclosure rather than a hover menu: a real button with aria-expanded, Escape and outside clicks closing it, and focus returning to the trigger. It is not an ARIA menu, because its actions are a link and a button and menuitem roles would strip the link semantics from one of them for no gain. The account URL of the Go Loose identity is resolved on each sign-in and is read from the live identity provider every time, which is also what makes it correct after a picture change. Depends on the Go Loose revision that serves avatar_url through /connect/userinfo, so the picture URL reaches this application at all.
2026-10-05 21:50:06 +02:00
`src/components/actions/Account.tsx` treats any host whose first DNS label is a
tenant as a possible Go Loose host and asks `/api/auth/session` whether browser
login is available there. A `404` means the API has no Go Loose login for the
feat: palette and light/dark from go-bananas, and fix the image user The theme selector and the appearance toggle are the custom elements go-bananas ships, loaded at run time. They are custom elements rather than components written here because the applications this service feeds are a mix of React, vanilla JavaScript and server-rendered HTML, and a custom element is the one shape all three can use with no build step, no import map, and no second copy of React to break the hooks. Every token in the stylesheet is now written as var(--bn-*, fallback). That ordering is the safety property: with no theme service configured the page renders exactly as it did before, and with one configured the same rules follow the palette. The navigation rail takes the contract's sunken surface and its paired foreground rather than a fixed dark navy, because a light appearance wants dark text there. THEME_BASE_URL is read from runtime-config.js, which the entrypoint rewrites from the environment on start, so one image serves every environment rather than baking a hostname into the bundle at build time. contract.test.ts fetches the live contract and asserts it defines every --bn-* variable this application consumes. A token renamed on the service would otherwise leave every var() resolving to its fallback, and the page would look correct while never actually following the palette. Verified it fails on a deliberately wrong token name. The image also had two USER lines, the second silently replacing the first with a uid that owns neither /app nor /tmp/nginx. nginx could not create its pid file or its temp paths, so the container failed to start. Confirmed by building both variants: the old one cannot write nginx's temp directory, the fixed one serves the front end, its hashed assets, and the /api proxy.
2026-10-05 22:47:20 +02:00
host, so the password form is shown. Otherwise the sign-in screen offers a single
button that hands the browser to Go Loose, which returns to the welcome page.
Nothing redirects to the identity provider on its own: that fired on every
anonymous visit and read as a redirect loop rather than as a choice to sign in.
A person who already signed in at another application passes straight through,
because Go Loose recognises the session it holds and issues a code without
asking anything. The callback exchanges that session for the bearer token used by
the typed API client. Participant routes are exempt: a participant opens the
application through a token link and is never signing in.
## Theming
The palette and the light/dark switch come from
[go-bananas](https://github.com/urpi/go-bananas), the design-token service, as
runtime CSS custom properties. Three pieces, and the application installs all
three itself:
- `src/theme/installThemeRuntime.ts` injects
`<link rel="stylesheet" href="$THEME_BASE_URL/rt/v1/contract.css" data-theme-contract>`
and imports `$THEME_BASE_URL/rt/v1/components.js`. Both are best effort: a
theme service that is absent, slow, or unreachable must not stop the
application working.
- `src/theme/ThemeControls.tsx` renders the service's own custom elements,
`<bananas-theme-selector>` and `<bananas-appearance-toggle>`. They are custom
elements rather than components written here because the applications this
service feeds are a mix of React, vanilla JavaScript, and server-rendered HTML,
and a custom element is the one shape all three can use with no build step, no
import map, and no second copy of React. React treats an unknown element as an
inert host node, so rendering them unconditionally is safe.
- Every token in `src/styles/global.css` is written as
`var(--bn-*, fallback)`. That ordering is the whole safety property: with no
theme service configured the page renders exactly as it did before, and with
one configured the same rules follow the palette.
`THEME_BASE_URL` is read from `runtime-config.js`, which the container entrypoint
rewrites from the environment on start, so one image serves every environment.
`VITE_THEME_BASE_URL` is the equivalent for `npm run dev`.
Two deployment requirements are easy to miss. The service must be configured to
allow this application's origin (`CORS_ALLOWED_ORIGINS` on go-bananas), or the
browser refuses to load the controls from it, because a module script is always
fetched with CORS. And `api.themeBaseUrl` in the Helm values must be set; it is
empty by default, which disables theming.
`src/theme/contract.test.ts` fetches the live contract and asserts it defines
every `--bn-*` variable this application consumes. A token renamed on the service
would otherwise leave every `var()` resolving to its fallback, and the page would
look correct while never actually following the palette.
Invitation and participant-meeting URLs use the validated request origin so
links stay on the tenant hostname. Copy actions fall back to a temporary selected
textarea when the Clipboard API is unavailable on local HTTP domains.
Login stores the returned JWT in
2026-09-19 20:31:14 +02:00
`sessionStorage`; protected requests send it as `Authorization: Bearer <token>`. API failures are
shown in the UI and are never replaced with demo data. A `401` from a protected
JSON, file, or event-stream request clears authentication and returns the user to
feat: avatar, account menu, and single sign-on from Go Loose Signing in now starts at the sign-in screen and one button that hands the browser to Go Loose, which returns to the welcome page. Nothing redirects to the identity provider on its own any more: that fired on every anonymous visit and read as a redirect loop rather than as a choice to sign in. The password form remains only where the API reports that Go Loose login is not configured for the host, because otherwise the application is unreachable on a bare localhost. A person's picture is carried through from the Go Loose identity and rendered in the account menu and on the profile page, with their initials as the fallback. Two things make that fallback necessary rather than decorative: Go Loose retires a picture key when a picture is replaced, so a link cached in a browser can be dead, and most people have not uploaded one. The URL is deliberately not persisted locally, since a stored key would keep failing after the picture changed. The account menu is a disclosure rather than a hover menu: a real button with aria-expanded, Escape and outside clicks closing it, and focus returning to the trigger. It is not an ARIA menu, because its actions are a link and a button and menuitem roles would strip the link semantics from one of them for no gain. The account URL of the Go Loose identity is resolved on each sign-in and is read from the live identity provider every time, which is also what makes it correct after a picture change. Depends on the Go Loose revision that serves avatar_url through /connect/userinfo, so the picture URL reaches this application at all.
2026-10-05 21:50:06 +02:00
`/login`. On a tenant host with Go Loose configured, the app restores
`/api/auth/session` or redirects to `/api/auth/login`; participant routes stay
token-based. The app also schedules logout from the JWT expiration claim so an idle
expired session cannot remain on a protected page.
2026-09-19 20:31:14 +02:00
The machine-readable OpenAPI 3.0 contract at `/api/openapi.json` is the source
of truth for supported routes and schemas. It is assembled by the backend from
the same typed calls that register Chi routes, so there is no generated file or
manual update command. Do not duplicate a route inventory here; inspect the
contract instead.
2026-09-19 20:31:14 +02:00
Participant creation uses multipart fields `firstName`, `lastName`, `birthday`, `email`,
`contactInfo`, `photo`, and `cv`.
## Interview workflow
Authenticated interviewers create and edit reusable questions at `/questions`, configure job
2026-09-19 20:56:27 +02:00
status and duration, attach active library questions, and generate invitations for each eligible
participant from a job detail page. Multiple-choice and radio questions require at least two
explicitly added options.
2026-09-19 20:31:14 +02:00
Detaching a question removes only the job association; questions can be deprecated but not deleted.
Open-answer and code-review questions include an interviewer-only reference answer that is never
2026-09-19 20:56:27 +02:00
rendered in the participant interview. Code-review questions also require a code snippet.
Accepted and completed invitations can be opened from the job to review every participant answer,
possible choice options, reference answers, and code-review context; unanswered questions are
called out explicitly.
Completed assessments can be marked as passed or failed. Passed candidates expose a scheduling
form for the date, location, co-interviewers, and candidate-visible shared documentation.
The authenticated workspace also includes:
- **Users** for listing and creating co-interviewers.
- **Invitations** in the top-right account navigation for accepting or declining assignments.
- **Profile** in the top-right account navigation for the logged-in user's identity and role.
- **Schedule** for interviews grouped by date.
- **Interviewer sessions** for changing status, editing prominent shared documentation, and
posting private notes while an interview is started. Notes and shared-document changes arrive
live through an authenticated streaming `fetch`; the app intentionally does not use
`EventSource`, because the request needs the JWT authorization header.
2026-09-19 20:31:14 +02:00
The authenticated layout ends with a sitemap and useful-links footer. Update
`src/config/navigation.ts` to add, remove, or reorder footer destinations.
2026-09-19 20:56:27 +02:00
Participants open the generated `/participant/:invitationId` URL without signing in. The opaque
invitation ID authorizes the existing `/api/interviews/:token` API. Code-review questions are shown
in a pull-request-style code panel with a review comment field. Answers are saved when navigating
between questions and as they change, then **Submit** completes the interview. The countdown is
derived from the backend `acceptedAt` timestamp plus the job duration so refreshing cannot reset
it. Questions stay hidden until the participant explicitly accepts the invitation.
2026-09-19 20:31:14 +02:00
Scheduled candidates use `/participant/meeting/:token`. This public view shows the interview date,
location, status, and read-only shared documentation. A token-authorized event stream updates the
document immediately when an interviewer saves it in another browser. The participant view never
receives interviewer notes or assessment reference answers.
2026-09-19 20:31:14 +02:00
## Container
Build with `docker build -t go-guess-frontend .`. The production Nginx server
2026-10-02 21:44:26 +02:00
serves the SPA and proxies `/api` to the Docker Compose service `api:8080`.