Skip to content

[IMPROVEMENT] Refactor to web components for better encapsulation and reus... #21

Description

@devwif

[IMPROVEMENT] Refactor Core UI Components to Web Components for Superior Encapsulation and Reusability


🚀 Problem Statement

The current UI components in the WebTUI library are implemented in a way that limits encapsulation, reusability, and framework-agnostic compatibility. This hampers developer experience, slows adoption across diverse JavaScript frameworks, and introduces maintenance complexity.

By refactoring these components into standards-based Web Components, we will achieve:

  • True encapsulation (shadow DOM, scoped styles)
  • Framework interoperability (React, Vue, Svelte, Angular)
  • Easier incremental adoption and extension
  • Better long-term maintainability and code clarity

This improvement is high ROI and aligns tightly with the AI Development Plan Milestone #1, laying the foundation for a modern, modular, and extensible terminal-like UI library.


🧠 Technical Context

  • Current State: Components are implemented in Astro with scoped CSS but lack full encapsulation and are tightly coupled to Astro’s rendering lifecycle.
  • Target: Native Web Components leveraging:
    • Custom Elements API
    • Shadow DOM for style and markup encapsulation
    • Lifecycle callbacks (connectedCallback, attributeChangedCallback)
    • Slots for flexible composition
  • Ecosystem: The repo uses TypeScript and biomejs tooling, which supports modern web standards. Dev dependencies include turbo and linting/formatting tools that should be integrated into the new workflow.
  • Challenges: Maintaining backward compatibility for existing Astro consumers while enabling framework-agnostic usage.

🛠 Detailed Implementation Plan

1. Analyze Current Components and Usage

  • Inventory all UI components (buttons, inputs, dialogs, tooltips, etc.).
  • Identify those with:
    • Shared styles or duplicated logic
    • Direct Astro-specific dependencies or templates
  • Document current rendering patterns, event handling, and props/state management.

2. Define Web Component Architecture & Patterns

  • Decide base class structure (e.g., extending HTMLElement or LitElement if allowed).
  • Establish naming conventions for custom elements (<webtui-button>, <webtui-dialog>, etc.).
  • Define slot usage strategies for content projection.
  • Plan style encapsulation (CSS Variables, Shadow DOM style sheets).
  • Determine attribute/property reflection strategies for reactive updates.

3. Incremental Refactor Implementation

  • Start with one foundational component (e.g., <webtui-button>):
    • Implement as a Web Component in TypeScript
    • Migrate styles into shadow DOM
    • Provide clear APIs for props/events
    • Write usage examples in Astro and vanilla HTML
  • Validate backward compatibility by supporting previous Astro usage or providing migration guides.
  • Repeat for subsequent components, building a reusable base class or utility functions as necessary.

4. Testing and Validation

  • Develop unit tests for each web component using a framework like Jest + @web/test-runner or similar.
  • Create integration tests in Astro environment to ensure seamless usage.
  • Benchmark performance impact before/after refactor.
  • Validate accessibility compliance (focus management, ARIA attributes).

5. Documentation & Examples

  • Update component docs with:
    • Web Component API specs
    • Usage examples across multiple frameworks (Astro, React, vanilla)
    • Migration guides for existing users
  • Enhance README with a new “Using Web Components” section.
  • Possibly add Storybook or a live playground demo.

⚙️ Technical Specifications

Specification Details
Web Standards Use Custom Elements v1, Shadow DOM v1, ES Modules
TypeScript Strict typing, interfaces for props/events
Styling Scoped styles inside shadow DOM, CSS Custom Properties for theming
Events Use CustomEvent for component events with proper bubbling and composition
Attributes/Props Reflect observed attributes to properties, use attributeChangedCallback for sync
Slots Named and default slots for flexible content insertion
Accessibility Keyboard navigation, ARIA roles, labels
Backward Compatibility Provide compatibility layer or migration docs

✅ Acceptance Criteria

  • Comprehensive analysis of existing components documented
  • At least one core UI component fully refactored as a Web Component with shadow DOM encapsulation
  • Backward compatible usage or clear migration path provided
  • Automated unit and integration tests added and passing
  • Performance impact assessed and documented (no regressions)
  • Accessibility best practices implemented and verified
  • Documentation updated with API, usage, migration guides, and examples
  • Demo or playground showcasing new components available

🧪 Testing Requirements

  • Unit tests for isolated component logic, lifecycle hooks, and attribute handling
  • Integration tests embedding components in Astro and vanilla HTML contexts
  • Accessibility tests (e.g., axe-core integration)
  • Visual regression tests to catch style regressions
  • Performance benchmarks comparing old vs new implementations

📚 Documentation Needs

  • Update README with “Web Components” section
  • Component-level docs:
    • API references (attributes, events)
    • Usage examples in Astro, React, vanilla JS
  • Migration guide from existing Astro components to Web Components
  • Contribution guidelines for adding new Web Components
  • CHANGELOG entry explaining the refactor

⚠️ Potential Challenges

  • Ensuring smooth transition without breaking existing Astro-based consumers
  • Managing CSS isolation while supporting theming/customization
  • Handling complex component state and reactive updates within Web Components
  • Balancing incremental migration speed with thorough testing and documentation
  • Aligning with the BiomeJS toolchain and Astro build pipeline for seamless integration

🔗 Resources & References


🎯 Summary Checklist

  • Analyze & document current components
  • Define Web Component architecture & patterns
  • Refactor core components incrementally
  • Add unit and integration tests
  • Verify accessibility and performance
  • Update all relevant documentation and examples
  • Provide migration guides and compatibility layers

Let’s boldly refactor and push WebTUI to be a shining beacon of modular, encapsulated, framework-agnostic terminal UI components! Your mission, should you choose to accept it, is to build the future of WebTUI — one web component at a time. 🚀✨

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions