Building an Efficient Frontend Component System: iQIYI Knowledge’s Approach

Componentization: A Frontend Decoupling and Efficiency Tool

Componentization is widely recognized for code reuse and improving development efficiency across client and frontend development for mobile, web, PC, TV, and other platforms.

Background

The iQIYI Knowledge web frontend team explored and practiced an efficient frontend componentization solution tailored to its business characteristics.

Why Componentization?

As frontend business evolves, code size grows and logic becomes more complex. Componentization aims to improve efficiency by delivering usable, intuitive, composable business forms.

Component Users

Industry front‑end componentization can be divided into three user‑oriented categories:

For operations staff : they assemble pages like LEGO blocks, with special components customized by developers for static or fixed functions such as lottery, Q&A, payment.

For designers : they convert design drafts directly into frontend code, using tools like Alibaba’s imgcook, with complex logic handed to developers.

For developers : the traditional model, focusing on dynamic pages that require backend APIs; common components are extracted for reuse.

iQIYI Knowledge’s componentization belongs to the third category, designed for developers. Reusing components reduces redundant code, decouples functionality and logic, and improves extensibility and maintainability.

Business Scenario

Projects are numerous and independent, yet product consistency must be maintained. Although each project is isolated, they share common UI entities (courses, teachers, shops) and generic UI elements (dialogs, loading). Therefore, component extraction is essential.

Difference from Mobile Componentization

Mobile teams split components vertically by business and functionality (e.g., player component includes UI and control logic). Web frontend componentization focuses more on the UI layer; logic stays in pages, making UI elements highly reusable.

Goals

Code reuse and higher development efficiency by dividing components horizontally and vertically.

Independent development and maintenance of components, decoupled from projects.

Clear input/output parameters with validation and appropriate routing (internal front‑end routing or external location.href).

Documented components with online debugging to lower usage barriers.

Overall Design

Component hierarchy is crucial. The design separates components into layers and categories: basic components (UI and utility) and business components (item, Card, block, functional, page).

Basic UI components include text, image, button, layout, loading, toast, etc.

Business components examples:

Item component : the smallest unit, such as a list item, grid item, carousel image.

Card component : serves a Card‑based data structure from the backend; composed of multiple Item components.

Block component : UI block like comment or rating.

Functional component : specific business functions like player, publisher, share.

Page component : a route component that can be used as a micro‑frontend.

Design Principles

Unified technology stack.

Single responsibility – each component does one thing well.

No side effects – fixed output for given input.

Configurable – clear input/output and parameter validation.

Appropriate granularity – balance between maintainability and reusability.

Reasonable bundle size for fast page loading.

Comprehensive documentation.

Data Protocol

Initially the H5 mobile homepage used a backend‑driven Card data model. A frontend data protocol converts backend Card data into a frontend structure, enabling reuse of Card and Item components. Converters adapt various API responses to this protocol, isolating component code from backend changes.

UI Implementation

Typical UI components such as Course List Item and Course Grid Item combine basic image and text components. Image component retains native img features while adding lazy loading, placeholders, and format selection. Text component supports single‑line and multi‑line truncation.

Components must adapt to mobile, tablet, and PC screens; dimensions are defined by the consumer, and responsive styles can be exported for different devices.

Build Tools

Basic utility libraries are built with Rollup to produce lightweight ES and UMD bundles. The UI component library uses Vue and Webpack, supporting multiple entry points and on‑demand loading.

import { item40000, item40001, item40010, item40011 } from '@iqiyi-kpp/ui-biz-vue'

To reduce bundle size, Babel runtime helpers are externalized, core‑js is disabled, and webpack externals are used for shared dependencies.

Technical Documentation

A Storybook‑based documentation site provides interactive demos, live debugging, and versioned component references, improving usability and communication.

Conclusion

The iQIYI Knowledge web frontend component library, continuously refined, achieves the full goals of componentization: independent development, testing, publishing, and extensive reuse across business projects. Ongoing challenges include managing component proliferation, bundle size, and ensuring team adoption, but a well‑designed system greatly reduces coupling and maintenance costs.