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

Skill Feedback: db-core collection-setup + mutations + react-db (mixed)

Aperta
  • Qualcosa non va?
#1,333 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
48/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
postgres, typescript
Ambito
documentation

Direzione di ricerca

Inizia con la documentazione degli skill collection-setup, schema, mutations-optimistic, react-db e meta-framework descritta nell’issue. Aggiorna gli esempi e le indicazioni per coprire i percorsi parser/schema di Electric, le mappature PostgreSQL-to-Zod, i generics schema-first e un percorso di scrittura server-function di TanStack Start; il lavoro è completato quando queste lacune sono documentate in modo coerente nel workflow end-to-end.

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

Descrizione

Skill Feedback: db-core/collection-setup + db-core/mutations-optimistic + react-db + meta-framework

Package: @tanstack/db + @tanstack/react-db
Skill version: 0.5.30
Rating: mixed

Task

Build a real-time synced todo app using Electric + TanStack DB + TanStack Start, with Postgres as the backend.

What Worked

  • The collection-setup skill's adapter selection table was immediately useful for picking electricCollectionOptions
  • The mutations-optimistic skill's Immer-style draft proxy pattern (collection.update(id, (draft) => { draft.completed = true })) was accurate and intuitive
  • The react-db skill's useLiveQuery with dependency arrays worked correctly
  • The meta-framework skill's ssr: false + collection.preload() pattern for TanStack Start was essential and correct
  • The TInput/TOutput superset rule explanation in the schema docs was clear

What Failed

  • The collection-setup skill shows electricCollectionOptions<Todo>({...}) with an explicit generic, but the actual overload requires the generic on createCollection<Todo>() when no schema is provided. With a schema (the recommended approach), no generic is needed at all.

Missing

1. Schema validates mutations only — not synced data

This is the most critical missing piece. The schema docs say "Schemas validate client changes only" but this distinction is buried and easy to miss. When using Electric, synced data bypasses the schema entirely and enters the collection as raw (parser-transformed) values. This means:

  • The Electric parser in shapeOptions handles the sync path
  • The Zod schema handles the mutation path (insert/update)
  • You need BOTH for types like timestamptz

This caused a runtime error that was hard to diagnose. The collection-setup skill should explicitly state this dual-path when discussing Electric collections with schemas.

2. Schema should always be used (not bare generics)

The skill examples sometimes show electricCollectionOptions<Todo>({...}) without a schema. The recommended pattern should always be schema-first, with the type inferred from z.output<typeof schema>. This avoids the generic placement confusion entirely.

3. PG-type → Zod-type mapping for Electric collections

When using Electric, the skill should document which Zod types to use per Postgres type:

  • bool → z.boolean() (Electric auto-parses)
  • int4 → z.number() (Electric auto-parses)
  • timestamptz → z.coerce.date() (needs parser too — see point 1)
  • text / uuid → z.string()
  • The z.union([z.string(), z.date()]).transform(...) pattern works but z.coerce.date() is simpler and satisfies the TInput-superset-of-TOutput rule automatically (TInput is unknown)
4. No TanStack Start server function examples for write path

The mutation handlers show api.todos.create() as a placeholder. For TanStack Start users, a concrete createServerFn example showing the Postgres transaction with pg_current_xact_id() returning { txid: Number(txid) } would close the biggest gap in the end-to-end story.

Self-Corrections

  • Initially used a bare Todo type generic instead of a Zod schema — user corrected this
  • Removed the Electric parser thinking the schema would handle timestamptz on the sync path — it doesn't, schemas only run on mutations
  • Used z.union([z.boolean(), z.string()]).transform(...) for booleans before learning Electric auto-parses them

User Comments

"Just frustrating that the SKILL didn't cover everything" — the schema-vs-parser dual path for Electric collections is the key gap.

Lingua principale
TypeScript
Stelle
3.9k
Fork
272
Merge medio
1g 1h
PR unite (30g)
222

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 TanStack/db

Tutte le issue di TanStack/db

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.