Frontend Development 11 min read

Achieving True WYSIWYG in Low‑Code Editors: Editing Layer and Rendering Layer Design

This article explains how a low‑code editor can provide true WYSIWYG editing by separating the canvas into an editing layer and a rendering layer, using an iframe for isolation, synchronizing layout information via DOM measurements, and addressing the challenges of component overlap, performance, and cross‑technology integration.

58 Tech
58 Tech
58 Tech
Achieving True WYSIWYG in Low‑Code Editors: Editing Layer and Rendering Layer Design

When building low‑code products, preview functionality is essential for confirming that edited content matches expectations. Existing editors typically implement preview either by opening a new window or by providing an in‑place WYSIWYG view, each with its own trade‑offs.

The author’s team created a fully WYSIWYG low‑code editor (the “Coral Sea” project) and shares the design principles behind it. The key idea is to treat the preview as part of the editing process by placing the preview container directly beneath the editing canvas.

To avoid visual conflicts and layout mismatches, the canvas is split into two distinct layers: an editing layer that captures user interactions and a rendering layer that displays the production‑ready page. The rendering layer is isolated inside an iframe , which prevents editor styles and scripts from affecting the final output and allows safe overlay of editing controls.

Layout synchronization is achieved by assigning a unique ID to each component, attaching it to the DOM in the rendering layer, and using getBoundingClientRect to retrieve exact size and position. This information is then applied to transparent trigger elements in the editing layer, ensuring that clicks on the preview correctly target the underlying component.

The multi‑layer approach solves two main problems: component overlap and misalignment between the editor and preview. It also enables advanced scenarios such as cross‑technology component integration (e.g., a React‑based editor handling Vue components) and potential debugging tools that inject editing capabilities into live pages.

Despite its benefits, the design has limitations, including the knowledge cost of reproducing the production environment, handling dynamic data fetching, precise text‑image mixing, and the performance impact of frequent re‑renders. The author acknowledges these issues and plans to address them in future articles.

Overall, separating the editing and rendering responsibilities provides a more accurate WYSIWYG experience, improves extensibility, and aligns with similar solutions used by major low‑code platforms.

frontendCanvaslow-codeiframeeditor designrendering layerWYSIWYG
58 Tech
Written by

58 Tech

Official tech channel of 58, a platform for tech innovation, sharing, and communication.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.