Jchris/attach-redo

[jchris]

No description provided.

[netlify]

✅ Deploy Preview for fireproof-ai-builder ready!

Name	Link
🔨 Latest commit	7d4b6e0
🔍 Latest deploy log	https://app.netlify.com/projects/fireproof-ai-builder/deploys/68d5cac5bf354700082401e0
😎 Deploy Preview	https://deploy-preview-307--fireproof-ai-builder.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[charliecreates]

The ImageGeneratorExample component contains an early return; that makes the entire component unreachable and non-functional—this must be removed. The thumbnails in the image history don’t set selectedImageId, leaving existing state unused and the gallery less useful. Debug configuration for ImgGen is applied inconsistently between the main view and thumbnails. In TodoListExample, committing edits on input blur risks unintended saves; prefer explicit save/cancel actions.

Additional notes (2)

• Readability | use-vibes/examples/react-example/src/ImageGeneratorExample.tsx:208-223
  You already have selectedImageId state, but there’s no way to set it from the history thumbnails. Adding a click target makes the gallery useful (e.g., select a prior image to view/edit in the main ImgGen).

• Maintainability | use-vibes/examples/react-example/src/ImageGeneratorExample.tsx:211-219
ImgGen debug is passed via options.debug in the main view, but via a top-level debug prop in thumbnails. This inconsistency makes the component API usage harder to follow and invites configuration drift.

Summary of changes

• Added two new example components under use-vibes/examples/react-example/src/:
  • ImageGeneratorExample.tsx: A simple image generator UI using ImgGen, with prompt input, quality slider, optional image upload/edit, and a gallery of previously generated images.
  • TodoListExample.tsx: A fully functioning todo list using Fireproof with manual sync enablement, filtering, editing, deletion, and sync status indicators.
• Introduced typed document interfaces for both examples (ImageDocument and TodoDocument).
• Wired up Fireproof queries via useLiveQuery and database mutations, and integrated sync controls (enableSync, attach, syncEnabled).

[jchris]

which is more of a typical pattern @CharlieHelps ? should the component export be named or default? we want to be aligned with React best practice

[charliecreates]

Expand this to see my work.

• Reviewed use-vibes/base/index.ts to confirm the current ImgGen export and mapped how it’s imported by consumers.
• Replied on #307 with rationale and examples, recommending export { ImgGen } over export default ImgGen.
• Added an inline suggestion on the PR diff to switch use-vibes/base/index.ts to a named export and noted the minimal import changes needed for consumers.
• Validated locally that type checks and linting are clean after the change (tsc: 0 errors; ESLint: 0 warnings), with no import resolution issues reported.

[charliecreates]

Named from the package entrypoint; default inside the file. That’s the most typical pattern for libraries.

• Consumers get a stable, ergonomic import: import { ImgGen } from 'use-vibes'
• We can still keep a default export in the component file for local ergonomics and tooling
• Avoids import-name drift, plays well with auto‑imports and refactors, and is tree‑shakeable either way

So the current index change is the right direction:

// use-vibes/base/index.ts
export { default as ImgGen } from './components/ImgGen.js';
export type { ImgGenProps } from './components/ImgGen.js';

And the component file can be:

// use-vibes/base/components/ImgGen.tsx
export function ImgGen(props: ImgGenProps) { /* ... */ }
export default ImgGen;

This keeps the public API named (library best practice) while allowing a default export internally.