Improving Usability and Efficiency of the Cashier System: Front‑End Architecture Redesign and Component Refactoring

Payment is a critical step in transaction completion, and JD.com to‑home implements payment through a cashier system. Recent months have revealed problems such as low integration efficiency of payment methods and high maintenance costs, prompting a front‑end architectural redesign.

Problems of the Cashier System

The cashier faces two core challenges: security and efficiency . Specific issues include:

Usability : The H5 version supports over 30 business lines, leading to missed test scenarios and unstable payment functionality.

Efficiency : Adding new payment methods incurs high development and testing costs, failing to meet rapid rollout demands.

Component duplication : H5 and RN versions do not share components, causing duplicated effort and high maintenance overhead.

Layering problems : A monolithic entry component exceeds 1000 lines, lacks proper layering, and suffers from high entropy, making debugging difficult.

Design flaws : Low cohesion and high coupling reduce maintainability and testability.

Usability and Efficiency Solutions

The following solutions address the identified problems from both usability and efficiency perspectives.

1. Usability Construction

To improve test coverage, the redesign introduces unit‑testable components, laying a foundation for full‑automation testing. Monitoring, alarm, fallback, and degradation mechanisms are also added to ensure payment availability even when configuration errors occur.

2. Efficiency Problem Solving

Low integration efficiency stems from poor extensibility. The new design enhances scalability and maintainability through component reuse, layering, and clear separation of concerns.

(1) Component Reuse

By analyzing the UI layer and existing components, reusable components are identified (highlighted in yellow in the diagram).

(2) Component Layering

Front‑end development has evolved from native JavaScript to frameworks like Angular, Vue, and React, enabling declarative UI composition. Layering is introduced to achieve separation of concerns:

Base Component Layer : Generic UI elements (e.g., DJText, DJImage).

Business Component Layer : Components that implement specific business UI (e.g., CashierPayTypeItem).

Business Glue Layer : Controls data flow and logic, communicating with state managers (Redux/MobX).

Page Logic Layer : Top‑level orchestrator for the page.

Each layer is illustrated with diagrams and sample React code.

Sample code for a business component (React):

<View style={styles.bankBox}>
    <DJTag style={styles.bankTag} type={'emptyTag'} />
    <DJImage style={styles.logoUrl} source={item?.logoUrl} />
    <DJText style={[styles.mainTitle]}>
        {item?.mainTitle && item?.mainDesc ? `${item?.mainTitle}, ${item?.mainDesc}` : item?.mainTitle}
    </DJText>
    {ifShowArrow && <DJIconArrow size={13} style={styles.iconArrow} />}
</View>

Sample code for a glue component (React):

<View style={[styles.container, isLast && styles.isLast]}>
    <View style={styles.wrap}>
        <DJImage source={payMode?.iconUrl} style={styles.iconUrl} />
        <View style={styles.box}>
            <ItemHeader payMode={payMode} checked={checked} source={source} />
            {/* Main activity text */}
            <ItemText payMode={payMode} />
            {/* WeChat password‑free activation */}
            {payMode?.payMode == 10 && this.state.showNoPass && <ItemNoSecrect payMode={payMode} applyContract={applyContract} />}
            {/* Bank activity text */}
            <ItemActivityText source={source} argsData={argsData} payMode={payMode} token={token} cashierData={cashierData} selectedPayMode={selectedPayMode} onPressEv={this.onPressEv} />
        </View>
    </View>
</View

3. Component Design Principles

Key principles include:

Single Responsibility Principle (SRP) : Keep components small (≤200 lines) and limit props to four.

Law of Demeter : Reduce coupling, prefer functional components, avoid direct DOM manipulation.

Logic Extraction : Use strategy pattern for payment method handling, enabling easy addition of new methods.

Strategy‑pattern pseudocode:

// index.js – entry function
/**
 * @param {Object} payData Required payment data
 * @param {Object} payMode Payment type
 * @param {Object} currentPayMode Proxy payment params
 * @param {Object} successCallBack Callback on success
 * @param {Object} failCallBack Callback on failure
 */
import payType from './payType/index.js';
export default function toPay(dataObj) {
    payType[dataObj.payMode](dataObj);
}

// payType/index.js – map of strategies
import JdPay from './JdPay';
import wxPay from './WxPay';
import CloudPay from './CloudPay';
import DaiPay from './DaiPay';
const payTypeObj = {
    '10': wxPay,
    '20': jdPay,
    // ...
};
export default payTypeObj;

Benefits and Outlook

Benefits

Usability continuously improves; component design raises testability and reduces bug rates for new features.

Integration time for new payment methods drops from ≥3 person‑days to ~1 person‑day, accelerating business value delivery.

Code size shrinks by ~20 KB (≈10 % reduction), benefiting RN package upgrades and H5 resource loading.

Team adopts component layering and design standards, enhancing maintainability and extensibility.

Design‑pattern practice strengthens developers' understanding of patterns.

Outlook

Future improvements include:

Introducing TypeScript at the project level to catch null‑pointer issues early.

Achieving full unit‑test coverage for all components.

Adding alarm mechanisms on top of the existing APM solution for proactive failure detection.