How do you write reusable components?

Writing reusable components is a fundamental skill for any software engineer, especially when working in modern frontend frameworks like React, Vue, or Angular. But beyond just "making something reusable," the real challenge lies in designing components that are flexible, maintainable, and performant across different parts of an application or even multiple projects.

From my experience, reusable components aren't just about code reuse—they're about creating building blocks that can adapt to various contexts without breaking or requiring heavy modifications. Let me walk you through how I approach writing reusable components, including practical tips, common pitfalls, and real-world examples.

Understanding What Makes a Component Reusable

At its core, a reusable component should be:

• Encapsulated: It manages its own internal state and behavior without leaking implementation details.
• Configurable: It accepts props or parameters to customize its appearance and behavior.
• Composable: It can be combined with other components or extended without rewriting.
• Predictable: It behaves consistently regardless of where or how it’s used.

Without these qualities, you risk creating components that are either too rigid (hard to adapt) or too tightly coupled (hard to maintain).

Core Concepts for Writing Reusable Components

1. Single Responsibility Principle (SRP)

Each component should have one clear purpose. For example, a Button component should handle rendering a button with different styles and states, but it shouldn’t also manage complex business logic or data fetching.

This keeps components focused and easier to test, debug, and reuse.

2. Props and Configuration

Use props (or inputs, depending on your framework) to allow customization. But be mindful not to overload your component with too many props, which can make it hard to understand and maintain.

Instead, group related props into objects or use patterns like render props or slots for more complex customization.

3. Avoid Hardcoding Styles and Logic

Hardcoded styles or logic reduce flexibility. Instead, allow styles to be overridden via class names, style objects, or CSS variables. Similarly, avoid embedding business rules inside the component; pass behaviors as callbacks or hooks.

4. Use Composition Over Inheritance

Composition lets you build complex components by combining simpler ones. For example, a Modal component can accept a header, body, and footer as children, allowing consumers to customize content without modifying the modal itself.

Real-World Example: Building a Reusable Button in React

Here’s a simple but practical example of a reusable button component:

function Button({ 
  children, 
  onClick, 
  variant = 'primary', 
  disabled = false, 
  className = '' 
}) {
  const baseClass = 'btn';
  const variantClass = `btn--${variant}`;
  const disabledClass = disabled ? 'btn--disabled' : '';

  return (
    <button
      className={`${baseClass} ${variantClass} ${disabledClass} ${className}`}
      onClick={disabled ? undefined : onClick}
      disabled={disabled}
    >
      {children}
    </button>
  );
}

This component:

• Supports multiple variants (primary, secondary, etc.) via the variant prop.
• Handles disabled state cleanly, preventing clicks and styling accordingly.
• Allows additional CSS classes via className for further customization.
• Is simple and focused on rendering a button, delegating behavior to the onClick callback.

Because it’s so focused and configurable, you can reuse this button across your app without duplicating code or styles.

Best Practices for Reusable Components

1. Design for Flexibility, Not for Every Use Case

It’s tempting to make a component handle every possible scenario, but that often leads to bloated, hard-to-maintain code. Instead, focus on the most common use cases and allow composition or extension for edge cases.

2. Document Your Components

Clear documentation helps other developers understand how to use your component correctly. Include prop types, expected behaviors, and examples.

3. Write Tests

Unit and integration tests ensure your component behaves as expected across different configurations. This is crucial when components are reused widely.

4. Keep State Local or Controlled

Decide whether your component should manage its own state or be controlled externally. For example, a form input might be controlled by the parent component to synchronize with global state.

5. Avoid Side Effects Inside Components

Reusable components should be as pure as possible. Side effects like API calls or subscriptions should be handled outside or in higher-order components/hooks.

Common Mistakes When Writing Reusable Components

• Overusing Global Styles: Relying on global CSS can cause conflicts and make components less portable.
• Too Many Props: Passing dozens of props makes the API confusing and error-prone.
• Embedding Business Logic: Mixing UI with domain logic reduces reusability and testability.
• Ignoring Accessibility: Reusable components should follow accessibility standards (like ARIA roles) to be usable by everyone.
• Not Handling Edge Cases: For example, not considering what happens when required props are missing or invalid.

Performance Considerations

Reusable components can sometimes introduce performance overhead if not designed carefully. For example:

• Unnecessary Re-renders: Passing new object or function references as props can cause child components to re-render unnecessarily. Use memoization techniques like React.memo or useCallback to prevent this.
• Heavy Computations: Avoid expensive calculations inside render methods; instead, use memoization or move logic outside the component.
• Large Bundle Size: Overly generic components might pull in dependencies or styles that bloat your app. Tree-shaking and code-splitting can help, but keep components lean.

Security Considerations

While reusable components mostly deal with UI, security can still be a concern:

• Sanitize User Input: If your component renders user-generated content (like rich text), sanitize it to prevent XSS attacks.
• Avoid Inline Event Handlers with Untrusted Data: Passing untrusted data directly into event handlers can lead to injection vulnerabilities.
• Be Cautious with Dangerous APIs: For example, React’s dangerouslySetInnerHTML should be used sparingly and only with sanitized content.

Interview Tips for Discussing Reusable Components

• Explain your thought process clearly: Why you made certain design decisions, how you balanced flexibility with simplicity.
• Use concrete examples from your experience, such as a component you built that saved time or reduced bugs.
• Discuss trade-offs, like when you chose composition over inheritance or how you handled state control.
• Be ready to talk about testing strategies and how you ensure your components don’t break when reused.
• Mention accessibility and performance considerations to show a well-rounded understanding.

Comparing Reusable Components with Alternatives

Approach	Pros	Cons	When to Use
Reusable Components	Modular, maintainable, consistent UI, easier testing	Requires upfront design, sometimes over-engineered	Building scalable UI libraries or apps with repeated UI patterns
Copy-Paste Code	Quick for small projects or prototypes	Hard to maintain, inconsistent, bug-prone	One-off features or very small apps
Higher-Order Components (HOCs)	Code reuse for behavior, separation of concerns	Can lead to wrapper hell, harder to debug	When you need to add cross-cutting concerns like logging or theming
Render Props / Hooks	Flexible, composable, good for sharing logic	Can be complex for beginners, verbose	Sharing stateful logic or behavior across components

Practical Production Scenarios

In one project, I was tasked with building a design system for a large e-commerce platform. We created a set of reusable components like buttons, inputs, cards, and modals. Initially, we tried to cover every edge case in each component, which made them bulky and hard to maintain.

After some iterations, we refactored to keep components focused and composable. For example, instead of a single Card component that handled images, text, buttons, and badges, we split it into smaller components that could be combined as needed. This improved maintainability and allowed teams to build new UI faster without reinventing the wheel.

We also invested in thorough documentation and automated visual regression tests to catch unintended UI changes early, which is crucial when components are reused across dozens of pages.

Another scenario involved performance optimization. We noticed some reusable components were causing excessive re-renders due to inline functions passed as props. By memoizing those functions and using React’s memo, we reduced unnecessary renders and improved page load times.

Summary

Writing reusable components is about more than just copying code. It requires thoughtful design, clear APIs, and attention to maintainability and performance. Focus on single responsibility, configurability, and composition. Avoid common pitfalls like overloading props or mixing concerns. Always consider accessibility and security, and back your components with tests and documentation.

When you explain this in an interview, emphasize your practical experience, trade-offs you’ve made, and how reusable components have helped your teams deliver better software faster.