Client‑Side Rendering Logic for Custom Layouts in the Dolphin System

The Dolphin system adopts a floor‑based custom layout model to improve efficiency. After describing the server‑side module design in the previous article, this piece focuses on the client‑side rendering logic, explaining how custom layouts are parsed from data and rendered on the UI.

The international channel homepage consists of five main tabs, each containing multiple sub‑tabs that display various business functions such as product listings, user acquisition, ads, and activities. Custom layout floors, like the "Brand Dynamics" floor, are displayed identically to fixed template floors.

Figure 1: Pre‑release version of the JD International channel page

Figure 2: Tree structure of the pre‑release channel homepage

Each floor’s common properties are defined globally, while private properties are encapsulated in a widget‑ending object. Custom floors use a flexWidget object to store layout and content data, allowing them to share the same creation and rendering logic as regular template floors.

The client initiates data requests, shows a loading state, then receives layout data (via the layout API) and content data (via the content API). Because the two data streams are decoupled, four scenarios can occur:

Layout arrives first, then content.

Layout arrives first, content fails.

Content arrives first, then layout.

Content arrives first, layout fails.

In the normal cases (1 and 3), the client processes the data differently. When layout arrives first, the layout initialization module recursively renders the nested layout structure from the root container outward, respecting the order defined in the configuration platform. After layout rendering, the content update module recursively traverses the same hierarchy, matching view IDs to assign actual images, text, and other data.

If content arrives before layout, the client keeps the loading state until the layout is received. Once both are available, a merging step combines layout and content into a single nested structure, allowing a single recursive pass to render and populate views simultaneously.

Figure 3: Merged data structure after combining layout and content

For error scenarios (2 and 4), a retry mechanism (typically two attempts) is triggered. Successful retries follow the normal rendering flow; if retries are exhausted, the UI switches from a loading indicator to an error message.

The complete custom UI rendering flow is illustrated in Figure 4.

Figure 4: Custom UI rendering process

When only content changes while the layout remains static, the client indicates this via a request parameter, prompting the server to return only content data. The client then performs a content‑only recursive update, following the same path as the second half of scenario 1.

Review

In summary, the article covered the architecture and workflow of custom layouts in the Dolphin system, from configuration to server processing and finally client rendering, forming a complete closed‑loop solution.

Future Plans & Summary

The custom module is now fully rolled out on the channel page, having supported over 20 activity configurations during the 618 promotion. Future work includes expanding material configuration, integrating with external platforms, enhancing interaction capabilities (e.g., linking, sliding), building a comprehensive monitoring dashboard, and pursuing open‑source collaboration to increase team impact.