Why We Abandoned the Component Library in Favor of a Page Platform

When a cross-border standalone site needs to tweak a Banner for Black Friday promotions, and the frontend team has to go through the full build-and-deploy pipeline just for that change, “making the component library complete” becomes the quintessential engineering false proposition.

Many frontend teams go through a seemingly logical phase: first build a React component library, covering buttons, carousels, cards, navigation, forms, and then believe that page composition problems will naturally be solved as the number of components increases.

This approach typically works for single-site, low-frequency-update projects maintained by frontend engineers. But when the business expands to multi-country sites, frequent marketing campaigns, and non-developer maintenance, the component library is no longer the answer itself — it can only be a part of the answer.

What we ended up doing was not “providing more components,” but “providing a page production system.” The title says “abandoning the component library” of course has some sensationalist spin; the reality is not to discard components, but to demote them from final deliverables to basic materials within the platform.

1. The Component Library Solves Reuse, Not Production

Component libraries are naturally good at three things: unifying visuals, reusing interactions, and improving development efficiency.

They solve the question: “When a developer writes a page, what ready-made building blocks can be used directly?” This is important, but it assumes several premises:

Pages are still written by programmers.
Page changes go through code submission, testing, building, deployment.
Page structure is determined by code, not by configuration.
Version management for pages still relies on Git and deployment systems.

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

Once business complexity surpasses this stage, you'll find that “having components available” and “being able to efficiently deliver pages” are completely different things. You have to face real-world problems beyond engineering: How can pages be maintained by non-technical staff? How to manage versions for 500+ pages? How to roll back in seconds without redeployment? The component library cannot answer these.

2. Complexity Evolution of Multi-site Business

Taking our smart hardware cross-border standalone site as an example, what really gave us headaches was not “whether we have a Banner component,” but the following four pain points that arose with the business:

2.1 “Version Split” Under the Same Route

The same route may correspond to different page versions at different release times, under different grayscale stages, and in different countries.

For example, the path /product/dual-lens-cam — during grayscale, 10% of users see the new Hero block, while 90% still see the old version. At the same time, users in different countries use different product data interfaces and different configuration parameters. This means “the same page” can actually have 4 version instances live simultaneously.

At this point, a page is no longer a piece of React code, but 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 Zero-sum Game Between Operations and Development Efficiency

Operations need to change promotional copy, marketing needs to swap campaign images, product wants to adjust module order. If every time you go through the chain of “submit requirement → engineer modify code → test → release,” system throughput will quickly bottleneck on human resources.

We looked at actual work order data and found that such “non-structural modifications” accounted for over 60% of the frontend team's daily workload. Before the page platform, a simple Banner copy change took an average of 1~2 working days from requirement to launch; after the platform, operations could complete and publish it independently within 10 minutes.

The component library cannot directly hand pages over to non-technical users for maintenance, because it is designed for developer APIs, not for an operations interface.

2.3 “Hard-coded” Decay of Differentiation Logic

The most common mistake in multi-site systems is treating “multi-site” as “copying a few pages.” But the reality is:

UI styles can differ: Brand colors, typography, fonts, spacing may vary.
Data interfaces can differ: Product API, promotional API domains and parameter structures are independent.
Some components are only available in specific countries: For example, Country A has a “trade-in” module, Country B does not.

If all these differences are handled via React conditional checks — if (country === 'US') { ... } — scattered across dozens of components, you will eventually end up with a crumbling building that nobody dares to touch. Every line change risks affecting other regions.

2.4 Entanglement of Rendering Path and Runtime

For standalone e-commerce businesses, client-side rendering (CSR) alone is often insufficient; SEO and first-screen performance push us toward SSR and pre-building.

When data dependencies are buried inside components (e.g., written in useEffect), the build system cannot easily perform validation, data prefetching, and error interception in advance. The result is that issues that should be caught during build time get dragged to the online request phase, leaving users staring at a blank page.

What you need to handle is not just the component tree, but also build artifacts, route mapping, caching, and rollback strategies. In the entire chain, the component library only covers the step of assembling the React component tree.

3. Paradigm Shift: “Writing Pages” vs. “Assembling Pages”

The biggest difference between the two is not in the UI, but in the system boundaries and delivery pipeline:

Dimension	Writing Pages (Component Library Mode)	Assembling Pages (Page Platform Mode)
Core Object	React source code (JSX / TSX)	Structured configuration protocol (JSON Schema)
Operator	Frontend engineer	Operations + Product (frontend provides material contracts)
Release Method	Git push → CI/CD → full deployment	Backend click publish → incremental configuration rollout
Deployment Cycle	Hours to days	Minutes
Version Management	Git commit / branch	Version manifest + runtime dynamic route switching
Rollback Method	revert commit → rebuild and deploy	One-click switch Manifest version pointer in database
Difference Management	Code conditional branches (`if/else`)	Protocol isolation + directory on-demand loading
Quality Assurance	Testing + Code Review	Build-time Schema static validation + data interface checking

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

This is also why “making the component library bigger” cannot naturally evolve into a page platform. The component library optimizes developer experience; the page platform solves production relationships.

4. Schema: The Contract Decoupling Development and Operations

A React component is an implementation, not a protocol. The props interface designed for developers and the editing form designed for operations are fundamentally different.

Developers are comfortable with parameters like items, theme, fetcher. Operations need to see intuitive visual controls like “title text”, “image upload”. Therefore, the system's center should shift toward protocols, rather than continuing to revolve around component implementations.

We introduced a config.json protocol file for each component, serving as a translation layer between developer semantics and operations control panel:

{
  "key": "DualLensCameraHero",
  "version": "1.2.0",
  "category": "hero",
  "preview": "/assets/previews/hero-dual-lens.webp",
  "fetchArgs": { 
    "api": "getProductDetails", 
    "params": ["productId"] 
  },
  "config": [
    { "type": "input", "key": "title", "label": "Camera main title", "required": true },
    { "type": "image", "key": "bgImage", "label": "Background image" },
    { "type": "select", "key": "layout", "label": "Text alignment", "options": ["left", "center"] }
  ]
}

The reason we designed fetchArgs is to extract data dependencies from inside components, allowing the build system to verify at compile time whether the component's data interface is available, rather than waiting until a user visits the page to discover a 404 on the interface.

5. The Four-layer Architecture We Implemented in Practice

To keep this system stable, we built the following four collaborative layers:

5.1 Overall Collaboration Flow

Below is a comparison of the delivery workflow under the traditional component library mode vs. the page platform mode:

5.2 Design of the Standalone Editor Sandbox

We isolated the editor into its own @site-builder/editor package, rather than embedding it directly into the admin page.

Runtime Isolation: The editing area is embedded via an Iframe. This ensures that the editor's React version, CSS styles, and global state are completely isolated from the host admin panel. No matter what the editor does, it will not slow down the admin panel's loading or cause style pollution.
Bidirectional Communication: The host admin panel and the Iframe editor communicate through a standardized postMessage Bridge.
Independent Versioning: The editor has its own independent iteration cycle, allowing new features to be released directly without requiring the host admin panel to release a new version.

5.3 Design of the Versioned SSR Service

The SSR part was split at runtime into two parts: Release (offline build) and Renderer (runtime rendering):

Release: When operations click publish, it reads the page's JSON config, analyzes which components are used, performs on-demand dependency packaging, and finally outputs a versioned deployable artifact and a Manifest that declares the page's data dependencies.
Renderer: It is a persistent Node.js SSR rendering service. It does not contain specific component source code or compilation logic. It is only responsible for querying, based on routing rules, which version Manifest should be used for the current region/grayscale strategy, then loading the corresponding Release static artifact from CDN, fetching the required data on the server side, and rendering the HTML.

Because the two are decoupled, rollback and grayscale become very lightweight: rollback requires no container deployment — operations simply point the version pointer back to a previously built Release ID in the admin panel, and the Renderer will automatically load the old version artifact on the next request. The entire process takes effect within 1–2 seconds.

6. In Conclusion: From “Component Thinking” to “Protocol Thinking”

The component library focuses on “how to reuse implementations,” while the page platform focuses on “how to constrain collaboration.”

When pages need to deal with multi-site, high-frequency changes, grayscale, and rollback, continuing to define the problem as “component reuse” is too narrow. What we need is not a larger component library, but a page production pipeline centered around a protocol (Schema).

The protocol is the common denominator of five subsystems, allowing each subsystem to evolve independently; as long as they adhere to the protocol, they will not break other systems. This is the true reason we moved from a component library to a page platform.

0 Comments

Leave a Comment