Component Breakdown with AI
AI is effective at two stages of component work: decomposing a UI design into a component hierarchy before you start coding, and generating TypeScript prop interfaces for components you have already decided on. The decomposition step is underused — spending 10 minutes with AI on component boundaries before writing code prevents the most common frontend debt: components that are too large to reuse and too tangled to test.
Decomposing a Design into Components
Describe the UI in words or paste a screenshot description. Be specific about interactions and state — AI cannot infer whether something is interactive from a static description alone.
1. Component Tree Generation
I am building a React application. Break down the following UI screen into a component tree.
Screen: [DESCRIBE THE UI — e.g., "A dashboard showing a list of orders. Each order has a status badge, customer name, total, and an actions dropdown. The list is filterable by status and searchable. Clicking an order opens a slide-over panel showing order details and a timeline."]
Tech stack: [REACT / NEXT.JS / VUE / etc.] with [TAILWIND / CSS MODULES / STYLED COMPONENTS]
For each component:
- Component name and file path
- Single responsibility (what it does in one sentence)
- Key props (with types)
- Whether it has internal state or is pure/presentational
- Child components it renders
After the tree, identify: which components are candidates for reuse across other screens, and which are screen-specific.
The reuse identification step is the most valuable part. It surfaces opportunities to put components in a shared directory rather than nesting them inside a specific page.
2. Component Boundary Review
Review the following component tree for my [SCREEN NAME] screen. Identify any component boundary problems:
[PASTE YOUR PROPOSED COMPONENT TREE]
Check for:
1. Components that do more than one thing (should be split)
2. Components so small they add complexity without reuse benefit (should be merged)
3. State that is being passed through too many levels (prop drilling — suggest where to lift or use context)
4. Missing components: interactions or states I have not modelled
5. Naming issues: names that do not make the component's responsibility clear
Run this review before implementing. Finding a boundary problem in a text description takes 5 minutes; finding it in written code takes an hour of refactoring.
Generating Prop Interfaces
Generate a TypeScript interface for the following React component.
Component: [COMPONENT NAME]
What it renders: [DESCRIBE THE OUTPUT]
What it needs to work: [LIST DATA AND CALLBACKS — e.g., "order data object, a callback for status change, loading state, whether the actions dropdown is available based on user role"]
Rules:
- Use specific types, not 'any' or generic 'object'
- Mark optional props with '?' only when there is a sensible default
- Callbacks use descriptive names: onStatusChange, not onChange
- Extract nested object types as separate named interfaces if they will be reused
- Add a JSDoc comment on each prop explaining when it is used
The JSDoc-per-prop request is important — it forces AI to think about whether each prop has a clear purpose. Unclear props usually mean unclear component responsibilities.
Composition Patterns
Use AI to think through which composition pattern fits your use case before implementing it.
| Pattern | When to use | What to ask AI |
|---|---|---|
| Compound components | Tabs, accordions, menus where children must coordinate | Generate compound component API with Context and displayName |
| Render props / children as function | When parent needs to expose state to caller-controlled render | Convert this component to use render prop; show before/after |
| Headless / hook-based | Logic reuse without coupling to a visual design | Extract logic from this component into a custom hook |
| Slots (children + named slots) | Layout components that accept flexible content areas | Design a card component with header/body/footer slot pattern |
| Higher-order components | Cross-cutting concerns (auth, analytics, feature flags) | Convert this HOC to a hook; explain the trade-off |
What You Must Decide
AI accelerates
- Generating initial component tree from a description
- Writing prop interfaces from a requirements list
- Explaining trade-offs between composition patterns
- Identifying prop drilling in a tree description
- Naming components consistently with your existing conventions
You must decide
- Whether a component belongs in shared vs page-specific
- Where to put global state vs local state
- What your team's file organisation conventions are
- Which components need accessibility (ARIA) handling
- Performance boundaries (where to memo, lazy load, or virtualize)
Checklist: Do You Understand This?
- Why is spending time on component decomposition before coding better than decomposing after?
- What information must you include in a component tree prompt that AI cannot infer from a static description?
- What is the reuse identification step in the component tree prompt — and why is it the most valuable part?
- Write a prop interface prompt for a notification toast component that shows different severity levels and can be dismissed.
- When would you use a compound component pattern versus a headless hook pattern?
- Name two component boundary problems that AI can identify before you start coding.