Designing Data Structures for a Visual H5 Page Editor (Web IDE)

Since the second half of 2014 H5 games and special pages have become popular, the author—a senior web front‑end engineer at Hujiang—shares the thinking behind building a visual H5 page editing system, focusing on how to model complex data structures for large‑scale applications.

In 2014 many H5 activity pages were repetitive, leading the team to consider creating their own editor to avoid copy‑paste development. After initial demos the idea evolved into a full‑featured Web IDE.

As a concrete example, the article shows a typical async request returning a list, the rendering flow, and a simple renderer diagram:

{
    ..., 
    data: {
        list: [
            {id: 1, content: '这是第一条数据'},
            {id: 2, content: '这是第二条数据'},
            {id: 3, content: '这是第三条数据'}
        ],
        total: 4
    }
}

From the list the DOM is assembled manually:

<li>1.这是第一条数据</li>
<li>2.这是第二条数据</li>
<li>3.这是第三条数据</li>

The rendering pipeline is illustrated as:

+--------+      +----------+      +-------+
|  data  |  =>  | renderer |  =>  |  DOM  |
+--------+      +----------+      +-------+

To handle the complexity of a full editor, the author breaks the UI into small widgets and enumerates typical H5 page elements: images, audio, video, text, links, animations, and others. Each element is abstracted with properties such as type, content, position, size, color, background, link, etc.

An example element object is shown:

element: {
    style: {
        someKeyA: 'someValueA',
        someKeyB: 'someValueB',
    },
    class: ['someClass'],
    attribute: {
        custom: 'someCustomData',
    },
    content: {
        text: 'content\'s context'
    }
}

A page aggregates multiple elements and its own settings:

page: {
    elements: [
        { /* element1 */ },
        { /* element2 */ },
        { /* element3 */ }
    ],
    setting: {
        propertyA: {},
        propertyB: 'valueB',
        flagC: false,
    }
}

The complete H5 document is a collection of pages plus global settings:

h5: {
    pages: [
        { /* page1 */ },
        { /* page2 */ },
        { /* page3 */ }
    ],
    setting: {
        propertyA: {},
        propertyB: 'valueB',
        flagC: false,
    }
}

The author argues that operating on data rather than directly manipulating the DOM yields better extensibility and compatibility, especially for responsive layouts.

CRUD operations for pages and elements are expressed as simple array manipulations (push, splice, swap) and object updates. For example, adding a page is a pages.push(page1) operation, and swapping page order is just swapping array indices.

Element editing follows a key‑value model; each attribute (top, left, width, height, transform, etc.) is edited through input controls that modify the underlying data, triggering a re‑render.

History (undo/redo) is modeled as an array of status objects with a cursor index. Pushing a new status, shifting old ones when the buffer is full, and moving the cursor back or forward implements undo and redo:

history.push(statusNew);
cursor--;
callback(history[cursor]);

Finally, the article shows the overall UI split into front‑end page data and back‑end interaction data, emphasizing that the data‑driven design, while seemingly large, remains conceptually simple: replace <li> with <element> and extend the data model as needed.

The author concludes that iteratively abstracting the system into small, testable modules helps manage complexity and produces a clear, maintainable architecture for visual H5 editors.