Writing High-Quality Maintainable Code: Component Abstraction and Granularity

Preface

As a meticulous front‑end developer, the author often faces questions when receiving UI designs: how to split pages, how to define reasonable components, and which abstraction approach to choose. This article shares personal insights on component abstraction and granularity.

What Is a Component

According to the React documentation, a component is conceptually similar to a JavaScript function that receives arbitrary inputs (props) and returns React elements describing the UI. Vue’s documentation describes a component as a reusable Vue instance with a name that can be used as a custom element within a root Vue instance created by new Vue .

In general, a component is a code snippet that implements specific functionality or renders a particular UI, typically imported into a project via import . The article uses React for the subsequent discussion.

Component Abstraction

Component abstraction is the process of extracting reusable, generic code into separate components. The main reasons for abstraction are:

Why Abstract Components

Large files containing 1k‑2k+ lines of React code become difficult to maintain, increase learning cost for new developers, and lead to code duplication when similar UI appears in multiple places. Extracting components promotes layering and reuse, reducing overall project complexity.

Reusable components also avoid redundant code, such as similar modal dialogs that differ only in titles or a few fields.

<TableConfiguration
// 基本参数
title="基础配置" // 标题名称
data={baseSettingData} // 展示数据
areaCode="baseSettingConfig" // 模块 code
config={baseSettingConfig} // 一些业务逻辑参数
// 新增参数
pageId={this.pageId} // 当前页面 Id
userIdentity={userIdentity} // 用户身份
/>

Initially, such a component is highly reusable, but as business expands, more parameters (e.g., pageId , userIdentity ) are added, leading to extensive conditional logic and making the component harder to maintain.

Basic Principles of Component Abstraction

Single Responsibility

A component should be highly cohesive and loosely coupled, handling only one concern. It may still reference other components (e.g., a container component that includes child components) without violating this principle.

Reusability / Generality

Design components with reuse in mind so they can be invoked in similar scenarios across projects. Public components (e.g., a UI library) aim for broad applicability, while project‑specific components address unique business needs.

Component Classification

Business Component vs. UI Component

Business components encapsulate data fetching and business logic, offering ready‑to‑use functionality. UI components (or basic components) focus on presentation, are highly reusable, and receive data via props.

Pure Component vs. Impure Component

Pure components implement shouldComponentUpdate (often using shallow equality) to avoid unnecessary re‑renders, making them suitable for display‑only components. Impure components inherit directly from Component and re‑render on any prop or state change.

Component Granularity

Granularity is not simply “the finer the better.” Over‑splitting leads to deep prop‑drilling, potential bugs, and performance overhead, while overly coarse components reduce reuse and maintainability. The article references Atomic Design (atoms, molecules, organisms, templates, pages) to illustrate appropriate granularity levels.

Atomic Component : Basic UI elements like Input or Button.

Molecular Component : Simple compositions of atoms, e.g., a labeled input.

Organism Component : More complex structures formed by atoms and molecules, such as a search bar with input and buttons.

Template Component : Layout structures that arrange organisms without concrete content.

Page : Full pages assembled from templates.

Choosing the right granularity should follow high cohesion and low coupling, adapting to specific business scenarios.

Conclusion

There is no universal standard for component abstraction or granularity. Teams should focus on adapting to business needs, maintaining clean layering, and establishing reasonable conventions to avoid excessive complexity.

References

React Component Design Practice Summary 02 – Component Organization: https://juejin.im/post/6844903843189243917#heading-3

Various React Components: https://zhuanlan.zhihu.com/p/30659051

React PureComponent Guide: https://juejin.im/entry/6844903480369512455

Atomic Design Practice: https://zhuanlan.zhihu.com/p/99737118