Resolving Frontend Development Conflicts with the “QianJiBian” Modular Solution

Background

Frontend developers in the industry frequently receive business requests such as adding mixed‑type feeds (text, images, short videos) or creating specialized channels with calendar and feed functions. Developers, however, face tight schedules and limited manpower, leading to growing friction between business and development teams.

Pain Points

From a business perspective, needs are scattered, chaotic, and unclear, resulting in fragmented implementation, duplicated effort across domains, and decisions based on experience rather than data. From a technical perspective, development suffers from low efficiency, difficulty in knowledge retention, and lack of standards, causing repeated resource consumption, inconsistent UI, and high maintenance costs.

Solution Exploration

Primary Solution

Leveraging the previously deployed TaoUI cross‑platform component library, a set of standardized industry modules (the “Industry Cube”) was created. Data‑source‑driven UI allows operations to configure DSL‑based data sources that assemble data with components, especially feeds, reducing pressure on developers.

However, the primary solution revealed several issues:

Configuration is complex and inaccessible to operations.

Too many configuration items increase learning cost.

Multiple data sources cause excessive request volume and long rendering times.

Fixed component styles cannot meet diverse design needs.

Lack of “one‑to‑one” personalization for users.

No data collection for module performance analysis.

Advanced Solution – “QianJiBian”

The “QianJiBian” approach introduces a product‑supply platform that guides business decisions, supports rapid strategy changes, and frees development capacity.

Design Principles of “QianJiBian”

1. Standardized UI Design Specification – Establish a unified design framework while allowing industry‑specific elements (colors, layouts) to vary, enabling reusable “Industry Cube” modules.

2. Component Theme Smart Control – Abstract mutable component styles into “themes”. Data‑source‑driven rendering applies different themes to the same standardized component, achieving “one‑to‑many” personalization.

3. Module Data‑Source Production – Introduce a “Component View Object (CVO)” that maps configured data sources to components. Generated data‑source IDs are bound to module styles, and the front‑end fetches rendering configurations and data via a unified API.

4. General Module Strategy Generation – Combine standardized atomic components to form modules. With multiple style variations per component, numerous module configurations can be generated, each linked to a strategy ID. Strategies are distributed to modules via internal tools, enabling “one‑to‑many” personalization.

5. Consume “QianJiBian” Strategies – Generated strategies are applied in downstream systems (e.g., “Zebra”, “Ark”) to drive module rendering according to the selected strategy.

Outlook

Future work will focus on expanding the material supply chain through intelligent UI generation, enriching the strategy library, and modularizing complex interaction flows (e.g., card opening) to further improve operational efficiency.