Front-End Architecture Refactoring for International Food Delivery Merchant Marketing

The article presents a comprehensive case study of architecture governance and upgrade for the front‑end of an international food‑delivery merchant marketing platform. It begins with a background describing how flexible subsidy strategies and diverse marketing activities are used to boost merchant sales and user engagement.

Business and Technical Characteristics

Key business traits include multiple marketing scenarios, many activity types, long activity chains, and complex rules. The back‑office faces numerous configuration forms and intricate linkage logic. Front‑end challenges stem from multiple terminal types (PC, EXE, PAD, PHONE), high code duplication, and complex user‑input validation.

Current Problems

Low efficiency in product iteration due to repetitive field modifications across activity types and channels.

Development omissions caused by long activity chains and inconsistent data models.

Poor extensibility; adding a new activity type requires changes across the entire stack.

Solution Overview

The core solution is a unified activity data model that abstracts activity entities and consolidates configuration. This model is implemented as a set of TypeScript schemas and JSON‑Schema definitions, enabling consistent validation and default handling.

Key components include:

Design of a unified activity entity (ActInfoModel) with subclass models for specific channels (e.g., selfOpsModel).

Use of a configuration‑model + dependency‑injection form for front‑end forms, replacing deep prop‑drilling.

Centralized API response validation and fallback using the zod library.

Code Examples

Example of a special‑item activity rule (JSON):

{
  "specialItemRule": [{
    "rulePurposeType": 0,
    "rules": [{
      "type": 3,
      "content": {
        "discountValueRange": null,
        "discountValueList": [10, 11, 20],
        "discountType": 1
      }
    }],
    "selectItemNumRange": {"min": 1, "max": 10},
    "itemPromoRangeValue": {"min": 1, "max": 50},
    "picLimit": 1,
    "priceLimit": null,
    "itemType": 0,
    "checkItemPriceDay": 7
  }]
}

Example of a reduction rule (JSON):

{
  "reductionRule": [{
    "rulePurposeType": 0,
    "rules": [{
      "type": 1,
      "content": {"threshold": 10, "discount": 5}
    }, {
      "type": 1,
      "content": {"threshold": 20, "discount": 8}
    }]
  }]
}

TypeScript schema for a sign‑up activity (using zod ):

// Sign‑up activity rule
export const SignUpActRuleSchema = ActRuleSchema.extend({
  selectNumRange: z.object({
    min: z.number().default(0),
    max: z.number().default(0)
  }).default({ min: 0, max: 0 }),
  actType: z.union([z.number(), z.string()]).default(0),
  rule: z.array(SignUpRuleSchema).default([])
});
export type SignUpActRule = z.infer
;

// Sign‑up activity detail API response
export const SignUpDetailSchema = z.object({
  actRule: SignUpActRuleSchema.default({}),
  actInfo: SignUpInfoSchema.default({}),
  shopJoinInfo: z.array(ShopJoinInfoSchema).default([])
});

API response handling example:

export async function getSignUpDetail(params: object = {}): Promise
{
  const response = await post(GET_SIGN_UP_DETAIL, params, { returnData: false });
  return useApiSchema
(SignUpDetailSchema, response.data, response.traceId);
}

Benefits

Unified data model reduces field duplication; changes now occur in a single place.

Configuration‑model + dependency injection simplifies data flow, lowers component coupling, and improves maintainability.

Centralized validation and fallback logic (via zod ) enhances interface safety and prevents UI crashes.

Development efficiency increased by roughly 40% for new activity types.

Future Plans

The team plans to standardize the most complex recruitment activity chain across all projects, aligning back‑office configuration with front‑end consumption using the same data model, and continue scaling the architecture for international markets.