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.
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.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
CoolHome R&D Department
Official account of CoolHome R&D Department, sharing technology and innovation.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
