rust-ui-architecture

Guide Rust GPUI application architecture with a four-layer UI, Application, Service, and Domain structure.

8|2|Updated Oct 17, 2025
One-click install
npx skills add https://github.com/geoffjay/claude-plugins --skill rust-ui-architecture
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rust-ui-architecture
Source: https://github.com/geoffjay/claude-plugins/tree/main/plugins/rust-gpui-developer/skills/rust-ui-architecture
Command: npx skills add https://github.com/geoffjay/claude-plugins --skill rust-ui-architecture

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solves? Designing a scalable and maintainable architecture for Rust UI applications, especially with frameworks like GPUI, can be challenging without clear guidelines on project structure, layer separation, and state management. This Skill provides a blueprint for robust application design.

Core Features & Use Cases

  • Application Structure: Recommended project layout and a four-layer architecture (UI, Application, Service, Domain) for clear separation of concerns and modularity.
  • Component Hierarchies: Guidance on patterns like Container-Presenter for effectively managing state and rendering logic within your UI components.
  • State Management Architecture: Implement unidirectional data flow, single source of truth, and hierarchical ownership patterns for predictable and robust state handling.
  • Use Case: A team is building a complex Rust UI application and needs to ensure its architecture supports long-term growth and maintainability. This Skill provides a blueprint for organizing code, managing dependencies, and establishing clear boundaries between different parts of the application.

Quick Start

// Example of UI Layer accessing Model pub mod ui { use gpui::; use super::models::;

pub struct DocumentView {
    model: Model<DocumentModel>,
    _subscription: Subscription,
}

impl Render for DocumentView {
    fn render(&mut self, cx: &mut ViewContext<Self>) -> impl IntoElement {
        let model = self.model.read(cx);
        div().child(format!("Words: {}", model.document.word_count()))
    }
}

}

Frequently Asked Questions about rust-ui-architecture

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure a scalable Rust UI application with GPUI?

Structure your Rust UI application using a four-layer architecture: UI, Application, Service, and Domain layers. This separation ensures modularity, clear boundaries between concerns, and long-term maintainability as your codebase grows. Each layer has specific responsibilities—UI handles rendering, Application orchestrates logic, Service manages business rules, and Domain contains core models.

What's the best way to manage state in a Rust GPUI application?

Implement unidirectional data flow with a single source of truth and hierarchical ownership patterns. Use container-presenter patterns for components to separate state management from rendering logic. This predictable approach reduces bugs and makes state changes easier to trace and debug.

How do I organize components and files in a GPUI project?

Follow the recommended file layout aligned with your four-layer architecture. Use naming conventions and design patterns specific to each layer—components in UI, use cases in Application, business logic in Service, and data models in Domain. Consistent organization prevents tangled dependencies and improves code navigation.

Can I use design patterns like Container-Presenter with Rust GPUI?

Yes. The Container-Presenter pattern effectively separates state management from rendering in GPUI components. Containers handle state and side effects while Presenters focus on rendering. This pattern is fundamental to maintaining clean, testable component hierarchies in Rust UI applications.

What are the key principles for building maintainable Rust UI architectures?

Apply layered architecture, enforce clear separation of concerns, establish naming conventions, implement hierarchical state ownership, and use unidirectional data flow. These principles work together to prevent monolithic designs, reduce coupling between modules, and ensure your application scales with complexity.