create-foldkit-app 0.7.1 → 0.7.2

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 CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "create-foldkit-app",
3
- "version": "0.7.1",
3
+ "version": "0.7.2",
4
4
  "description": "Create Foldkit applications",
5
5
  "type": "module",
6
6
  "main": "./dist/index.js",
@@ -49,13 +49,23 @@ Don't add type annotations to `evo` callbacks when the type can be inferred.
49
49
 
50
50
  ### View
51
51
 
52
- Call `html<Message>()` once in a dedicated `html.ts` file and import the destructured helpers everywhere else:
52
+ Bind the `html` factory once per module by calling `html<Message>()`, then reach for `h.div`, `h.OnClick`, and the rest off the returned record. Each view module binds its own `h` against the Message type it dispatches:
53
53
 
54
54
  ```ts
55
- // html.ts
56
- export const { div, button, span, Class, OnClick } = html<Message>()
55
+ const h = html<Message>()
56
+
57
+ export const view = (model: Model): Html =>
58
+ h.div(
59
+ [h.Class('flex flex-col gap-2')],
60
+ [
61
+ h.h1([], [`Hello, ${model.name}`]),
62
+ h.button([h.OnClick(ClickedRefresh())], ['Refresh']),
63
+ ],
64
+ )
57
65
  ```
58
66
 
67
+ For child views that should be agnostic to their parent, take `ParentMessage` as a function generic and bind `html<ParentMessage>()` inside. The view stays decoupled from any particular parent and composes through the `toParentMessage` callback the parent supplies.
68
+
59
69
  Use `empty` (not `null`) for conditional rendering. Use `M.value().pipe(M.tagsExhaustive({...}))` for rendering discriminated unions and `Array.match` for rendering lists that may be empty.
60
70
 
61
71
  Use `keyed` wrappers whenever the view branches into structurally different layouts based on route or model state. Without keying, the virtual DOM will try to diff one layout into another (e.g. a full-width landing page into a sidebar docs layout), which causes stale DOM, mismatched event handlers, and subtle rendering bugs. Key the outermost container of each layout branch with a stable string (e.g. `keyed('div')('landing', ...)` vs `keyed('div')('docs', ...)`). Within a single layout, key the content area on the route tag (e.g. `keyed('div')(model.route._tag, ...)`) so page transitions replace rather than patch.