How to Build Reactive Data Synchronization Between Raw and Intermediate Models

This article explains why an intermediate data structure is needed for 3D rendering in a React‑like Virtual DOM environment, how to keep it reactively synchronized with raw graph data using dependency analysis, proxies, and conversion functions, and the performance benefits of minimal partial updates.

CoolHome R&D Department
CoolHome R&D Department
CoolHome R&D Department
How to Build Reactive Data Synchronization Between Raw and Intermediate Models

Responsive Data Synchronization Scenarios

Technology is driven by business needs. One core business of KuJiaLe is 3D rendering of floor plans, originally built with Flash and later migrated to an HTML5 tool driven by a React‑like Virtual DOM for canvas rendering.

3D model rendering as main business

React‑style Virtual DOM as view framework driving 3D rendering

The Gap Between Raw Data and View Framework: Need for an Intermediate Data Structure

As front‑end projects become more complex, data management gets chaotic and frameworks impose format constraints. In this case, raw 3D data is a graph of inter‑referencing nodes, which cannot be JSON‑ified or made immutable, conflicting with React’s immutable data requirement and Redux’s tree‑structured JSON data.

An intermediate data structure bridges raw data and the view framework, allowing raw data to remain business‑focused while the view receives a suitable format.

The intermediate structure provides:

No format restrictions: raw data can ignore framework limits.

Clear responsibilities: interaction data lives in the intermediate layer, separating it from business data.

New Problem: Synchronizing Original and Intermediate Data Reactively

Introducing the intermediate layer solves format issues, but keeping it in sync with the original data becomes another challenge, similar to data‑view synchronization.

Traditional MVC (Backbone, Dojo, Ember) requires manual updates after data changes, which is error‑prone.

Reactive view frameworks like React define a single data‑view conversion function that handles both initialization and automatic partial updates.

Applying the same idea, the synchronization between original and intermediate data should also be reactive, eliminating manual maintenance.

How to Implement Reactive Data Synchronization?

The goals are:

Reactivity: a single conversion function automatically handles initialization and updates, producing identical results for identical source data.

Minimal partial updates: only changed data is synchronized, supporting React PureRender.

Support for unrelated auxiliary data mixed into the conversion.

Low learning curve for new concepts.

Implementation can be divided into:

Dependency analysis and data‑change listening.

The conversion function.

Syntax definition.

Dependency Analysis and Data‑Change Listening

ES5 getters/setters can intercept property reads/writes but require prior knowledge of properties. ES2017 Proxy can intercept any property access, enabling fine‑grained dependency tracking and update notifications.

During execution, all read objects become dependency sources; any write triggers an update for those dependent nodes.

In practice, one can limit monitoring to specific data levels to improve efficiency.

Data Conversion Function

The conversion function binds raw data to result data. Initialization runs the whole function and records dependencies; on updates, only nodes dependent on changed sources are re‑executed.

Partial update requirements:

Update only the minimal data set, avoiding unnecessary renders.

Prevent redundant updates.

Partial Update Optimizations: Independent Parent‑Child Updates

When [户型] or [家具] change, only those nodes are synchronized; [房间] and [墙面] conversion functions are not called.

Partial Update Optimizations: Update Ordering

Updating from top to bottom avoids unnecessary child updates when a parent node removes a child.

Partial Update Optimizations: Arrays

Array nodes handle only addition/removal; element updates are driven by their own dependencies. Identical elements retain previous conversion results via matching.

Syntax Definition for Data Synchronization Binding

The syntax aims to avoid requiring developers to adopt a full view‑framework binding language; instead, a Virtual DOM‑like description maps raw data to view data with minimal local updates.

Summary

Introducing an intermediate data layer decouples business data from view constraints, enabling immutable data, reliable update notifications, and clear data flow. Reactive synchronization ensures that changes in raw data automatically propagate to the intermediate layer without extra maintenance, and the approach can be applied to any scenario where two data formats need to be bridged.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

frontendreactive-programmingdata synchronizationVirtual DOMintermediate data
CoolHome R&D Department
Written by

CoolHome R&D Department

Official account of CoolHome R&D Department, sharing technology and innovation.

0 followers
Reader feedback

How this landed with the community

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.