DIY Product Card System: Decoupling UI and Logic for Scalable Frontend Development

In many business units of Ctrip, a large number of marketing pages require diverse product card styles, leading to a cumbersome workflow where each new card or field demands a full design‑to‑development cycle. This caused duplicated effort, low reuse, and reduced click‑through rates.

The DIY product card system solves these problems by separating UI from business logic. The UI can be configured in a backend canvas, while developers provide atomic React/React‑Native components that render the final card based on the configuration.

The system consists of two main parts: a rendering engine and a configuration platform. Rendering supports three approaches:

Fixed layout where field width, height, and position are static.

Dynamic layout using absolute positioning but calculated from data, employing row containers (flex <div></div> ) to avoid hard‑coded coordinates.

Relative layout using nested row and vertical containers so fields automatically flow based on preceding content.

The dynamic algorithm follows four steps: (a) detect fields affected by height changes, (b) collect required adjustments, (c) modify the rendering data, and (d) render the card and fine‑tune any deviations.

On the configuration side, product or operation staff can drag‑and‑drop components onto a canvas, bind fields, and set styles. Supported components include basic fields, images, containers, vertical/horizontal flex containers, and inline containers for line‑break scenarios. Style configuration mirrors CSS, with special handling for absolute vs. relative positioning, flex properties, and platform‑specific conversions (e.g., <Text><Text/> for RN inline containers, LinearGradient for gradients, etc.).

Special problem solutions include:

API repeat‑call reduction via a publish‑subscribe mechanism that caches schema per template ID.

RN style differences handled by the css-to-react-native package and custom component logic.

Field linkage to express mutual exclusivity, co‑appearance, or conditional styling.

Render‑props slots allowing custom JSX (e.g., a live‑stream player) to be injected.

Custom click‑event functions bound by field name, enabling multiple interactive zones without code changes.

Parent‑child card composition to reuse common sections and assemble complex cards.

Additional features include import/export of card templates (TXT format), version management (online, editable, historical), preview for H5 or app, and a component library for quick assembly.

Integration is done via an npm package; the contract supplies product data, optional custom logic (click handlers), and rendering preferences ranging from 0% (pure data) to 100% (full custom render).

Overall, the DIY product card system demonstrates how front‑end engineers can leverage low‑code platforms, modular UI components, and decoupled architectures to dramatically cut development cost, improve reuse, and boost user engagement.