A reading list for a site that never had one

Pages are server components that fetch their own data and stay thin — around 150 lines, with logic pushed into the components below them. Client components are used only where there’s genuine interaction: dialogs, menus, the search field, the theme toggle. Mutations run through server actions, so most interactions never ship a fetch handler to the browser.

A deep navy surface with warm gold accents, Lora italic for headings and Nunito Sans for everything else. Colour and type live entirely in named Tailwind tokens — no raw hex in component code — which is what makes the in-progress light mode a change at the token layer instead of a rewrite of every component.

The card is the unit the whole product is made of. It carries title, author, fandom, word and chapter count, completion status, the user’s private note, and a menu for everything else. It appears in search results, in collections, and in the reading list — same component, different affordances.

• Dialogs inside menus. Dialog state is owned by the parent menu, not the button, so the dialog survives the dropdown closing.
• Portals on mobile. Dialogs render through createPortal to escape the transform containing block Radix creates, which was clipping them on small screens.
• Optimistic saves. Saving a work updates the UI immediately and reconciles when the server action returns.
• Empty states as invitations. A new collection explains what to put in it and links to search, rather than showing a blank grid.

A work card can be turned into an image and shared straight from the phone. The card is rendered to PNG in the browser with html-to-image and handed to the Web Share API where it exists, with a download fallback where it doesn’t.

The extension injects a save button into AO3’s own markup: on work pages, on listing blurbs, and on bookmark pages. It reads the site’s visual language rather than fighting it, and the collections dropdown matches the order used on the site, so the two surfaces feel like one product.

Works are stored once and shared across users; the join table between a user’s collection and a work carries the per-user state. Notes live in their own table, keyed to the user and the work, which keeps them private by construction rather than by filtering.

• works — archive metadata, deduplicated across the whole user base
• collections — owned by a user, with three defaults created on sign-up
• collection_works — membership, reading status, date added
• work_notes — one private note per user, per work

The schema originally assumed AO3 was the only source. Adding FanFiction.net meant a source column, a generated public_id, and a composite unique constraint on source plus site ID. Every step shipped as a no-op against existing rows first — the constraint went on before anything wrote to it, so production data was never in an intermediate state.

NextAuth v5 handles Google SSO and email/password side by side, with verification and reset flows sent through Resend. Row Level Security is the real boundary: even a bug in a query can’t return another user’s collections, because the database refuses.

Saving a work scrapes its metadata from the archive server-side. Restricted works can’t be fetched that way — they’re login-gated — so for those the extension reads the metadata out of the page the user is already authenticated on and posts it up. The scraper returns a discriminated result rather than throwing, so the UI can say this work was deleted and the archive is down differently.

Fics change: chapters are added, works are completed, some disappear. A refresh pass re-checks works in the collection you’re actually looking at, fire-and-forget, so status drift gets corrected during normal use instead of needing a cron job over the whole table.

All writes from the extension go through its background worker so the session cookie travels with the request and CORS stays out of it. The endpoints are deliberately thin: authenticate, check ownership, call the same logic the site uses.