@yuneta/gobj-ui 6.3.1 → 6.3.2

package/README.md

@@ -529,9 +529,13 @@ Two implementation notes worth keeping:
 
 A landing view that draws a treedb the way its schema literal draws it in ASCII
 (`treedb_schema_*.c`, `treedb_system_schema.c`): **one card per topic**,
-listing its fields in schema order, and **one edge per hook**, leaving the row
-that declares the hook and landing on the fkey row of the child it names. Built
-from the schema `descs` **alone**: no data, no backend calls. It is the "every
+listing its fields in schema order, and **one edge per hook**, between the row
+that declares the hook and the fkey row of the child it names. The **arrowhead
+is on the hook**, the way the `.c` draws it and the way the `↖` of the fkey
+mark reads: the reference is held by the child and points at its parent. The
+edge itself is declared parent → child, which is what ranks the parent to the
+left, first, as the literal lists it. Built from the schema `descs` **alone**:
+no data, no backend calls. It is the "every
 treedb is a graph" rule applied to the schema itself, and an alternate landing
 to the topic cards. A node click opens that topic's table through a real hash
 navigation, so the graph is a navigation surface rather than a picture.

package/dist/gobj-ui.cjs.js

@@ -19796,9 +19796,11 @@ function register_c_yui_treedb_graph() {
 *      Schema-graph landing: the treedb drawn the way its `.c` literal
 *      draws it in ASCII (treedb_schema_*.c, treedb_system_schema.c) —
 *      one CARD per topic listing its fields in schema order, one edge
-*      per hook, from the row that declares the hook to the fkey row of
-*      the child it names. Built from the schema `descs` alone: no data,
-*      no backend calls.
+*      per hook, between the row that declares the hook and the fkey row
+*      of the child it names — arrowhead on the HOOK, as the `.c` draws
+*      it and as the `↖` of the fkey mark says: the reference is the
+*      child's and it points at its parent. Built from the schema
+*      `descs` alone: no data, no backend calls.
 *
 *      WHY THE CARD AND NOT A DOT. A topic is its fields; a schema is
 *      read to find out what a topic holds and what links to what. A
@@ -20058,14 +20060,17 @@ ${rows_html}    </div>
 *   Derive {nodes, edges} from the schema.
 *
 *   Node = a topic, drawn as the card the `.c` literal draws in
-*   ASCII: its name and its fields. Edge = a hook, from the row
-*   that declares it to the fkey row of the child it names —
-*   `'hook': {'users': 'departments'}` says both ends, so the
-*   arrow can land where the `.c` drawing lands it. An fkey
-*   whose parent declares no hook still gets its edge, or a
+*   ASCII: its name and its fields. Edge = a hook, between the
+*   row that declares it and the fkey row of the child it names
+*   — `'hook': {'users': 'departments'}` says both ends, so the
+*   edge can land on the rows the `.c` drawing lands it on. An
+*   fkey whose parent declares no hook still gets its edge, or a
 *   half-declared schema would draw as disconnected.
 *
-*   Left-to-right dagre follows the parent -> child data flow.
+*   An edge is declared parent -> child so left-to-right dagre
+*   ranks the parent first, the order the `.c` literal lists
+*   them in. The ARROWHEAD is the other way (see edge_style):
+*   the fkey points at the hook, never the hook at the fkey.
 ************************************************************/
 function schema_to_graph(gobj) {
 	let descs = (0, _yuneta_gobj_js.gobj_read_attr)(gobj, "descs");
@@ -20165,12 +20170,20 @@ function schema_to_graph(gobj) {
 *   the graph is built and re-applied on a theme switch
 *   (ac_theme), which restyles the LIVE graph — rebuilding it
 *   would drop the user's zoom/pan and any dragged node.
+*
+*   The arrowhead is at the START of the edge, on the parent's
+*   hook — the direction the `.c` literals draw and the `↖` of
+*   the fkey mark names: the reference is held by the CHILD and
+*   points at its parent. The edge is still declared parent ->
+*   child, which is what ranks the parent to the left; only the
+*   marker says who points at whom.
 ************************************************************/
 function edge_style(dark) {
 	return {
 		stroke: dark ? "#7a8593" : "#9aa4b2",
 		lineWidth: 1.2,
-		endArrow: true
+		startArrow: true,
+		endArrow: false
 	};
 }
 /************************************************************

package/dist/gobj-ui.es.js

@@ -19783,9 +19783,11 @@ function register_c_yui_treedb_graph() {
 *      Schema-graph landing: the treedb drawn the way its `.c` literal
 *      draws it in ASCII (treedb_schema_*.c, treedb_system_schema.c) —
 *      one CARD per topic listing its fields in schema order, one edge
-*      per hook, from the row that declares the hook to the fkey row of
-*      the child it names. Built from the schema `descs` alone: no data,
-*      no backend calls.
+*      per hook, between the row that declares the hook and the fkey row
+*      of the child it names — arrowhead on the HOOK, as the `.c` draws
+*      it and as the `↖` of the fkey mark says: the reference is the
+*      child's and it points at its parent. Built from the schema
+*      `descs` alone: no data, no backend calls.
 *
 *      WHY THE CARD AND NOT A DOT. A topic is its fields; a schema is
 *      read to find out what a topic holds and what links to what. A
@@ -20045,14 +20047,17 @@ ${rows_html}    </div>
 *   Derive {nodes, edges} from the schema.
 *
 *   Node = a topic, drawn as the card the `.c` literal draws in
-*   ASCII: its name and its fields. Edge = a hook, from the row
-*   that declares it to the fkey row of the child it names —
-*   `'hook': {'users': 'departments'}` says both ends, so the
-*   arrow can land where the `.c` drawing lands it. An fkey
-*   whose parent declares no hook still gets its edge, or a
+*   ASCII: its name and its fields. Edge = a hook, between the
+*   row that declares it and the fkey row of the child it names
+*   — `'hook': {'users': 'departments'}` says both ends, so the
+*   edge can land on the rows the `.c` drawing lands it on. An
+*   fkey whose parent declares no hook still gets its edge, or a
 *   half-declared schema would draw as disconnected.
 *
-*   Left-to-right dagre follows the parent -> child data flow.
+*   An edge is declared parent -> child so left-to-right dagre
+*   ranks the parent first, the order the `.c` literal lists
+*   them in. The ARROWHEAD is the other way (see edge_style):
+*   the fkey points at the hook, never the hook at the fkey.
 ************************************************************/
 function schema_to_graph(gobj) {
 	let descs = gobj_read_attr(gobj, "descs");
@@ -20152,12 +20157,20 @@ function schema_to_graph(gobj) {
 *   the graph is built and re-applied on a theme switch
 *   (ac_theme), which restyles the LIVE graph — rebuilding it
 *   would drop the user's zoom/pan and any dragged node.
+*
+*   The arrowhead is at the START of the edge, on the parent's
+*   hook — the direction the `.c` literals draw and the `↖` of
+*   the fkey mark names: the reference is held by the CHILD and
+*   points at its parent. The edge is still declared parent ->
+*   child, which is what ranks the parent to the left; only the
+*   marker says who points at whom.
 ************************************************************/
 function edge_style(dark) {
 	return {
 		stroke: dark ? "#7a8593" : "#9aa4b2",
 		lineWidth: 1.2,
-		endArrow: true
+		startArrow: true,
+		endArrow: false
 	};
 }
 /************************************************************

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yuneta/gobj-ui",
-  "version": "6.3.1",
+  "version": "6.3.2",
   "type": "module",
   "main": "dist/gobj-ui.cjs.js",
   "module": "dist/gobj-ui.es.js",

package/src/c_yui_treedb_schema.js

@@ -4,9 +4,11 @@
  *      Schema-graph landing: the treedb drawn the way its `.c` literal
  *      draws it in ASCII (treedb_schema_*.c, treedb_system_schema.c) —
  *      one CARD per topic listing its fields in schema order, one edge
- *      per hook, from the row that declares the hook to the fkey row of
- *      the child it names. Built from the schema `descs` alone: no data,
- *      no backend calls.
+ *      per hook, between the row that declares the hook and the fkey row
+ *      of the child it names — arrowhead on the HOOK, as the `.c` draws
+ *      it and as the `↖` of the fkey mark says: the reference is the
+ *      child's and it points at its parent. Built from the schema
+ *      `descs` alone: no data, no backend calls.
  *
  *      WHY THE CARD AND NOT A DOT. A topic is its fields; a schema is
  *      read to find out what a topic holds and what links to what. A
@@ -380,14 +382,17 @@ ${rows_html}    </div>
  *   Derive {nodes, edges} from the schema.
  *
  *   Node = a topic, drawn as the card the `.c` literal draws in
- *   ASCII: its name and its fields. Edge = a hook, from the row
- *   that declares it to the fkey row of the child it names —
- *   `'hook': {'users': 'departments'}` says both ends, so the
- *   arrow can land where the `.c` drawing lands it. An fkey
- *   whose parent declares no hook still gets its edge, or a
+ *   ASCII: its name and its fields. Edge = a hook, between the
+ *   row that declares it and the fkey row of the child it names
+ *   — `'hook': {'users': 'departments'}` says both ends, so the
+ *   edge can land on the rows the `.c` drawing lands it on. An
+ *   fkey whose parent declares no hook still gets its edge, or a
  *   half-declared schema would draw as disconnected.
  *
- *   Left-to-right dagre follows the parent -> child data flow.
+ *   An edge is declared parent -> child so left-to-right dagre
+ *   ranks the parent first, the order the `.c` literal lists
+ *   them in. The ARROWHEAD is the other way (see edge_style):
+ *   the fkey points at the hook, never the hook at the fkey.
  ************************************************************/
 function schema_to_graph(gobj)
 {
@@ -509,13 +514,21 @@ function schema_to_graph(gobj)
  *   the graph is built and re-applied on a theme switch
  *   (ac_theme), which restyles the LIVE graph — rebuilding it
  *   would drop the user's zoom/pan and any dragged node.
+ *
+ *   The arrowhead is at the START of the edge, on the parent's
+ *   hook — the direction the `.c` literals draw and the `↖` of
+ *   the fkey mark names: the reference is held by the CHILD and
+ *   points at its parent. The edge is still declared parent ->
+ *   child, which is what ranks the parent to the left; only the
+ *   marker says who points at whom.
  ************************************************************/
 function edge_style(dark)
 {
     return {
         stroke:   dark ? "#7a8593" : "#9aa4b2",
         lineWidth: 1.2,
-        endArrow: true,
+        startArrow: true,
+        endArrow:   false,
     };
 }