Components are the building blocks of modern web development. Whether you're using React, Vue, Angular, or any other framework, understanding how to architect components effectively is a critical skill that separates average developers from exceptional ones. But what exactly makes a component "good"? How do top engineers at companies like Google approach component design? And how can both beginners and experienced developers apply these principles? In this comprehensive guide, I'll share 15 universal rules of component building that will elevate your development skills regardless of your experience level or the framework you use. ## Rule 1: Follow the Single Responsibility Principle Perhaps the most fundamental rule of component architecture is that **each component should do exactly one thing and do it well**. **For beginners**: Think of a component like a specialized tool in a kitchen. A knife cuts, a spoon stirs, and a whisk beats. You wouldn't create a "spork-whisk-knife" that does everything poorly. **For experienced developers**: This means rigorously evaluating component boundaries not just by visual separation but by behavioral cohesion. When a component handles multiple concerns, it becomes less predictable, harder to test, and more difficult to reuse. ```jsx // 🚫 Bad: Component doing too many things function UserProfile({ userId }) { const [user, setUser] = useState(null); const [loading, setLoading] = useState(true); useEffect(() => { fetchUser(userId).then(data => { setUser(data); setLoading(false); }); }, [userId]); return (

{loading ? : ( <>

{user.name}

)}

); } // ✅ Better: Decomposed into focused components function UserProfile({ userId }) { return ( ); } function UserProfileLayout() { const { user, loading } = useUserData(); if (loading) return ; return (

); } ``` ## Rule 2: Create a Clear Component Hierarchy with Atomic Design Successful component systems are organized in a clear hierarchy, from simple to complex. **For beginners**: Think of it like LEGO blocks. You have tiny pieces (atoms) that combine to form small structures (molecules), which combine to form more complex sections (organisms), and eventually complete pages. **For experienced developers**: Implement a systematic approach like Brad Frost's Atomic Design methodology, which provides a clear mental model for component composition: 1. **Atoms**: Basic building blocks (buttons, inputs, labels) 2. **Molecules**: Simple groups of UI elements functioning together (search form) 3. **Organisms**: Complex UI components composed of molecules (header) 4. **Templates**: Page-level layouts without real content 5. **Pages**: Specific instances of templates with real content ```jsx // Atomic design in practice // ⚛️ Atom function Button({ children, onClick, variant = "primary" }) { return ( ); } // 🔬 Molecule function SearchInput({ onSearch }) { const [query, setQuery] = useState(""); const handleSubmit = (e) => { e.preventDefault(); onSearch(query); }; return ( ); } // 🧫 Organism function Header() { const handleSearch = (query) => { // Search logic }; return (

); } ``` ## Rule 3: Prioritize Props API Design The public interface of your component (its props) is a contract with other developers. Invest time in designing it well. **For beginners**: Props are like settings on a TV remote. They should be intuitive, well-named, and not overwhelming. **For experienced developers**: Apply interface design principles to your props. Make required props obvious, use sensible defaults, and consider the principle of least surprise. ```jsx // 🚫 Poor props API design function DataTable({ d, p, onS, c, s, l, onR, e }) { // Implementation } // ✅ Better props API design function DataTable({ data, pageSize = 10, onSort, columns, sortedColumn, loading = false, onRowClick, error = null, }) { // Implementation } // ✅ Even better: Use object composition for related props function DataTable({ data, pagination = { pageSize: 10, currentPage: 1 }, sorting = { column: null, direction: 'asc' }, onSort, onPageChange, columns, loading = false, onRowClick, error = null, }) { // Implementation } ``` ## Rule 4: Build for Composability, Not Configuration The best components don't try to handle every possible use case through configuration props. Instead, they're designed to be composed with other components. **For beginners**: Rather than building a super-complex "Swiss Army knife" component, build simpler components that work well together. **For experienced developers**: Embrace React's component composition model using techniques like the children prop, render props, or higher-order components. ```jsx // 🚫 Too much configuration function Button({ label, onClick, size, color, rounded, outlined, icon, iconPosition, isFullWidth, disabled, loading, loadingText, tooltip, tooltipPosition, // ...20 more props }) { // Complex implementation with many conditions } // ✅ Better: Composed components function Button({ children, size, variant, disabled, ...rest }) { // Simpler implementation return ( ); } // Compose to build complexity function IconButton({ icon, children, ...rest }) { return ( ); } function LoadingButton({ loading, children, ...rest }) { return ( ); } // Usage Submit ``` ## Rule 5: Separate Container and Presentational Components One of the most powerful patterns in component architecture is the separation of concerns between data-fetching/state management and rendering. **For beginners**: Think of this like separating the chef (who gets ingredients and prepares them) from the server (who presents the dish to customers). **For experienced developers**: This pattern enhances reusability, testability, and maintainability by decoupling business logic from presentation logic. ```jsx // 🚫 Mixed concerns function UserList() { const [users, setUsers] = useState([]); const [loading, setLoading] = useState(true); const [error, setError] = useState(null); useEffect(() => { fetch('/api/users') .then(res => res.json()) .then(data => { setUsers(data); setLoading(false); }) .catch(err => { setError(err); setLoading(false); }); }, []); if (loading) return

; if (error) return

Error: {error.message}

; return (

{users.map(user => (

{user.name}

{user.email}

))}

); } // ✅ Separated concerns // Container component function UserListContainer() { const [users, setUsers] = useState([]); const [loading, setLoading] = useState(true); const [error, setError] = useState(null); useEffect(() => { fetch('/api/users') .then(res => res.json()) .then(data => { setUsers(data); setLoading(false); }) .catch(err => { setError(err); setLoading(false); }); }, []); return ( ); } // Presentational component function UserList({ users, loading, error }) { if (loading) return

; if (error) return

Error: {error.message}

; return (

{users.map(user => ( ))}

); } function UserCard({ user }) { return (

{user.name}

{user.email}

); } ``` ## Rule 6: Implement Consistent Error Handling Error handling is often an afterthought, but in robust component design, it's a first-class concern. **For beginners**: Always plan for what happens when things go wrong, not just when they go right. **For experienced developers**: Create standardized error boundaries and error states that gracefully handle failures at different levels of your component hierarchy. ```jsx // Error boundary component class ErrorBoundary extends React.Component { constructor(props) { super(props); this.state = { hasError: false, error: null }; } static getDerivedStateFromError(error) { return { hasError: true, error }; } render() { if (this.state.hasError) { return this.props.fallback ? ( this.props.fallback(this.state.error) ) : (

Something went wrong.

{this.state.error?.message}

); } return this.props.children; } } // Usage function App() { return (

); } // Component-level error handling function DataFetcher({ url, renderData }) { const [data, setData] = useState(null); const [loading, setLoading] = useState(true); const [error, setError] = useState(null); useEffect(() => { setLoading(true); setError(null); fetch(url) .then(res => { if (!res.ok) throw new Error(`HTTP error ${res.status}`); return res.json(); }) .then(data => { setData(data); setLoading(false); }) .catch(err => { setError(err); setLoading(false); }); }, [url]); if (loading) return ; if (error) return ; return renderData(data); } ``` ## Rule 7: Design with Accessibility from the Start Accessibility isn't a feature—it's a fundamental aspect of component design. **For beginners**: Accessibility means making your app usable by everyone, including people with disabilities. **For experienced developers**: Build accessibility patterns directly into your base components, leveraging ARIA attributes, keyboard navigation, and semantic HTML. ```jsx // 🚫 Inaccessible component function Dropdown({ options, onSelect }) { const [isOpen, setIsOpen] = useState(false); const [selected, setSelected] = useState(options[0]); return (

setIsOpen(!isOpen)}> {selected.label}

{isOpen && (

{options.map(option => (

{ setSelected(option); onSelect(option); setIsOpen(false); }} > {option.label}

))}

)}

); } // ✅ Accessible component function Dropdown({ options, onSelect, id }) { const [isOpen, setIsOpen] = useState(false); const [selected, setSelected] = useState(options[0]); const menuId = `${id}-menu`; // Close menu when clicking outside const dropdownRef = useRef(null); useEffect(() => { const handleClickOutside = (event) => { if (dropdownRef.current && !dropdownRef.current.contains(event.target)) { setIsOpen(false); } }; document.addEventListener('mousedown', handleClickOutside); return () => { document.removeEventListener('mousedown', handleClickOutside); }; }, []); // Handle keyboard navigation const handleKeyDown = (event) => { switch (event.key) { case 'Escape': setIsOpen(false); break; case 'ArrowDown': if (!isOpen) { setIsOpen(true); } // Focus next option break; // Handle other keys... } }; return (

{isOpen && ( )}

); } ``` ## Rule 8: Make Components Resilient with Defensive Coding Robust components handle unexpected inputs gracefully rather than breaking. **For beginners**: Always expect the unexpected. Users and other developers will use your component in ways you didn't anticipate. **For experienced developers**: Implement thorough prop validation, default props, and guards against null or undefined values. ```jsx // 🚫 Fragile component function UserProfile({ user }) { return (

{user.name}

{user.bio}

Followers: {user.stats.followers} Following: {user.stats.following}

); } // ✅ Resilient component function UserProfile({ user = {} }) { const { avatarUrl = '/default-avatar.png', name = 'Unknown User', bio = 'No bio available', stats = { followers: 0, following: 0 } } = user; return (

{ e.target.src = '/default-avatar.png'; }} />

{name}

{bio}

Followers: {stats.followers} Following: {stats.following}

); } // Even better with TypeScript interface UserStats { followers: number; following: number; } interface User { avatarUrl?: string; name?: string; bio?: string; stats?: UserStats; } interface UserProfileProps { user?: User; } function UserProfile({ user = {} }: UserProfileProps) { // Implementation with type safety } ``` ## Rule 9: Optimize for Performance Proactively Performance isn't something you add at the end—it's designed in from the beginning. **For beginners**: Even simple performance habits like avoiding unnecessary re-renders can make a big difference. **For experienced developers**: Use memoization strategically, implement virtualization for long lists, defer non-critical rendering, and measure performance impacts. ```jsx // 🚫 Performance-inefficient component function ExpensiveList({ items, onItemClick }) { // This component re-renders unnecessarily return (

onItemClick(item)} > {item.name}

); } // ✅ Performance-optimized component const MemoizedExpensiveComponent = React.memo(ExpensiveComponent); function ExpensiveListItem({ item, onClick }) { const handleClick = useCallback(() => { onClick(item); }, [item, onClick]); return (

{item.name}

); } function ExpensiveList({ items, onItemClick }) { // Only re-render items that changed return (

))}

); } // For very large lists, use virtualization import { FixedSizeList } from 'react-window'; function VirtualizedList({ items, onItemClick }) { const Row = ({ index, style }) => { const item = items[index]; return (

); }; return ( {Row} ); } ``` ## Rule 10: Design for Testability Testable components are inherently better designed and more maintainable. **For beginners**: If your component is hard to test, it's probably hard to understand and maintain too. **For experienced developers**: Design components with explicit, injectable dependencies and clear contracts that make unit testing straightforward. ```jsx // 🚫 Hard-to-test component function UserActions({ userId }) { const [user, setUser] = useState(null); useEffect(() => { // Directly calling external service UserService.getUser(userId).then(setUser); }, [userId]); const handleAction = () => { // Direct side effect UserService.performAction(userId); window.location.href = '/success'; }; return (

{user && }

); } // ✅ Testable component function UserActions({ userId, fetchUser = UserService.getUser, performAction = UserService.performAction, navigateTo = (path) => window.location.href = path }) { const [user, setUser] = useState(null); useEffect(() => { fetchUser(userId).then(setUser); }, [userId, fetchUser]); const handleAction = () => { performAction(userId); navigateTo('/success'); }; return (

{user && }

); } // Test example test('UserActions performs action and navigates on click', async () => { const mockFetchUser = jest.fn().mockResolvedValue({ id: '123', name: 'Test User' }); const mockPerformAction = jest.fn().mockResolvedValue({}); const mockNavigateTo = jest.fn(); const { getByText } = render( ); await waitFor(() => expect(mockFetchUser).toHaveBeenCalledWith('123')); fireEvent.click(getByText('Perform Action')); expect(mockPerformAction).toHaveBeenCalledWith('123'); expect(mockNavigateTo).toHaveBeenCalledWith('/success'); }); ``` ## Rule 11: Document Components with Care Great components come with great documentation—it's part of the component, not an afterthought. **For beginners**: Write clear comments explaining how your component works and how to use it. **For experienced developers**: Implement comprehensive but concise documentation that includes usage examples, prop definitions, and design principles. ```jsx /** * Button - A customizable button component with various states and styles. * * @component * @example * // Primary button * * * // Disabled button * * * @param {Object} props - The component props. * @param {ReactNode} props.children - The button content. * @param {string} [props.variant="primary"] - The button style variant. * @param {boolean} [props.disabled=false] - Whether the button is disabled. * @param {function} [props.onClick] - Click handler function. * @param {string} [props.size="medium"] - Button size (small, medium, large). * @param {Object} [props.rest] - Additional props passed to the button element. */ function Button({ children, variant = "primary", disabled = false, onClick, size = "medium", ...rest }) { return ( ); } Button.propTypes = { children: PropTypes.node.isRequired, variant: PropTypes.oneOf(["primary", "secondary", "danger", "ghost"]), disabled: PropTypes.bool, onClick: PropTypes.func, size: PropTypes.oneOf(["small", "medium", "large"]), }; ``` ## Rule 12: Handle State Management Appropriately Different types of state belong at different levels of your component hierarchy. **For beginners**: Think of state like information in an organization. Some info is personal (component state), some is shared between a few people (context), and some is company-wide (global state). **For experienced developers**: Categorize state properly and use the right tools for the job, whether that's local component state, React Context, Redux, or another state management solution. ```jsx // Different types of state handled appropriately // 1. UI State - Local to component function Accordion({ title, children }) { // UI state belongs in the component const [isOpen, setIsOpen] = useState(false); return (

{isOpen &&

{children}

}

); } // 2. Shared State - Context const ThemeContext = React.createContext('light'); function ThemeProvider({ children }) { const [theme, setTheme] = useState('light'); return ( {children} ); } function ThemedButton() { const { theme } = useContext(ThemeContext); return ; } // 3. Application State - Redux or similar // For complex, global application state function UserProfile() { // Using Redux hooks const user = useSelector(state => state.user); const dispatch = useDispatch(); const handleLogout = () => { dispatch({ type: 'USER_LOGOUT' }); }; return (

{user.name}

); } ``` ## Rule 13: Make Components Themeable and Customizable Great component systems adapt to different visual styles without changing functionality. **For beginners**: Separate what a component does from how it looks, making it easier to change its appearance. **For experienced developers**: Implement a comprehensive theming system with design tokens, CSS variables, or a CSS-in-JS solution. ```jsx // 🚫 Hard-coded styles function Button({ children, onClick }) { return ( ); } // ✅ Themeable button using CSS variables function Button({ children, variant = "primary", size = "medium", onClick }) { return ( ); } // CSS with variables :root { --color-primary: #0070f3; --color-secondary: #6c757d; --color-danger: #dc3545; --border-radius: 4px; } .btn { border-radius: var(--border-radius); border: none; font-weight: 500; } .btn-primary { background-color: var(--color-primary); color: white; } .btn-small { padding: 6px 12px; font-size: 14px; } .btn-medium { padding: 10px 20px; font-size: 16px; } // Theme switching :root[data-theme="dark"] { --color-primary: #5c9eff; --color-secondary: #8c8c8c; --color-danger: #ff6b6b; --border-radius: 8px; } ``` ## Rule 14: Design for i18n and Localization from the Start International components handle different languages, formats, and cultural considerations seamlessly. **For beginners**: Don't hardcode text or assume everyone sees dates and numbers the same way you do. **For experienced developers**: Implement a proper i18n system and ensure components adapt to different content lengths and reading directions. ```jsx // 🚫 Not internationalized function Checkout({ price, date }) { return (

Checkout

Price: ${price}

Delivery date: {date.toLocaleDateString()}

); } // ✅ Internationalized import { useTranslation } from 'react-i18next'; import { FormattedNumber, FormattedDate } from 'react-intl'; function Checkout({ price, date, locale = 'en', currency = 'USD' }) { const { t } = useTranslation(); return (

{t('checkout.title')}

{t('checkout.price')}:

{t('checkout.delivery_date')}:

); } ``` ## Rule 15: Write Self-Documenting Code with Clear Naming The best component code reads like a story, with clear names that convey intent. **For beginners**: Spend time choosing good names for your components, props, and functions. It makes your code easier to understand. **For experienced developers**: Names should reveal purpose, not implementation. They should be consistent across your codebase and follow established patterns. ```jsx // 🚫 Poor naming function Comp1({ d, f1, f2, enableFlag }) { const [s, setS] = useState(false); const h = () => { setS(!s); f1(d.id); }; return (

{d.t}

{d.desc}

{enableFlag && } {s &&

{d.more}

}

); } // ✅ Clear, self-documenting naming function ExpandableCard({ item, onSelect, onExpand, isEditable = false }) { const [isExpanded, setIsExpanded] = useState(false); const handleToggle = () => { const newExpandedState = !isExpanded; setIsExpanded(newExpandedState); onExpand(item.id, newExpandedState); }; return (

{item.title}

{item.description}

{isEditable && ( )} {isExpanded && (

{item.details}

)}

); } ``` ## Bonus: Putting It All Together - Component Design Systems The ultimate expression of component architecture is a full-fledged design system that implements all these rules consistently. **For beginners**: A design system is like a standard set of LEGO pieces that all work together perfectly. **For experienced developers**: Design systems provide a unified language for design and development, reducing decision fatigue and ensuring consistency. ```jsx // A simple example of a design system component import { useState, useContext } from 'react'; import { ThemeContext } from './ThemeProvider'; import { useTranslation } from 'react-i18next'; import { Icon } from './Icon'; /** * Alert - Displays important information or feedback to users */ function Alert({ title, children, variant = 'info', icon, dismissible = false, onDismiss, testId, }) { const [dismissed, setDismissed] = useState(false); const { theme } = useContext(ThemeContext); const { t } = useTranslation(); const handleDismiss = () => { setDismissed(true); if (onDismiss) onDismiss(); }; if (dismissed) return null; return (

{icon && }

{title &&

{title}

}

{children}

{dismissible && ( )}

); } // Usage Your profile has been updated successfully. ``` ## Conclusion: The Journey to Component Mastery Great component architecture is a journey, not a destination. These 15 rules provide a roadmap, but you'll develop your own patterns and principles as you grow as a developer. Start by focusing on the fundamentals: single responsibility, clear props APIs, and good composition. As you gain experience, you'll naturally incorporate more advanced patterns like performance optimization, accessibility, and internationalization. Remember that components aren't just technical artifacts—they're the way we communicate our application's capabilities to other developers and users. By creating thoughtful, well-designed components, you're making your applications more maintainable, more accessible, and more delightful to use. Whether you're building a simple personal project or working on enterprise-level applications at Google or Facebook, these component building rules will serve you well. Now it's your turn to put these principles into practice. Start by evaluating your existing components against these rules, or design your next component with these principles in mind from the beginning. The quality of your code—and the experience of everyone who works with it—will thank you. **What's your favorite component design principle? Share your thoughts in the comments below!**

JavaScript Fundamentals to Master for React Development

Related Posts

The Ultimate Guide to Component Building: 15 Rules That Google Engineers Swear By