uniweb 0.14.2 → 0.14.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 CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "uniweb",
3
- "version": "0.14.2",
3
+ "version": "0.14.3",
4
4
  "description": "Create structured Vite + React sites with content/code separation",
5
5
  "type": "module",
6
6
  "bin": {
@@ -42,11 +42,11 @@
42
42
  "prompts": "^2.4.2",
43
43
  "tar": "^7.0.0",
44
44
  "@uniweb/core": "0.8.0",
45
- "@uniweb/runtime": "0.9.0",
46
- "@uniweb/kit": "0.10.2"
45
+ "@uniweb/kit": "0.10.3",
46
+ "@uniweb/runtime": "0.9.0"
47
47
  },
48
48
  "peerDependencies": {
49
- "@uniweb/build": "0.16.0",
49
+ "@uniweb/build": "0.16.1",
50
50
  "@uniweb/content-reader": "1.2.0",
51
51
  "@uniweb/semantic-parser": "1.2.0"
52
52
  },
@@ -338,7 +338,9 @@ content = {
338
338
  lists: [], // [[{ paragraphs, links, lists, … }]] — each item is an object, not a string
339
339
  quotes: [], // Blockquotes
340
340
  snippets: [], // Fenced code — [{ language, code }]
341
- data: {}, // From tagged data blocks (```yaml:tagname, ```json:tagname)
341
+ data: {}, // Tagged blocks ```yaml:tag / ```json:tag give the parsed value,
342
+ // ```md:tag gives { items, sequence } (see Concept blocks)
343
+ tables: [], // Only when present — [{ rows: [{ cells: [{ children, header, align }] }] }]
342
344
  headings: [], // Headings after subtitle, in document order
343
345
  items: [], // Each has the same flat structure — from headings after body content
344
346
  sequence: [], // All elements in document order
@@ -503,7 +505,7 @@ Sites can adjust these or add named styles in `theme.yml`'s `inline:` section. O
503
505
 
504
506
  ### Fenced code: data blocks vs snippets
505
507
 
506
- Fenced code serves two purposes depending on whether it carries a tag.
508
+ Fenced code serves three purposes depending on its info string: `yaml:`/`json:` for data, `md:` for a named kind of prose (see *Concept blocks*), and a bare language for a code sample.
507
509
 
508
510
  **Tagged data blocks** — structured data parsed into JS objects. The tag is the key in `content.data`; the format (`yaml`/`yml`/`json`) is a serialization format, not a display language.
509
511
 
@@ -1334,12 +1336,58 @@ Pages are sequences of sections — the obvious layer. The framework also suppor
1334
1336
  | Pattern | How authored | Use when |
1335
1337
  |---|---|---|
1336
1338
  | **Items** (`content.items`) | Heading groups within one `.md` | Repeating content in one section: cards, features, FAQ entries |
1339
+ | **Concept blocks** (`content.data[tag]`) | ` ```md:<tag> ` fence around markdown | A named *kind* of content — an FAQ, a callout, a set of steps |
1337
1340
  | **Child sections** (`block.childBlocks`) | `@`-prefixed `.md` files + `nest:` | Children needing their own section type, rich content, or independent editing |
1338
1341
  | **Insets** (`block.insets`) | `![](@Component)` in markdown | Self-contained visuals/widgets: charts, diagrams, code demos |
1339
1342
  | **Block insets** (`block.insets`) | ` ```@Component ` fence around markdown | A component that *wraps* authored prose: callouts, disclosures, admonitions |
1340
1343
 
1341
1344
  Does the author write content *inside* the nested element? **Yes** → child sections, or a block inset when the wrapper is presentational and lives mid-page. **No** (self-contained, param-driven) → inset. Repeating same-structure groups → items. These compose: a child section can contain insets; items work inside children; a block inset can contain both.
1342
1345
 
1346
+ ### Concept blocks — naming *what* content is
1347
+
1348
+ A ` ```md:<tag> ` fence marks a run of prose as a named kind of thing. The author writes ordinary markdown; the tag says what it is:
1349
+
1350
+ ````markdown
1351
+ ```md:faq
1352
+ # What plans do you have?
1353
+ Three — Starter, Team and Enterprise.
1354
+
1355
+ # Can I change later?
1356
+ Any time, and we prorate the difference.
1357
+ ```
1358
+ ````
1359
+
1360
+ Every `#` heading starts an item, so this arrives as `content.data.faq`:
1361
+
1362
+ ```js
1363
+ {
1364
+ items: [ { title, paragraphs, links, … }, … ], // one per heading
1365
+ sequence: [ … ] // the same content, in document order
1366
+ }
1367
+ ```
1368
+
1369
+ **The shape is fixed by the fence, not by the tag.** Any tag works and none is special — the framework never learns what `faq` means. A body with **no** headings is the same block with a single titleless item, which is what a callout is:
1370
+
1371
+ ````markdown
1372
+ ```md:warning
1373
+ Back up your database **before** running this. It is not reversible.
1374
+ ```
1375
+ ````
1376
+
1377
+ **Why this instead of a component reference.** ` ```@Alert ` names *which component renders this*, which is a rendering decision sitting in content. `md:warning` names *what the content is* and leaves rendering to the foundation — so the same content works under a different foundation, and an editor can recognize the concept and offer a surface built for it.
1378
+
1379
+ **Reading one in a component.** `content.data[tag]` gives you both views: `items` for anything row-shaped (an accordion, a step list), `sequence` when you don't recognize the tag and want to render it faithfully in document order. Both are derived, so nothing is stored twice.
1380
+
1381
+ ```jsx
1382
+ function Faq({ content }) {
1383
+ const faq = content.data?.faq
1384
+ if (!faq) return null
1385
+ return faq.items.map((item, i) => <Disclosure key={i} q={item.title} a={item.paragraphs} />)
1386
+ }
1387
+ ```
1388
+
1389
+ **Two tags, not a tag plus a variant.** A warning and a note are different concepts, so they are `md:warning` and `md:note`. The fence takes no params.
1390
+
1343
1391
  **Insets — embedding components in content.** Many section types need a "visual" — a hero's illustration, a split-content section's media. Classically an image or video. But what if it's a JSX + SVG diagram, a ThreeJS animation, an interactive playground? Elsewhere you'd reach for MDX or prop-drilling. Here the author writes standard image syntax:
1344
1392
 
1345
1393
  ```markdown
@@ -1,9 +1,9 @@
1
1
  {
2
2
  "schemaVersion": 1,
3
- "generatedAt": "2026-07-30T22:09:40.317Z",
3
+ "generatedAt": "2026-07-30T22:59:53.314Z",
4
4
  "packages": {
5
5
  "@uniweb/build": {
6
- "version": "0.16.0",
6
+ "version": "0.16.1",
7
7
  "path": "framework/build",
8
8
  "deps": [
9
9
  "@uniweb/content-reader",
@@ -22,7 +22,7 @@
22
22
  "deps": []
23
23
  },
24
24
  "@uniweb/content-writer": {
25
- "version": "0.3.0",
25
+ "version": "0.3.1",
26
26
  "path": "framework/content-writer",
27
27
  "deps": []
28
28
  },
@@ -45,7 +45,7 @@
45
45
  "deps": []
46
46
  },
47
47
  "@uniweb/kit": {
48
- "version": "0.10.2",
48
+ "version": "0.10.3",
49
49
  "path": "framework/kit",
50
50
  "deps": [
51
51
  "@uniweb/core",
@@ -64,7 +64,7 @@
64
64
  "deps": []
65
65
  },
66
66
  "@uniweb/projections": {
67
- "version": "0.2.0",
67
+ "version": "0.2.1",
68
68
  "path": "framework/projections",
69
69
  "deps": [
70
70
  "@uniweb/content-writer",
@@ -100,7 +100,7 @@
100
100
  "deps": []
101
101
  },
102
102
  "@uniweb/templates": {
103
- "version": "0.7.46",
103
+ "version": "0.8.0",
104
104
  "path": "framework/templates",
105
105
  "deps": []
106
106
  },