How NetEase Yanxuan Built a Cross‑Framework Component System with Web Components

Background

NetEase Yanxuan’s front‑end stack has evolved from jQuery, NEJ, Angular to React. Each upgrade required extensive component library adjustments, leading to high maintenance cost, visual inconsistency, and difficult upgrades across more than 100 B‑end business systems.

High maintenance cost : Migrating component libraries when the stack changes and handling frequent business adjustments require duplicated logic across different framework “shells”.

Inconsistent visual interaction : Different UI libraries (Shark for Angular, Ant Design for React) cause slight visual differences.

Upgrade difficulty : Strong coupling forces repeated painful migrations for each new framework.

To address these pain points, Yanxuan explored an environment‑agnostic, easily integrable, fully autonomous cross‑framework component development model.

Technical Selection

Cross‑Framework Component (CFC)

A CFC is a reusable module that can be used by any front‑end framework, breaking the limitation of framework‑specific component libraries.

Web Components

Web Components consist of three specifications: Custom Elements, Shadow DOM, and HTML Templates, which enable native, framework‑independent component creation.

Advantages : framework‑agnostic, native browser support, supported by major frameworks, aligns with future component trends.

Disadvantages : limited browser compatibility (full support only in Chrome and Firefox, polyfills needed for IE/Edge), lack of built‑in data binding, state management, and higher development cost.

Solution Comparison

Yanxuan evaluated several solutions on development efficiency, UI library reuse, performance, and learning cost, finally choosing a React‑based core that is compiled to Web Components and then wrapped for each target framework.

Cross‑Framework Component Development Scheme

Architecture Design

The architecture is divided into five layers from bottom to top: Base Library, Component Layer, Bridge Layer, Encapsulation Layer, and Application Layer.

Base Library : Underlying tech stack, UI library, and utility libraries.

Component Layer : Core component logic written in React, reusable across UI libraries.

Bridge Layer : Uses Direflow to convert React components into Web Components, packaged as UMD and delivered via CDN with lazy loading.

Encapsulation Layer : Handles source loading, parameter passing, event conversion, and provides a unified npm package that matches existing component usage.

Base Package : Files that are framework‑agnostic and needed for Web Component reuse.

Package Service Management : Manages dependencies and load order.

Technical Details

Direflow

Direflow is a third‑party tool that transforms React components into Web Components by leveraging the lifecycle hooks of Web Components. It wraps the component, exposing it as a custom element.

Encapsulation Layer

The encapsulation layer acts as glue, providing:

Loading of Web Components and their dependencies.

Parameter initialization and change detection.

Event handling: converting callbacks to framework events and global communication via Event.

Base package output: scripted configuration for one‑click generation, keeping upgrade and refactor costs low.

Implementation Issues

Conversion Capability

In practice, React and Angular wrappers preserve component capabilities such as props, events, and routing, but slot/template features cannot be customized from React to Angular.

Most business scenarios can avoid slots by designing data‑driven views.

Base Package Reuse

Direflow outputs Web Components that still depend on React and UI libraries, resulting in large bundle sizes (~1.2 MB). By extracting React, UI libraries, and Direflow into shared CDN packages and using lazy loading, the core business bundle is reduced to a few dozen kilobytes.

Additional measures include namespace isolation, version convergence (limiting React versions to two per environment), dependency management, and CDN acceleration.

Style Handling

Shadow DOM provides isolation, making CSS handling more complex:

Inside Shadow DOM: inject styles at the root using tools like style‑it.

Outside Shadow DOM: global UI elements (toast, modal) require dynamic CSS loading with unique namespaces.

Third‑party UI styles (e.g., Ant Design) also need resource reuse and dynamic loading.

Development and Usage Practices

Yanxuan integrated the development template into a CLI. Developers can create a business component in five steps, and users can consume the component with the same workflow as native framework components because the encapsulation layer hides the underlying complexity.

Value Analysis

Efficiency boost : Development effort can be reduced to about 60 % of the previous approach.

Environment isolation : Decoupling framework and version enables smooth upgrades by only adding a new encapsulation layer.

Consistent interaction and visual : A single codebase guarantees uniform appearance across different stacks.

Conclusion

Cross‑framework component development is a future trend for component libraries. A truly autonomous library should be environment‑isolated and framework‑agnostic. Yanxuan’s solution, built on Web Components, demonstrates this approach, and future Web Component enhancements will further strengthen its viability.