glm-5.1
0d5b9d5ea8
Critical fixes: - Restructure pointers.md: move setNode prop-key writes section under its own heading (was incorrectly nested under selectNode) - Add Context/Density/Direction/RenderContext documentation section to host-config.md (was only a brief constraint bullet) - Advance all 5 ADRs from Status: Proposed → Accepted and frontmatter from status: draft → status: stable (decisions are driving implementation) - Add error handling philosophy section to README Warning/suggestion fixes: - Add isUElement null check (node !== null) to schema.md discriminator table - Add UjsxEnvelope convenience type documentation to events.md - Add Direction Unicode arrow naming note to transforms.md - Standardize all cross-references from absolute docs/research/ paths to relative ../research/ paths across all architecture docs - Fix schema.md ADR references to use relative paths - Reduce redundancy between transforms.md and host-config.md Direction notes - Update all architecture doc frontmatter from draft → stable Deferred: - Performance model section (reconciler not yet built) - Concepts/glossary document (low ROI at current scale) - Line counts in source references (would date quickly)
1.5 KiB
1.5 KiB
status, last_updated
| status | last_updated |
|---|---|
| stable | 2026-05-18 |
ADR-001: HTML-agnostic core
Status: Accepted
Context
UJSX is a universal JSX IR that treats JSX as an intermediate representation. The core types (UNode, UElement, UniversalProps) are deliberately free of any platform-specific concepts.
Alternatives Considered
- HTML-compatible props (className, onClick, etc.): Include DOM/HTML-specific prop names in core types. Rejected because it biases toward DOM rendering and forces non-DOM hosts to filter/translate irrelevant props.
- Separate "web" prop types: Create a parallel type hierarchy for web/DOM props alongside the universal core. Rejected because it creates two type hierarchies and increases complexity for hosts that don't need HTML.
Decision
UJSX core does NOT include HTML/DOM-specific concepts. No onClick, no className, no style, no aria-*. UniversalProps accepts any key-value pairs because different hosts need different prop shapes. The host decides what props mean.
Consequences
Positive
- Clean separation. Each host defines its own prop semantics. Flowgraph hosts use
{ name, type, url }not{ className, id }. - TypeBox schemas for host-specific props can validate independently. No "stripping" step needed.
Negative
- Consumers targeting HTML must map their own props (e.g.,
class→className). This is the host's responsibility. - No built-in event handling system — events are host-specific. The event system (
PubSubLike,EventEnvelope) is generic.