How JD’s Mart Page Maker Revolutionizes Front‑End Development with Zero‑Code Visual Building

Preface

When an organization reaches a certain development scale, visual page building becomes the most effective way to reduce repetitive development and boost productivity. Fixed business scenarios lead to repeated work, and even component‑based reuse cannot eliminate the two‑to‑three‑day effort required for each new requirement. A more flexible, thorough solution—ideally zero‑code response—is needed.

Visual page building systems allow demand parties to assemble complex pages quickly through simple editing, dramatically improving response efficiency and freeing developers to focus on higher‑value tasks.

What Is MPM

MPM (Mart Page Maker) is JD.com’s self‑developed marketplace visual building system. Since 2016 it has undergone three major version iterations and now offers a rich set of components and templates.

Rich Component Templates

After four years of service, MPM provides over 30 components and 500 templates covering product, navigation, marketing and other scenarios.

Powerful Configuration Features

MPM pages built by operations support first‑screen direct output via a high‑availability Node layer that aggregates configuration data and renders the initial view, overcoming first‑screen performance bottlenecks.

Additional strong features include:

Floor BI sorting: personalized floor priority based on user attributes.

Automatic tracking: auto‑creates RD identifiers for data statistics, avoiding manual errors.

Page health diagnosis: validates configuration legality, effectiveness, and detects potential component conflicts.

Key Business Support

MPM is the core operation system for JD’s Shenzhen team, supporting major promotions such as 618, Double 11, Double 12, and daily marketing events. In 2019’s Double 11/12, over 90% of JD’s promotional venues were built with MPM.

MPM Element Design

System elements are the fundamental building blocks that must be considered before designing a system. For a marketplace visual builder, the scope is limited to marketplace pages, not arbitrary pages.

Three Marketplace Characteristics

Marketplace pages have three obvious traits:

Independent Floors

Floors are arranged in a waterfall layout and are largely independent, unlike product detail pages where sections are tightly linked.

Heavy Display, Light Interaction

The primary function is to attract purchases, so most floors consist of material and image displays with minimal complex interactions.

Numerous Business Scenarios

Because marketplaces drive traffic, many business lines compete for placement, resulting in a large variety of business interfaces.

Deriving System Elements

Any visual page builder requires attributes as the smallest configuration unit. Using iH5 as an example, a button’s text is an attribute. However, a pure “control‑attribute” hierarchy is too fine‑grained for marketplace pages, leading to high configuration cost.

MPM therefore adopts a three‑layer configuration:

component

→

template

→

attribute

. This reduces operational cost while preserving flexibility.

To avoid each component handling its own data requests, a unified data source layer is introduced to manage all interface calls.

MPM’s Four System Elements

The four core elements are Component , Template , Attribute , and Data Source .

Component

Components represent business scenarios (e.g., product, flash‑sale, coupon). Each floor is an independent component instance, simplifying the page structure to a floor array rather than a tree.

Components implement common business logic such as navigation positioning or coupon handling. They are registered as global Vue components:

/**
 * Flash‑sale component
 */
import Vue from 'vue';
import utilMixins from './utils';

export default function register() {
  Vue.component('seckill', {
    props: ['params'],
    mixins: [utilMixins],
    data() {
      return {
        // ...
      };
    },
    created() {
      // ...
    },
    methods: {
      // ...
    }
  })
}

Each component receives a

params

prop containing the floor’s configuration data. Templates are injected dynamically, so the component itself does not define a

template

attribute.

Template

Templates provide the UI layer for a component and may contain private logic. A template file follows a custom HTML format:

<!-- Template CSS -->
<style>
  .rank_2212_215 { background: #fff; }
</style>

<!-- Template HTML (Vue) -->
<template>
  <div>
    <p>Welcome to develop a template of MPM!</p>
  </div>
</template>

<!-- Private attributes -->
<script class="extends">
  const com_extend = [{ "name": "标题", "nick": "title", "type": "text" }];
</script>

<!-- Private methods -->
<script class="methods">
  const com_js = {
    priceFormat() { /* ... */ }
  };
</script>

<!-- Lifecycle hooks -->
<script class="hooks">
  const com_vueHook = {
    mounted() { /* ... */ }
  };
</script>

The parser extracts

style

,

template

,

script.extends

,

script.methods

, and

script.hooks

to build the final Vue component.

Attribute

Attributes are the smallest configurable units. MPM supports various attribute types such as date, text, image, color, radio, option, range, etc., each with validation rules (e.g.,

type=url

,

type=id

,

type=char

) and optional regular‑expression checks.

Example attribute definitions (simplified):

[
  { "name": "日期", "nick": "date", "type": "date" },
  { "name": "标题", "nick": "title", "type": "text" },
  { "name": "图片", "nick": "image", "type": "img" },
  { "name": "颜色", "nick": "color", "type": "color" },
  { "name": "单选", "nick": "radio", "type": "radio", "data": [
    { "name": "选项一", "value": 1 },
    { "name": "选项二", "value": 2 }
  ], "value": "1" },
  { "name": "多选", "nick": "option", "type": "option", "data": [
    { "name": "选项一", "value": 1 },
    { "name": "选项二", "value": 2 }
  ], "value": ["1"] },
  { "name": "范围", "nick": "range", "type": "range", "min": 230, "max": 280 }
]

After parsing, a configuration object might look like:

{
  "date": "2020-01-01 00:00:00",
  "title": "我是配置的标题",
  "image": "//a.com/image.png",
  "color": "#FFFFFF",
  "radio": 1,
  "option": [1, 2],
  "range": 250
}

Data Source

Because marketplace pages involve many interfaces, a centralized data source layer manages all requests, supports request merging, and distributes responses.

Each data source is a class defining request parameters, URL, and a callback:

export default class GroupBuying {
  constructor(option) {
    // Parameter handling
    this.params = { activeid: option.groupid };
  }
  // Request URL
  url = '//wqcoss.jd.com/mcoss/pingou/show';
  // Request parameters
  params = {};
  // Callback processing
  callback(result) {
    // ...
    return result;
  }
}

The global Vue component

ds

receives a

mpmsource

prop to select the appropriate data source, instantiate it, and fetch data via a custom requester:

/** Data source center */
import Vue from 'vue';
import requester from './requeter';
import utilMixins from './utils';
import * as dataSourceMap from './data-source-map';

export default function register() {
  Vue.component('ds', {
    props: ['params'],
    mixins: [utilMixins],
    data() { return { result: null }; },
    async created() {
      const { mpmsource } = this.params;
      const DataSource = dataSourceMap[mpmsource];
      const req = new DataSource(this.params);
      const result = await requester.fetch(req);
      this.result = result;
    },
    methods: {
      // ...
    }
  })
}

In a template, the data source is used inline:

<template>
  <ds :params="{ mpmsource: 'groupbuying', ... }" inline-template>
    <p>Fetched group‑buying product count: {{result.list.length}}</p>
  </ds>
</template>

Data sources can define a

batch

object to merge multiple similar requests, limit batch size, and unpack responses back to individual callers.

export default class GroupBuying {
  // ...
  batch = {
    limit: 20,
    merge(reqlist) {
      return { activeid: reqlist.map(req => req.data.activeid).join(',') };
    },
    unpack(result, reqlist) {
      const ret = {};
      reqlist.forEach(req => {
        const key = md5(JSON.stringify(req));
        ret[key] = result[req.data.activeid];
      });
      return ret;
    }
  }
}

Conclusion

We have distilled the four core system elements of MPM based on marketplace scenarios. Future articles will cover editing workflow, save‑publish mechanisms, and same‑origin direct output.

Reference: iH5 – https://www.ih5.cn/