# Architectural Rules for Modular React Component Generation from Stitch Designs: The Complete Guide > Discover architectural rules for generating modular React components from Stitch designs. Learn to create production-ready codebases with Vite, Tailwind, and React Router. - Repository: [Google Labs Code/stitch-skills](https://github.com/google-labs-code/stitch-skills) - Tags: architecture - Published: 2026-07-18 --- **The stitch::react-components skill enforces strict architectural rules—including component granularity, logic isolation, and type safety—to transform Stitch designs into modular, production-ready React codebases compatible with Vite, Tailwind, and React Router.** Converting visual designs into maintainable code requires disciplined architecture. The `google-labs-code/stitch-skills` repository defines precise **architectural rules for modular React component generation from Stitch designs** to ensure generated codebases remain scalable, type-safe, and consistent with modern React patterns. These rules, specified in **Phase 3** of the skill documentation, mandate specific file structures, data patterns, and validation gates that every component must satisfy. ## Enforce Granular Component Architecture ### Atomic Design and File Organization Every reusable UI pattern must reside in its own file under `src/components/`. The skill mandates **component granularity** where atomic elements compose into larger composite structures, preventing monolithic page files. As defined in [`plugins/stitch-build/skills/react-components/SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main/plugins/stitch-build/skills/react-components/SKILL.md), component file names must exactly match the exported component name—such as [`Button.tsx`](https://github.com/google-labs-code/stitch-skills/blob/main/Button.tsx) or [`Card.tsx`](https://github.com/google-labs-code/stitch-skills/blob/main/Card.tsx)—to guarantee IDE auto-import support and discoverability. ### Props Interface Requirements Every component must export a **`Readonly`** props interface named `Props`. These interfaces enforce immutability and are validated via `npm run validate`. The **Type safety** rule in Phase 3 requires this pattern for all components, including page-level views. ```typescript // src/components/Card.tsx export interface CardProps { readonly title: string; readonly description: string; readonly imageUrl: string; } export const Card: React.FC = ({ title, description, imageUrl }) => (
{/* … */}
); ``` ## Isolate Business Logic in Custom Hooks All event handling, pagination, filtering, and state management must be extracted to `src/hooks/`. Following the **Logic isolation** rule from Phase 3 of [[`SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main/SKILL.md)](https://github.com/google-labs-code/stitch-skills/blob/main/plugins/stitch-build/skills/react-components/SKILL.md), hook files must follow the `use...` naming convention to clearly indicate encapsulated business logic. ```typescript // src/hooks/usePagination.ts import { useState } from "react"; export function usePagination(items: T[], pageSize: number) { const [page, setPage] = useState(0); const pageCount = Math.ceil(items.length / pageSize); const pagedItems = items.slice(page * pageSize, (page + 1) * pageSize); return { page, setPage, pageCount, pagedItems }; } ``` ## Decouple Static Data from Components The **Data decoupling** rule mandates that all hard-coded strings, image URLs, and data arrays live exclusively in [`src/data/mockData.ts`](https://github.com/google-labs-code/stitch-skills/blob/main/src/data/mockData.ts). Components import these values rather than embedding literals, ensuring pure, reusable presentation logic that remains easy to update and localize. ```typescript // src/data/mockData.ts export const HERO_TEXT = "Build a DeFi portfolio dashboard"; export const CARDS = [ { title: "Bitcoin", value: "$23,456", icon: "/icons/btc.svg" }, // … ]; ``` ```tsx // src/components/Hero.tsx import { HERO_TEXT } from "../data/mockData"; export const Hero = () =>

{HERO_TEXT}

; ``` ## Wire Navigation with React Router Replace all `` tags with React Router `` components. The architecture requires the **top logo** to use `` for desktop navigation, while bottom and sidebar items implement active-state handling via `useLocation()` to ensure proper SPA behavior. ```tsx // src/components/TopAppBar.tsx import { Link } from "react-router-dom"; export const TopAppBar = () => (
MyApp {/* …other nav items… */}
); ``` ## Apply Tailwind Styling and Dark Mode Standards Design tokens extracted to [`resources/style-guide.json`](https://github.com/google-labs-code/stitch-skills/blob/main/resources/style-guide.json) during Phase 2 must drive all styling decisions. Component class names reference these tokens using Tailwind utilities, with every color class receiving the **`dark:`** prefix for automatic dark mode support. Never use raw hex values in component files; always map through the design tokens as specified in [[`react-tailwind.md`](https://github.com/google-labs-code/stitch-skills/blob/main/react-tailwind.md)](https://github.com/google-labs-code/stitch-skills/blob/main/plugins/stitch-design/skills/extract-design-md/references/react-tailwind.md). ```tsx // src/components/Button.tsx export const Button = ({ children }: { readonly children: React.ReactNode }) => ( ); ``` ## Validate Against the Architecture Checklist Before production, components must pass the quality gate defined in [`plugins/stitch-build/skills/react-components/resources/architecture-checklist.md`](https://github.com/google-labs-code/stitch-skills/blob/main/plugins/stitch-build/skills/react-components/resources/architecture-checklist.md). The `npm run validate` command checks for structural integrity, type safety, and styling conventions. Any missing `Props` interface, hard-coded hex color, or logic embedded in JSX causes immediate validation failure, ensuring only architecturally sound code enters the repository. ## End-to-End Implementation: From Design to Component Transforming a Stitch design into a validated React component follows this strict workflow: ### 1. Extract Design Tokens Run the extraction utility to populate the style guide before writing components. ```bash npm run extract-tokens # populates resources/style-guide.json ``` ### 2. Define Static Data Centralize all content in the mock data layer. ```typescript // src/data/mockData.ts export const CARD_DATA = [ { title: "Bitcoin", description: "Leading cryptocurrency", imageUrl: "/assets/btc.svg", }, ]; ``` ### 3. Build the Component and Page Implement the atomic component with proper typing and consume it in page views. ```tsx // src/components/Card.tsx export interface CardProps { readonly title: string; readonly description: string; readonly imageUrl: string; } export const Card: React.FC = ({ title, description, imageUrl }) => (
{title}

{title}

{description}

); ``` ```tsx // src/pages/Home.tsx import { Card } from "../components/Card"; import { CARD_DATA } from "../data/mockData"; export const Home = () => (
{CARD_DATA.map((c) => ( ))}
); ``` ### 4. Configure Routing Wire components into the application router. ```tsx // src/App.tsx import { BrowserRouter as Router, Routes, Route } from "react-router-dom"; import { Home } from "./pages/Home"; import { TopAppBar } from "./components/TopAppBar"; export const App = () => ( } /> {/* additional routes… */} ); ``` ### 5. Execute Validation Run the architecture validator to ensure compliance. ```bash npm run validate src/components/Card.tsx npm run validate src/pages/Home.tsx ``` ## Summary - **Component granularity**: Each UI pattern lives in its own file under `src/components/` following atomic design principles. - **Logic isolation**: All state and business logic must reside in `src/hooks/` using the `use...` naming convention. - **Data decoupling**: Static content belongs exclusively in [`src/data/mockData.ts`](https://github.com/google-labs-code/stitch-skills/blob/main/src/data/mockData.ts), never embedded in components. - **Type safety**: Every component exports a `Readonly` props interface validated by `npm run validate`. - **Navigation standards**: Use React Router `` components exclusively, with the top logo linking to `/`. - **Styling compliance**: Reference [`resources/style-guide.json`](https://github.com/google-labs-code/stitch-skills/blob/main/resources/style-guide.json) tokens and apply `dark:` prefixes for all color classes. ## Frequently Asked Questions ### What is the stitch::react-components skill? The stitch::react-components skill is a code generation module within `google-labs-code/stitch-skills` that converts Stitch design exports into modular React applications. It enforces a three-phase workflow: design extraction, token generation, and component architecture, ensuring outputs are compatible with Vite, Tailwind CSS, and React Router while maintaining strict TypeScript standards. ### Why must all props interfaces be Readonly? The **`Readonly`** requirement prevents accidental mutation of component inputs, enforcing unidirectional data flow patterns essential for React optimization and predictability. This rule, defined in Phase 3 of [`SKILL.md`](https://github.com/google-labs-code/stitch-skills/blob/main/SKILL.md), allows the `npm run validate` checker to enforce immutability contracts across the entire component library. ### How does the validator enforce architectural rules? The validator script reads the quality gate specifications from [`architecture-checklist.md`](https://github.com/google-labs-code/stitch-skills/blob/main/architecture-checklist.md) and scans source files for compliance. It checks for the presence of exported `Props` interfaces, verifies that no hard-coded hex values exist in component files, ensures hooks are stored in `src/hooks/`, and confirms that navigation uses React Router `` components rather than anchor tags. ### Where should design tokens be stored in a Stitch-generated project? Design tokens extracted from Stitch HTML reside in [`resources/style-guide.json`](https://github.com/google-labs-code/stitch-skills/blob/main/resources/style-guide.json) at the project root. These tokens map to Tailwind configuration values, and the architectural rules prohibit referencing raw color values or spacing units directly in components—all styling must derive from this centralized token file to ensure theme consistency and dark mode support.