Redesigning JD Order Detail Page with a Flexible Floor‑Based Architecture
The article presents a comprehensive case study of JD's order detail page redesign, detailing the shortcomings of the legacy layout, the goals of flexibility, smoothness, and maintainability, and the floor‑based data and UI architecture that enables rapid, configurable, and low‑cost feature expansion across client and server sides.
JD's order business provides users with comprehensive order information after purchase, including logistics, product, and price details, making the order detail page a critical touchpoint for user retention and repeat purchases.
The legacy order detail page suffered from inflexible development, a static layout, and data redundancy, causing high maintenance costs and difficulty adapting to new business requirements.
The core renovation goals are threefold: flexibility (configurable business entry, dynamic floor ordering, and template layout control), smoothness (maintaining performance and preventing frame drops or OOM), and maintainability (standardized floor rules and simplified development processes).
The floor‑based redesign splits the page into modular sections (floors) such as product, store, logistics, and price floors, distinguishing between fixed floors and configurable floors that can be customized via server‑side settings.
A new data structure separates high‑dependency, low‑reuse fields into a floors object and high‑reuse fields into an others object, allowing precise data delivery and reducing redundancy.
Server‑side implementation involves selecting or creating a template, implementing a FloorHandler class with isValid() and onEvent() methods, and registering the class with a configuration system for dynamic loading.
Client‑side architecture features a clear separation between business logic and UI: a ViewManager manages floor views, a base floor class provides common methods, and business and utility modules supply interfaces and tools. Dynamic class loading uses a mapping of floor IDs ( mid) to class names for both models and views.
Floor addition is streamlined: developers only need to create a new model and view, register the floor ID, and implement any specific business logic, without affecting existing code, thus adhering to the open‑closed principle.
Performance optimizations include pre‑computing floor layouts and heights before rendering and caching reusable floors to reduce memory usage.
Since the floor‑based redesign went live, configuration capability has increased dramatically, supporting up to 40% of urgent business needs through configurable floors, significantly improving development efficiency and user experience.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
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.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
