create-foldkit-app 0.6.1 → 0.6.3
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.
- package/package.json +1 -1
- package/templates/base/AGENTS.md +33 -0
package/package.json
CHANGED
package/templates/base/AGENTS.md
CHANGED
|
@@ -87,6 +87,33 @@ Commands catch all errors and return Messages — side effects never crash the a
|
|
|
87
87
|
|
|
88
88
|
Command definitions live where they're produced — colocated with the update function that returns them. Don't centralize all definitions in one file.
|
|
89
89
|
|
|
90
|
+
### Mount
|
|
91
|
+
|
|
92
|
+
For per-element DOM work — focusing an input, handing the live `Element` to a third-party library — define a Mount with `Mount.define` and attach it to a view element with `OnMount`. The runtime runs the Effect when the element mounts, dispatches its result Message back through `update`, and runs the paired cleanup on unmount.
|
|
93
|
+
|
|
94
|
+
```ts
|
|
95
|
+
const CompletedFocusInput = m('CompletedFocusInput')
|
|
96
|
+
|
|
97
|
+
const FocusInput = Mount.define('FocusInput', CompletedFocusInput)
|
|
98
|
+
|
|
99
|
+
const focusInput = FocusInput(element =>
|
|
100
|
+
Effect.sync(() => {
|
|
101
|
+
if (element instanceof HTMLInputElement) {
|
|
102
|
+
element.focus()
|
|
103
|
+
}
|
|
104
|
+
return {
|
|
105
|
+
message: CompletedFocusInput(),
|
|
106
|
+
cleanup: Function.constVoid,
|
|
107
|
+
}
|
|
108
|
+
}),
|
|
109
|
+
)
|
|
110
|
+
|
|
111
|
+
// In view:
|
|
112
|
+
input([Type('search'), OnMount(focusInput)])
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
Cleanup is data, paired with setup as a single value. For setup with no cleanup, pass `Function.constVoid`. The `Completed*` Message marks the lifecycle without forcing a meaningful response in update.
|
|
116
|
+
|
|
90
117
|
### File Organization
|
|
91
118
|
|
|
92
119
|
Use uppercase section headers (`// MODEL`, `// MESSAGE`, `// INIT`, `// UPDATE`, `// COMMAND`, `// VIEW`) to make files easier to skim. These are for wayfinding — they make it clear where things live and where new code should go. Use domain-specific headers too when it helps (e.g. `// PHYSICS`, `// ROUTING`).
|
|
@@ -101,6 +128,12 @@ Use `Story.story` to chain steps into a readable narrative: set initial Model
|
|
|
101
128
|
|
|
102
129
|
If the `repos/foldkit` submodule is available, study the `.test.ts` files in `repos/foldkit/examples/` for patterns — they cover simple Command resolution, multi-step interactions, and Submodel OutMessage assertions.
|
|
103
130
|
|
|
131
|
+
## Debugging with Foldkit DevTools
|
|
132
|
+
|
|
133
|
+
This project ships with `@foldkit/devtools-mcp` pre-wired. When the dev server is running and the app is open in a browser tab, `foldkit_*` MCP tools are available for inspecting Model, Message history, and time-travel. Reach for them before adding `console.log` whenever the question is about state or Message flow.
|
|
134
|
+
|
|
135
|
+
If the `foldkit_*` tools aren't visible, see `@foldkit/devtools-mcp` on npm for setup.
|
|
136
|
+
|
|
104
137
|
## Code Quality Standards
|
|
105
138
|
|
|
106
139
|
- Every name should eliminate ambiguity. Prefix Option-typed values with `maybe` (e.g. `maybeSession`). Name functions by their precise effect (e.g. `enqueueMessage` not `addMessage`). A reader should never need to check a type signature to understand what a name refers to.
|