@vibes.diy/prompts 14.3.113 → 14.3.114

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (2) hide show
  1. package/llms/fireproof.md +23 -1
  2. package/package.json +5 -5
package/llms/fireproof.md CHANGED
@@ -23,7 +23,7 @@ Use granular documents, e.g. one document per user action, so saving a form or c
23
23
 
24
24
  `useLiveQuery` populates and refreshes the UI reactively as data arrives, so you usually render empty states rather than loading spinners. Writes are optimistic and local: `put()`/`save()`/`del()` land in the local replica instantly, and transport or offline failures queue and retry automatically. If the server's access rules reject a synced write, the local optimistic revision converges **server-wins** (it is overwritten by the server's version) — and the **platform** surfaces the reason in a write-fail toast whenever there is one: the app's own `forbidden("…")` text, or the platform's message when a signed-in visitor has no write access to the app (both also reach the app as `writeRejection`, below); a reason-less rejection converges silently. So do **not** wrap plain writes in `try/catch` to show denial errors to the user (a save carrying `_files` is the one exception, covered with the image uploader below); keep the UI reactive to the store (`useLiveQuery`/`useDocument`) so the converged state is the feedback, and gate write surfaces up front with `useVibe(dbName).can.create/edit/delete` so a disallowed action never renders in the first place.
25
25
 
26
- When the server later refuses a write the visitor can act on — a signed-in visitor saving to a private app, say — the platform shows a notice and `useFireproof` hands the app the same reason as `writeRejection` (`{ docId, message }`, or `null` until a save is refused). Render `writeRejection.message` beside the form it came from and call `clearWriteRejection()` when the visitor dismisses it:
26
+ When the server later refuses a write the visitor can act on — a signed-in visitor saving to a private app, say — the platform shows a notice and `useFireproof` hands the app the same reason as `writeRejection` (`{ docId, message, code }`, or `null` until a save is refused). Render `writeRejection.message` beside the form it came from and call `clearWriteRejection()` when the visitor dismisses it:
27
27
 
28
28
  ```jsx
29
29
  function NoteForm({ text }) {
@@ -44,6 +44,28 @@ function NoteForm({ text }) {
44
44
  }
45
45
  ```
46
46
 
47
+ While the app's first build is still finishing, the preview runs on its example records, and saving opens up the moment the build completes. A save in that window comes back as a `writeRejection` with `code: "draft-read-only"` and a friendly ready-made `message`. Treat it as a calm status line: the same quiet `role="status"` note as above (or nothing at all), with the visitor's typed text and selections kept in component state so the next save carries them. The platform clears this `writeRejection` itself the moment saving opens up (and on the next save that lands), so the note goes away on its own:
48
+
49
+ ```jsx
50
+ function AddItem() {
51
+ const { database, writeRejection } = useFireproof("items");
52
+ const [text, setText] = useState("");
53
+ async function add() {
54
+ const res = await database.put({ type: "item", text });
55
+ if (res.ok) setText(""); // clear the field once the record is saved
56
+ }
57
+ return (
58
+ <Stack gap={2}>
59
+ <Field label="Item">{(id, describedBy) => <Input id={id} describedBy={describedBy} value={text} onChange={setText} />}</Field>
60
+ <Row>
61
+ <Button type="button" onClick={add}>Add</Button>
62
+ </Row>
63
+ {writeRejection?.code === "draft-read-only" && <p role="status">{writeRejection.message}</p>}
64
+ </Stack>
65
+ );
66
+ }
67
+ ```
68
+
47
69
  ### Basic Example
48
70
 
49
71
  When the composer is on screen, wire these visible actions in the same build, using the app's own record names. One composer has Add and Ask actions. Add extracts and normalizes facts, saves each record immediately, and shows saved records with edit actions; one item and a pasted batch share this action. Each saved row has Change by sentence: selecting it changes Add to Apply correction, which saves onto that same record id. Ask sends the typed question with the relevant saved records and displays a read-only answer beside the composer. Edit opens the selected row’s populated fields. One parent-owned Undo restores the latest successful creation batch or the previous document from either a sentence correction or a field edit.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@vibes.diy/prompts",
3
- "version": "14.3.113",
3
+ "version": "14.3.114",
4
4
  "type": "module",
5
5
  "main": "./index.js",
6
6
  "exports": {
@@ -39,10 +39,10 @@
39
39
  "license": "Apache-2.0",
40
40
  "dependencies": {
41
41
  "@adviser/cement": "~0.5.34",
42
- "@vibes.diy/api-types": "14.3.113",
43
- "@vibes.diy/call-ai-v2": "14.3.113",
44
- "@vibes.diy/identity": "14.3.113",
45
- "@vibes.diy/use-vibes-types": "14.3.113",
42
+ "@vibes.diy/api-types": "14.3.114",
43
+ "@vibes.diy/call-ai-v2": "14.3.114",
44
+ "@vibes.diy/identity": "14.3.114",
45
+ "@vibes.diy/use-vibes-types": "14.3.114",
46
46
  "arktype": "~2.2.6",
47
47
  "json-schema-faker": "~0.6.3"
48
48
  },