Component Template Management for Qunar's Special Activity System

The Special Activity System is a platform built by Qunar's accommodation business unit to enable rapid construction of promotional activity pages, replacing the previous labor‑intensive process that required developers to spend days iterating designs and code.

The front‑end code of the system is organized into several layers: View Layer for page rendering and user interaction, Command Layer for editing state management and automatic data updates, Controller Layer for dispatching user actions to API methods, Component Layer for registering, creating and loading components, Service Layer for data transmission and configuration loading, and Extra Layer for auxiliary functions such as resource management and template handling.

As component types and themes proliferated, three main problems emerged: (1) lack of reusable logic across components, (2) themes were not loaded on demand, and (3) component development was tightly coupled to the special‑activity system, hindering rapid iteration.

To address these issues, a separate Component Template Platform was created. The platform decouples components from the special‑activity system, leaving only a lightweight container in the system while actual component implementations are fetched from the platform.

Below is the original component file structure (simplified for illustration):

/nav/singleNav
├── _style.scss          // component theme styles
├── config.js            // configurable data and defaults
├── formConfig.mustache  // configuration panel template
├── index.js             // entry file, lifecycle management
└── template.mustache    // DOM structure template

After separation, only the container files remain in the system:

/game/miniGame
├── config.js            // container configuration
├── formConfig.mustache  // container configuration template
└── index.js            // loads component templates and performs conversion

The component configuration is stored as JSON in the template platform. An example configuration for a prize‑draw component is shown below:

{
  "prizeConfig": {
    "label": "游戏配置",
    "type": "group",
    "value": {
      "prizeDurationStart": {
        "label": "抽奖开始时间",
        "type": "datetime",
        "value": ""
      },
      "prizeDurationEnd": {
        "label": "抽奖结束时间",
        "type": "datetime",
        "value": ""
      },
      "prizeDrawCount": {
        "label": "用户抽奖次数",
        "type": "text",
        "value": 1
      },
      "countType": {
        "label": "计数方式",
        "type": "boolean",
        "text1": "日次数",
        "text2": "总次数",
        "value": "true"
      }
    }
  }
}

When an editor opens the activity page, the system dynamically loads this configuration, generates a configuration panel, and binds it to the component, achieving on‑demand loading and customization.

The new architecture brings several benefits: independent development and versioning of components, lightweight system containers, on‑demand theme loading, reusable inheritance relationships, and a foundation for component usage monitoring and automated testing.