Many teams go through a seemingly logical phase: first build a React component library, consolidating buttons, carousels, cards, navigations, and forms, and then believe that the problem of page building will naturally be solved as the number of components increases.

This approach usually works fine in single-site, low-frequency update projects maintained by front-end engineers. But when the business expands to multi-country sites, multi-merchant official websites, frequent marketing campaigns, and non-developer maintenance, the component library is no longer the answer itself — it can only be part of the answer.

What we eventually did was no longer "providing more components," but "providing a page production system." The title's phrase "abandoning the component library" is admittedly a bit sensational; the reality is not about discarding components, but about downgrading components from the final deliverable to the foundational material within the page platform.

I. The Component Library Solves the Reuse Problem, Not the Production Problem

A component library is naturally good at three things: unifying visuals, reusing interactions, and improving development efficiency.

It solves the question: "When developers write pages, what ready-made blocks can they use directly?" This is important, but it implies several prerequisites:

Pages are still written by programmers
Page changes are completed through code commits, testing, building, and deployment
Page structure is determined by code, not by configuration
After a page goes live, version management still relies on Git and deployment systems

If your business is still at this stage, a component library is sufficient.

However, the capability boundaries of a component library are very clear — it only covers the earliest part of the page lifecycle: coding efficiency during the development phase. Once business complexity goes beyond this phase, you will find that there is still a huge gap between "having components available" and "being able to deliver pages efficiently": How can non-technical personnel maintain pages? How to manage versions of 500+ pages? How to roll back in seconds without redeployment? The component library cannot answer these questions.

The following diagram shows the capability boundary of the component library and the coverage scope of the page platform:

The problem is that multi-site official websites quickly break down the prerequisites of a component library one by one.

II. Once You Enter Multi-Site Territory, Complexity Is No Longer at the Component Level

Using our scenario as an example, what truly caused the system to spiral out of control was not "whether there is a Banner component," but the simultaneous emergence of the following changes:

2.1 Pages No Longer Have Just One Version

The same route may correspond to different page versions at different release times, different canary stages, and under different merchants.

For a concrete example: the path /product/xxxx-x might show the new v2.1 Hero block to 10% of users during canary, while 90% of users still see v2.0. Meanwhile, Merchant A and Merchant B use different product data APIs and different CTA button styles. This means that "the same page" might actually have 4 version instances online at the same time.

At this point, a page is no longer a piece of React code; it becomes a versioned asset that needs to be published, tracked, rolled back, and compared. What you need is not a Git branch, but a runtime-level version management system.

2.2 Pages Are No Longer Maintained Only by Engineers

Operations need to change copy, marketing needs to swap campaign images, and product needs to adjust the order of modules. If every change must go through the pipeline "submit request → engineer modify code → test → release," system throughput will quickly be strangled by manpower.

We observed actual data: before the page platform, a simple Banner copy change took an average of 1-2 working days from request to launch; after the platform, operations can complete and publish it autonomously within 10 minutes. This efficiency gap grows as the number of pages and update frequency increase.

A component library cannot directly hand over pages to non-technical users for maintenance because the component library is designed for developers' APIs, not for an operations interface.

The following diagram compares the typical flow of a single page modification under the traditional component library model and the page platform model:

2.3 Pages No Longer Face Only One Site

The most common mistake in multi-merchant systems is understanding "multi-site" as "making several copies of pages." But the reality is:

UI styles differ: brand colors, typography, fonts, spacing may all vary
Data APIs differ: product APIs, promotion APIs, user APIs have independent domains and parameter structures
Some components are only available for specific merchants: e.g., Merchant A has a "trade-in" module, Merchant B does not
Certain business rules only apply to specific sites: price display rules, shipping calculations, regional restrictions, etc.

If all these differences are handled with React conditional statements — if (merchant === 'A') { ... } else if (merchant === 'B') { ... } — scattered across dozens of components, you will inevitably end up with a codebase that no one dares to touch. Every line change risks affecting other merchants.

2.4 Pages No Longer Have Only One Rendering Path

For official website business, browser-side rendering alone is usually insufficient. SEO, first-screen performance, timeliness of marketing campaigns, and online failure recovery will all push you toward SSR, pre-building, offline artifacts, and runtime version management.

In our system, from page configuration to the user seeing HTML, the page goes through at least the following stages:

At this point, you are no longer just handling a component tree; you also need to manage build artifacts, route mappings, caching, and rollback strategies. In the entire pipeline, the component library only covers step E.

III. "Writing Pages" and "Assembling Pages" Are Two Completely Different System Designs

Many teams fall into a pit here because they try to solve the "assembling pages" problem with the "writing pages" approach.

The biggest difference is not in the UI, but in the system boundaries.

Dimension	Writing Pages (Component Library Model)	Assembling Pages (Page Platform Model)
Core object	Code (JSX / TSX)	Configuration, protocol, versioned artifact
Operator	Engineer	Operations + Product + Engineer
Release method	Git push → CI/CD → full deployment	Click publish in admin → incremental effect
Release cycle	Hours to days	Minutes
Version management	Git commit / branch	Version manifest + runtime switch
Rollback method	Revert commit → redeploy	One-click switch to historical version
Difference management	Code conditional branches	Config isolation + directory isolation
Quality assurance	Testing + Code Review	Build-time validation + protocol constraints

When writing pages, the engineer is the sole operator; when assembling pages, the system must allow operations, product, and engineers to each complete their work within their own responsibility boundaries.

When writing pages, release is an engineering action; when assembling pages, release must become a product action — at least in most scenarios.

This is also why "making the component library bigger" cannot naturally evolve into a page platform. A component library optimizes the coding experience; a page platform solves the page production pipeline. It is not a case of quantitative change leading to qualitative change — their fundamental goals are different.

IV. Why the Component Library Fails Here

If you treat the component library as the center of the entire system, four obvious problems arise.

4.1 The Backend Cannot Understand Components

A React component is an implementation, not a protocol.

What the backend system truly needs to know to present a component for operations use is:

What it is called (key / name)
Which category it belongs to (category)
What the preview looks like (preview)
Which fields can be configured (config)
Which fields are required (required)
What data it depends on (fetchArgs)

If this information only exists in the component source code, the backend cannot consume it reliably. You ultimately need to extract a layer of metadata outside the code.

For example, a HomepageBanner component's React implementation may have 20+ props, but the metadata that the backend and editor really need looks like this:

{
  "key": "HomepageBanner",
  "version": "2.1.0",
  "category": "hero",
  "preview": "/previews/homepage-banner.png",
  "fetchArgs": { "api": "getBannerData", "params": ["region", "lang"] },
  "config": [
    { "type": "input", "key": "title", "label": "Main title", "required": true },
    { "type": "image", "key": "bgImage", "label": "Background image" },
    { "type": "select", "key": "layout", "label": "Layout mode", "options": ["left", "center", "right"] }
  ]
}

Since this metadata layer is unavoidable, the system's center should shift to the protocol, rather than continuing to revolve around component implementations.

4.2 The Editor Cannot Directly Reuse Developer Interfaces

The props interface designed for developers is fundamentally different from the editing form designed for operations.

Developers can tolerate mixed semantic parameters like items, layout, theme, fetcher, fallback; operations cannot. Operations need to see clear, verifiable, and visual configuration items like "title text", "button color", "image upload", "display count", "auto carousel", etc.

The following diagram shows how the editor generates the configuration panel that operations see based on the protocol:

Therefore, if the editor aims to achieve WYSIWYG, it cannot directly reuse component props; it must dynamically generate forms, validation rules, and preview behavior based on a unified protocol. This protocol serves as the "translation layer" between the component and the editor, converting developer semantics into operation interfaces that operations can understand.

4.3 SSR Cannot Rely Solely on Components to Infer Data Requirements

Server-side rendering needs to answer not "how to render," but "what data does this page depend on during build-time and runtime?"

If data dependencies are scattered inside component implementations — for example, written in useEffect or custom hooks — the build system cannot easily perform pre-validation, pre-fetching, dependency analysis, and error interception. As a result, problems that should be exposed during build-time are dragged to the online request stage, and users see a blank page or an error page.

This is another key reason why we protocolized components: by explicitly declaring data dependencies through the fetchArgs field, both the build system and runtime can understand the page's data requirements and structural constraints without intruding into the implementation details of the component. The builder can batch-validate the data interface accessibility of all pages during the compilation phase, rather than waiting until a user visits to discover that a certain API returns 404.

4.4 Version Management Cannot Be Tied to the Source Repository

Git can manage source code versions, but it is not a page runtime versioning system.

When you need to support canary, second-level rollback, and multiple versions coexisting, what really works is a release manifest and runtime loading mechanism, not "reverting a commit and redeploying." For high-frequency operational scenarios, this engineering pipeline is too heavy, too slow, and too risky — a full redeployment rollback could affect all pages across all sites, while you may only want to roll back a single change on a single page.

What a page platform needs is version management granularity at the page level or even the component level, not at the repository level.

V. What We Eventually Added Was Not More Components, but Four Layers of Capabilities

In our repository, what finally took shape were four collaborative layers, rather than a single UI library.

5.1 Layer 1: Component Library

The component library still exists and remains important. multiple-site-components provides component implementations, local preview capabilities, and shared component assets across systems.

But its responsibility has been narrowed: it is responsible for "how to implement components," not "how to produce pages." Each component, in addition to React code, must also include a config.json protocol file that declares its metadata, configurable items, and data dependencies. The component library is no longer the center of the system, but the raw material supplier for the system.

5.2 Layer 2: Admin System

The admin system (multiple-site-admincp) is responsible for turning components into manageable page materials and pages into maintainable business objects.

In this layer, operations care not about React APIs, but about:

Which components are available? (based on the category and preview in the protocol, display a component marketplace)
How to orchestrate the page structure? (drag and drop components, adjust order and hierarchy)
Which versions have been published? (version list, publish status, publish time)
How to roll back when something goes wrong? (one-click revert to any historical version)

The admin system does not need to understand the component's internal code; it only needs to understand the protocol.

5.3 Layer 3: Standalone Editor

We made the editor a standalone package, page-editor, rather than embedding it inside the admin page. The benefits are very direct:

Independent versioning: The editor has its own version number (currently iterated to 2.8.x) and can be independently released, canaried, and rolled back.
Host decoupling: The admin system can upgrade its framework or revamp its UI without requiring a synchronous editor refactor; conversely, new editor features do not block admin releases.
Runtime isolation: Through iframe embedding and bridge communication, the editor's React version, styles, and global state do not pollute the host admin system at all.
Multi-host reuse: If we need to create a mobile editor, mini-program editor, or allow other product lines to integrate in the future, the editor can be reused directly.

This means that editing capability itself becomes a platform capability, not just a page module within the admin.

5.4 Layer 4: Versioned SSR Service

The SSR part is also not simply "rendering React into HTML." In the repository it is split into Release and Renderer:

Release (build & publish): Reads page configurations and component protocols, executes the build pipeline (config parsing → dependency collection → data pre-fetch → code generation → artifact packaging), and finally outputs versioned deployable artifacts and a version manifest.
Renderer (runtime rendering): Receives user requests, finds the corresponding page artifact based on route and version rules, performs SSR rendering, and returns HTML; also handles cache management, canary traffic splitting, and version switching.

This split is critical because it separates "artifact generation" from "online running" into distinct operations. Only then can the page platform truly support version coexistence, canary validation, and quick recovery — rolling back no longer means "rebuild + redeploy," but "point the version pointer back to a previously built artifact."

VI. The Real Watershed Is Shifting from Component Thinking to Protocol Thinking

If I had to summarize this shift in one sentence, it would be:

A component library focuses on "how to reuse implementations"; a page platform focuses on "how to constrain collaboration."

Once the system simultaneously contains a component library, admin system, editor, builder, and SSR runtime, you must have a stable contract shared across systems. This contract cannot be the source code of a React component; it must be a protocol.

The value of a protocol is that it allows different systems to collaborate around a single source of truth:

Admin uses the protocol to display component metadata, letting operations know what components are available and what each can be configured with.
Editor dynamically generates configuration panels based on the protocol, without needing to write a separate editing UI for each component.
Build system validates page configuration legality, collects data dependencies, and generates optimized artifacts based on the protocol.
SSR runtime understands page structure and data requirements based on the protocol and Manifest, determining routing, caching strategies, and versioning.

This is the most essential difference between a page platform and an ordinary component library. The core of the former is inter-system collaboration, while the core of the latter is development-time reuse. The protocol is the common denominator of the five subsystems, allowing each to evolve independently — as long as they adhere to the protocol, they will not break other systems.

VII. The So-Called "Page Platform" Is Essentially a Page Production Pipeline

When the number of pages, update frequency, and participating roles all increase, a page is no longer a piece of static code, but a continuously running production chain.

In this chain, React components are certainly important, but they are only one link. Without an admin system, pages cannot be operated; without an editor, non-technical users cannot participate; without build and versioned SSR, pages cannot be reliably launched and rolled back.

From this perspective, looking back at the title, "abandoning the component library" does not deny the value of components; it denies an overly optimistic judgment: believing that as long as you make components comprehensive enough, the page system will naturally grow.

The opposite is true. The component library is often just the starting point. The truly difficult part is how to string together components, configuration, editing, building, publishing, and runtime management into a sustainable platform.

We summarize the core problems solved and key outputs at each stage of the entire chain below:

Stage	Responsible System	Problem Solved	Key Output
Component development	Component library	Provide reusable UI units	React component + config.json
Protocol declaration	Component library	Make components understandable by other systems	Standardized protocol file
Page orchestration	Admin system	Enable operations to assemble pages	Page config JSON
WYSIWYG	Editor	Reduce error cost	Live preview + config validation
Build artifact	Release	Pre-validation + optimization	Deployable artifact + Manifest
Version release	Release	Support canary and incremental updates	Version number + publish record
Online rendering	Renderer	Route by version + cache	HTML response
Failure recovery	Renderer	Second-level rollback	Version pointer switch

VIII. Conclusion

Many front-end systems, as they mature, evolve from "engineering projects" into "platform products." This is not because the team suddenly wants to go big, but because business complexity forces the system to upgrade.

When your pages already have to face multi-site, multi-role, high-frequency changes, canary, and rollback, continuing to define the problem as "component reuse" is too narrow. What you need is not a larger component library, but a system capable of producing, publishing, and managing pages.

If you are going through a similar phase, ask yourself three questions:

Who maintains your pages? If only engineers, a component library is enough; if operations and product also need to participate, you need an operation interface.
How high is your release frequency? If monthly updates, a traditional pipeline is enough; if daily or even hourly updates, you need second-level publish and rollback capabilities.
How many sites do you face? If only one site, conditional branches might suffice; if multiple merchants and regions, you need structured difference governance.

If the answers to all three questions point to the latter, then the component library is your starting point, not your endpoint.

This is the real reason we moved from a component library to a page platform.

Next article will explore an even more core issue: since the platform's core is not component implementation, how should the protocol that connects the admin, editor, build system, and SSR be designed?

0 Comments

Leave a Comment