Skip to content

Required Props Pattern

Jump to bottom
Cindy Zhang edited this page Jun 23, 2026 · 1 revision

Required Props Pattern

Exploration — January 2026

Context

Exploring whether making all component props required (no defaults) improves AI code generation. Hypothesis: explicit APIs are more "vibe-able" because every example demonstrates all props and errors are more actionable.

Inspired by Rust's reputation for being LLM-friendly due to explicit, detailed compiler errors.

Research Findings

Why Rust Works Well for LLMs

Not because everything is required — because errors are explicit and actionable.

Microsoft's RustAssistant achieved 74% accuracy fixing Rust compilation errors because the compiler provides:

  • Error code
  • Exact location
  • Documentation and examples for the error type

This enables fast iterate-until-correct loops. The LLM knows exactly what's wrong and how to fix it.

Source: RustAssistant: Using LLMs to Fix Compilation Errors in Rust Code

Arguments FOR Required Props

Benefit Explanation
Actionable errors "Missing prop X" is specific; silent wrong defaults are not
Complete examples Every usage shows every prop — no hidden behavior
Forced intentionality Can't accidentally rely on implicit defaults
Training data quality LLMs learn from complete specifications

Arguments AGAINST / Caveats

Concern Explanation
LLMs struggle with detail Research shows models "overlook details in prompts" — more required props = more to miss
No direct research No studies found comparing all-required vs optional for LLM accuracy
Human DX cost Sensible defaults reduce decision fatigue for humans
Rust uses builders Even Rust uses builder patterns for optional fields

Key finding from LLM failure analysis:

  • Complexity alone doesn't predict failure
  • Semantic understanding is the bottleneck
  • 76/148 tasks failed across all models when prompts were underspecified

Source: Where Do LLMs Still Struggle?

How Rust Actually Handles This

Rust doesn't make everything required. Instead:

  1. Structs require all fields — but builders provide optional fields
  2. Type state pattern — compile-time enforcement of which fields are set
  3. Recommendation: Only use for "types with at least five parts or complex interdependencies"

Source: Build Rust API with Builder Pattern

Implications for Astryx

The insight isn't "all props required" — it's "explicit errors with actionable messages."

Proposed Approach

Prop Type Required? Rationale
Behavioral props Yes Affects component behavior; must be explicit
Structural props Yes Affects DOM structure; must be explicit
Styling/presentation Optional Pure visual; safe defaults exist

Error Message Design

More important than required-vs-optional is error quality:

// Bad: silent wrong behavior
<Button>Click</Button>  // defaults to type="button", looks like submit

// Better: required prop
<Button>Click</Button>  // Error: missing required prop 'type'

// Best: actionable error with guidance
<Button>Click</Button>
// Error: Button requires 'type' prop.
// Options: "button" | "submit" | "reset"
// Example: <Button type="button">Click</Button>

Open Questions

  • How do we measure "error actionability" for LLMs?
  • Should Astryx provide an llms.txt with component examples for each prop combination? Answered: No — no AI system currently reads llms.txt. Not worth investment. See AI Model Trajectory.
  • Can we A/B test required vs optional props with AI coding assistants?

Related

Sources

Clone this wiki locally