Designing a Scalable Front‑End Architecture for WeChat’s Scan‑to‑Edit Product Page

1 Background

In the WeChat client, scanning a product’s barcode with the “Scan” feature reads its information, and after merchants join the WeChat public platform they can claim the product and enrich its details. The Scan module on the public platform provides this capability, and the product editing section has the most complex front‑end design. This article briefly shares the thinking and implementation process of the front‑end architecture for the WeChat Scan “product editing” feature.

2 Technical Requirements

The front‑end interaction and logic of the product editing page are highly complex. Key points include:

Left side is a preview area that real‑time simulates how the product appears on a phone.

Right side is the editing area; changes must synchronize in real time to the preview.

Different product attributes have distinct editing logic.

Before saving, previewing, or submitting, fields must be validated; the validation logic depends on user settings on the page.

Because product attributes are numerous, each type requires its own handling logic, such as conditional display (show B only after selecting A), long dependency chains, varying validation rules per field, enabling/disabling based on selections, supporting sorting with restoration, asynchronous data fetching, and inter‑attribute dependencies.

3 Technical Solution

Product attributes often exceed ten types, each with complex interaction logic, so design patterns are needed to make the code easier to develop and maintain .

3.1 Modularization

The page is split into sub‑modules by product attribute, keeping modules as independent as possible. Each module contains its own initialization, rendering, events, and form‑validation methods, preventing coupling and facilitating future product iteration. The diagram below shows part of the attribute module division, along with the left‑side preview (Preview module).

3.2 Using MMVC

Modules need to share data, so a shared data model stores all product attribute fields. When an editor module changes data, the model’s callback notifies the Preview module to render in real time . The whole page acts as a large controller that orchestrates modules and handles global actions such as save and preview. All modules expose a uniform interface for consistency.

Each module independently manages its own view (data rendering, interaction handling). To decouple, the controller does not manipulate the view directly; instead, view logic resides within each module. Modules can access each other; for dependent modules, the data model resolves synchronization, while cross‑module logic is accessed via public interfaces, keeping internal implementation transparent to the outside.

3.3 Mapping Simplification

Complex interactions often involve chained selections (choose A to reveal B, then B to reveal C). Writing long if‑else chains quickly becomes unwieldy. For patterned options, a mapping relationship can replace conditional logic. For example, defining types “none/video/image” as 0/1/2 maps to templates #tpl_banner_0, #tpl_banner_1, #tpl_banner_2; rendering then uses simple string concatenation instead of multiple if‑else statements.

This small coding trick is useful across many WeChat public platform scenarios.

4 Afterword

The upgrade of the Scan‑to‑Edit product page required extensive development time and involved many intricate steps. The above outlines the overall architectural ideas; readers are welcome to discuss and share further insights.