Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

A Build tab edit is lost if the page reloads or closes within a second of typing

Aperta
  • Qualcosa non va?
#598 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@richshaw ci sta già lavorando.

Dal 26/10/2026.

  • #669 di @richshaw — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
frontend

Direzione di ricerca

Start with src/components/build-shared/useBuildState.ts and its tests, especially the debounce, flushPendingSaves from #580, request sending, and unmount cleanup. Check how the Build tab tracks save status and handles pagehide and hidden visibility events. Done means pending edits are sent with keepalive: true on both events, the rail reflects waiting saves, the unmount test still passes, and the listed checks succeed.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug pipeline:building pipeline:ux

What happens

The Build tab saves an edit 800 ms after the last keystroke (DEBOUNCE_MS and flushTimer in src/components/build-shared/useBuildState.ts). The wait is a setTimeout in the page. If the organizer reloads, closes the tab or leaves the site in that time, the timer never fires. The edit is lost, and nothing warns them. In the walkthrough, an organizer edited a slot and reloaded within about a second. The edit was gone both times they tried.

  • Every debounced save is affected: a slot's values (editCell), its spots (setCapacity), and the signup's title and description (updateSignupMeta).
  • Links inside the app are safe. Going to another tab or page unmounts the builder, and the hook's unmount cleanup sends every waiting save. A reload or a closed tab doesn't unmount React, so that cleanup never runs.
  • A save already sent can be lost too. send uses a plain fetch, which the browser can cancel as the page unloads.
  • The rail can say "Saved" over an unsent edit. "Saving…" shows only when the timer fires (withSave). "Saved" stays up for 3 s (SAVED_CLEAR_MS), so the next edit in that time still reads "Saved" for its first 800 ms. That is when someone reloads to check.

The help article says "Your changes save as you go." #504 notes the same gap for the review page.

To see it: create a signup by hand, open its slot, type in What, and reload at once. After the reload, the slot is empty.

Fix, in outline

  • Send waiting saves when the page goes away. On pagehide, and on visibilitychange to hidden (a phone can drop a tab in the background without pagehide), send every save still waiting out its debounce. #580 adds flushPendingSaves to useBuildState; call it, not a second loop over timersRef.
  • Let those requests outlive the page. Give the builder's PATCH requests keepalive: true (an option on send), so the browser finishes them after the page unloads. A slot or signup PATCH body is a few hundred bytes, well under keepalive's 64 KiB limit.
  • Show "Saving…" from the first keystroke. Mark the rail as saving when an edit starts its wait in flushTimer, not when the request starts. "Saved" then shows only when nothing is waiting.
  • No "Leave site?" prompt. With the flush, it isn't needed, and it would appear on every reload while typing.

Watch for

  • Keep the unmount flush. In-app navigation still uses it, and its test in useBuildState.test.ts must keep passing.
  • The back-forward cache. Don't use unload or beforeunload: they keep pages out of the cache in some browsers. A pagehide with persisted: true means the page may come back, so the builder must still work after it does.
  • A save refused during unload can't show its error. That's fine: the next load shows what the server holds.
  • Overlap with #580 and #581, which change useBuildState.ts.
  • CHANGELOG entry.

Order

After #580, which adds flushPendingSaves and tracks saves in flight in useBuildState.ts. Built on main first, this would add a second flush that #580 must then merge with.

Done when

  • A unit test: an edit waiting out its debounce is sent at once, with keepalive: true, when pagehide fires, and again when visibilitychange reports hidden.
  • A unit test: the rail shows "Saving…" as soon as an edit is made, and "Saved" only when nothing is waiting.
  • In the running app, typing in a slot's What and reloading within half a second keeps the value.
  • pnpm lint && pnpm typecheck && pnpm knip && pnpm test pass.

Found by the UX walkthrough (scenario O1) on 2026-10-24, and checked against the code on main at 4ed27a9.

Generated by Claude Code

Lingua principale
TypeScript
Stelle
19
Fork
4
Merge medio
19h 34m
PR unite (30g)
165

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di richshaw/OpenSignup

Tutte le issue di richshaw/OpenSignup

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.