How JD’s Order Module Achieved One‑Code‑Three‑Platform Success with Taro

This article details JD.com’s six‑month engineering effort to refactor its high‑traffic order module into a single Taro codebase that runs on Android, iOS and HarmonyOS, covering business background, preparation, multi‑mode adaptation, core challenges, quality assurance, efficiency gains and the resulting business impact.

JD Retail Technology
JD Retail Technology
JD Retail Technology
How JD’s Order Module Achieved One‑Code‑Three‑Platform Success with Taro

Background

In July 2025 the Ministry of Industry and Information Technology required HarmonyOS to achieve feature parity with iOS and Android by the end of the year. JD.com’s order module, handling over one billion daily page views, needed to support multiple UI modes (large‑font, dark mode, large screen, multi‑language, foldable devices) on three platforms. The team aligned the HarmonyOS version with Android and iOS and extended the Taro “one‑code‑multiple‑platform” approach.

Preparation

Scenario Mapping

The module contains 15 pages, 22 overlay layers and more than 400 functional points. Senior developers and AI tools produced 209 detailed scenario documents. Redundant code and technical debt were removed.

Task Decomposition

More than 390 concrete tasks were created, grouped by milestone, with explicit dependencies and batch‑testing schedules.

External Dependencies

Three categories were identified: Taro SDK components, H5/mini‑program navigation links, and cross‑module protocols. Over 60 SDK components (pull‑to‑refresh, network library, dialogs, WebView, analytics, cache, native communication, etc.) were catalogued and prioritized.

Key Technical Challenges & Solutions

Multi‑Mode Adaptation

A unified device‑state store using zustand and a custom useDevice.ts hook provides real‑time theme, language, font‑size and accessibility handling.

import { create } from 'zustand';
export enum Theme { LIGHT = 'light', DARK = 'dark' }
export enum Lang { ENUS = 'en-US', ZHCN = 'zh-CN', ZHTW = 'zh-TW' }
export enum Age { YOUNG = '2', NORMAL = '0', OLD = '1' }

Theme and locale changes are subscribed via Taro APIs:

const themeChange = useCallback((_theme) => {
  if (_theme !== theme) setTheme(_theme);
}, [setTheme, theme]);

useEffect(() => {
  Taro?.onThemeChange?.(themeChange);
  Taro?.onLocaleChange?.(langChange);
  return () => {
    Taro?.offThemeChange?.(themeChange);
    Taro?.offLocaleChange?.(langChange);
  };
}, [themeChange, langChange]);

Stability of the New Architecture

A gray‑release strategy released core transaction flows first, then long‑tail scenarios after monitoring. Crash, white‑screen and bundle‑download issues were fixed. A monitoring stack tracks first‑screen time, API latency, Taro exceptions and business errors.

export const reportOrderBusinessErrorToDra = async (
  scene,
  functionId = '',
  netWorkResultCode = '',
  extraMap,
  requestParam = ''
) => {
  const reportSwitch = (await getOrderCustomErrorReportSwitch) ?? false;
  if (reportSwitch) {
    const currentPage = useDeviceStore.getState().currentPage || '';
    const orderSourceKey = PAGE_TO_ORDER_SOURCE_KEY_MAP[currentPage] || 'pages/orderNew/list/index';
    const exception = JSON.stringify({ scene, code: netWorkResultCode, isTaro: '1', extraParams: extraMap });
    const error = {
      errCode: getDraErrorCode(),
      errMsg: scene,
      errType: '2',
      functionId,
      url: orderSourceKey,
      occurTime: Math.floor(Date.now() / 1000),
      httpResp: netWorkResultCode,
      postData: requestParam,
      exception,
    };
    Taro.JDDRA.reportError(error);
  }
};

Data Consistency

During gray release a “gold‑stone” metric comparison was introduced; any scenario with >10 % deviation triggered a standardized investigation, code diffing and corrective deployment.

Long‑Tail Issue Governance

AI‑driven scanning of API inputs combined with data sampling, alerting and rapid‑fix loops systematically eliminated residual edge‑case bugs.

Code Quality Assurance

Code Review

30+ cross‑functional review sessions involved analysts, developers, architects and testers. Tasks were labeled by importance and complexity to focus reviews.

ESLint Enforcement

A unified ESLint configuration extended for Taro and order‑specific rules was enforced via Husky and lint‑staged. Weekly reports highlighted violations.

Efficiency Improvements

AI‑Assisted Conversion

AI tools translated legacy mCube, TN and native code into Taro components, standardizing component mapping, lifecycle handling and state management, followed by self‑testing.

Collaboration Workflow

Daily stand‑ups identified risk points early; critical blockers prompted immediate schedule adjustments. Transformation deadlines were synchronized with business releases.

Platform Tooling Optimization

Initial HarmonyOS builds took eight hours. Collaboration with the Deco platform team streamlined build, release and bundling processes, achieving more than a two‑fold speedup.

Business Impact

216 documented business scenarios forming a searchable knowledge base.

On‑time December launch and stable traffic migration.

≈90 % reduction in HarmonyOS logistics‑map complaints.

First Taro‑based one‑code‑multiple‑platform deployment for core transaction flow, improving development efficiency.

Enhanced cross‑platform experience supporting rapid innovation.

HarmonyOSPerformance MonitoringTaroOrder Module
JD Retail Technology
Written by

JD Retail Technology

Official platform of JD Retail Technology, delivering insightful R&D news and a deep look into the lives and work of technologists.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.