Synchronous update methods, systems, devices, and storage media for low-code components

Abstract

This invention relates to the field of low-code platform technology, providing a method, system, device, and storage medium for the synchronous update of low-code components. During dynamic component library loading, an AST template is generated for each component and an attribute mapping is established. When an attribute is modified, the AST template is updated. A difference analysis algorithm is used to identify changes, and the differences are converted into an operation sequence (including a global ID and timestamp) of a conflict-free copy data type. This sequence is broadcast to other modification interfaces and coordinating terminals via a collaboration protocol. During concurrent modifications, conflicts are resolved based on merging rules or timestamp priority, ultimately achieving synchronous attribute modification. This method enables real-time seamless collaboration between visual configuration and source code editing.

Description

Technical Field

[0001] This invention belongs to the field of low-code platform technology, specifically relating to a method, system, device, and storage medium for synchronous updating low-code components. Background Technology

[0002] In the current front-end development field, low-code platforms have significantly improved the efficiency of building basic applications through visual drag-and-drop and pre-built component libraries. However, existing solutions still have obvious limitations. Traditional low-code development environments typically separate visual configuration from source code editing modes, making it difficult to achieve bidirectional real-time synchronization between the two. When advanced customization or team collaboration is required, developers often have to leave the visual environment, resulting in a disjointed development experience and low collaboration efficiency. In addition, existing technologies lack effective conflict resolution mechanisms and cannot reliably handle concurrent modifications to the same component properties by multiple users, severely limiting their application in complex, multi-user collaborative projects. Therefore, there is an urgent need in this field for a low-code component synchronization update method that can deeply integrate visual operations and source code editing, and support real-time collaboration and conflict resolution. Summary of the Invention

[0003] In view of the above-mentioned shortcomings of the prior art, the present invention provides a method, system, device and storage medium for synchronous updating of low-code components to solve the above-mentioned technical problems.

[0004] In a first aspect, the present invention provides a method for synchronously updating low-code components, comprising:

[0005] When the dynamic component library module is loaded, a corresponding AST template is generated for each low-code component, and a mapping relationship between component properties and the AST template is established.

[0006] In response to the user's modification operation of the target component's attributes in the first operation interface, first update data is generated, the AST template of the target component is updated according to the first update data, and the difference before and after the update is identified by the AST difference analysis algorithm;

[0007] The differences are converted into a sequence of operations compatible with conflict-free copy data types, and each operation is assigned a globally unique ID and timestamp. The sequence of operations is then broadcast to the second operation interface via a cooperative protocol.

[0008] If multiple terminals concurrently modify the same attribute, the operation sequence is conflict-resolved based on the merging rules of conflict-free copy data types or timestamp priority.

[0009] In the second operation interface, the corresponding component attributes are updated according to the operation sequence to complete the bidirectional synchronization between the first operation interface and the second operation interface.

[0010] In an optional implementation, a corresponding AST template is generated for each low-code component, including:

[0011] Generate a structured template object, which includes at least:

[0012] Component type identifier;

[0013] A collection of properties for a component, where each property contains a property name, property type, and default value;

[0014] The set of events that a component can respond to;

[0015] Slot information for the component.

[0016] In an optional implementation, establishing the mapping relationship between component properties and AST templates includes:

[0017] Assign a unique path identifier to each attribute of the component;

[0018] Establish a mapping table with the path identifier as the key and the corresponding AST template as the value.

[0019] In an optional implementation, in response to a user's modification operation on the attribute of the target component in the first operation interface, first update data is generated; the AST template of the target component is updated according to the first update data; and the differences before and after the update are identified by an AST difference analysis algorithm, including:

[0020] The JavaScript Proxy object proxies the property object of the target component, intercepting its property setting operations; when the property value is modified, a normalized property change event is generated and emitted, the event payload of which includes at least the component instance ID, the path of the modified property, the old value before modification, and the new value after modification.

[0021] Based on the attribute path in the attribute change event, locate the corresponding node in the AST template of the target component, update only the value of the node, generate a new AST template object, and thus complete the incremental update of the AST template.

[0022] The updated AST template is compared with the original AST template using a depth-first traversal to identify node additions, deletions, and updates, generating a structured list of differences. This list of differences is then minimized to filter out style tweaks that do not substantially change and to merge consecutive operations with the same path.

[0023] In an optional implementation, the differences are converted into a sequence of operations compatible with conflict-free replication data types, and each operation is assigned a globally unique ID and timestamp. The sequence of operations is then broadcast to a second operation interface via a cooperative protocol, including:

[0024] The differences are mapped to corresponding conflict-free copy data type operations according to their operation types, and the attribute paths in the differences are converted into a standardized path format; the mapping behavior includes: ADD type differences are mapped to insert operations, REMOVE type differences are mapped to delete operations, and UPDATE type differences are mapped to set operations.

[0025] Assign a globally unique operation ID and a hybrid logical timestamp to each conflict-free copy data type operation after conversion, and encapsulate metadata containing the ID, timestamp, operation type, path, and operation value;

[0026] The encapsulated operation sequence is broadcast to the second operation interface via a WebSocket connection; before broadcasting, an incremental compression algorithm is applied to the operation data to reduce network load.

[0027] In an optional implementation, if multiple terminals concurrently modify the same attribute, conflict resolution is performed on the operation sequence based on the merging rules of conflict-free copy data types or timestamp priority, including:

[0028] When an operation is received from another collaborative terminal, check if there is a local operation on the target path of the operation that has not yet been synchronized to the terminal; if so, it is determined to be a concurrent modification conflict.

[0029] Conflicting operations are merged according to preset priority rules;

[0030] The merged operation results are applied to the local state, and the AST template and view are updated to ensure that the final state of all terminals is consistent.

[0031] The priority rules include:

[0032] Timestamp priority rule: Compare the timestamps carried in conflicting operations, and apply the operation with the later timestamp first;

[0033] Operation type priority rule: If it is impossible to determine based on the timestamp or the timestamps are the same, the operation of type delete shall be applied first;

[0034] Attribute-specific rules: For attributes of a specific type, execute custom merging logic; for style attributes, call the style value merging function to merge conflicting values.

[0035] In an optional implementation, the corresponding component attributes are updated in the second operation interface according to the operation sequence to complete the bidirectional synchronization between the first and second operation interfaces, including:

[0036] The second operation interface receives the broadcast operation sequence through the cooperation protocol, parses out the operation metadata, including operation ID, type, target path and value, verifies the global uniqueness of its ID, and discards duplicate operations that have been processed.

[0037] Based on the parsed target path, locate the corresponding target component instance in the component tree of the current document; call the corresponding state update function according to the operation type, and apply the operation value to the corresponding property of the target component instance;

[0038] The view rendering engine of the second operation interface is triggered, and the user interface is re-rendered according to the updated component state, thereby completing the visual state synchronization with the first operation interface, and sending confirmation feedback of successful operation application to the coordination layer.

[0039] Secondly, the present invention provides a synchronous update system for low-code components, comprising:

[0040] The template loading module is used to generate a corresponding AST template for each low-code component when loading dynamic component library modules, and to establish a mapping relationship between component properties and AST templates.

[0041] The update parsing module is used to generate first update data in response to the user's modification operation of the target component's attributes in the first operation interface, update the AST template of the target component according to the first update data, and identify the differences before and after the update through the AST difference analysis algorithm.

[0042] The operation broadcast module is used to convert the differences into an operation sequence compatible with conflict-free copy data types, assign a globally unique ID and timestamp to each operation, and broadcast the operation sequence to the second operation interface through a cooperation protocol;

[0043] The conflict resolution module is used to resolve conflicts in the operation sequence based on the merging rules of the conflict-free copy data type or the timestamp priority if multiple terminals concurrently modify the same attribute.

[0044] The operation execution module is used to update the corresponding component attributes in the second operation interface according to the operation sequence, so as to complete the bidirectional synchronization between the first operation interface and the second operation interface.

[0045] Thirdly, a device is provided, comprising:

[0046] Memory, used to store the synchronous update program for low-code components;

[0047] A processor, configured to implement the steps of the low-code component synchronization update method as provided in the first aspect when executing the synchronization update procedure of the low-code component.

[0048] Fourthly, a computer-readable storage medium is provided, on which a synchronization update program for a low-code component is stored, wherein when executed by a processor, the synchronization update program for the low-code component implements the steps of the synchronization update method for the low-code component provided in the first aspect.

[0049] The beneficial effects of this invention are as follows: the low-code component synchronization update method, system, device, and storage medium provided by this invention achieve seamless real-time synchronization between visual configuration and source code editing by establishing a mapping relationship between component attributes and AST templates and a two-way binding mechanism, greatly improving development efficiency and flexibility; by converting operation sequences into CRDT format and assigning them unique IDs and timestamps, combined with multi-strategy conflict resolution algorithms, the eventual consistency and reliability of data in multi-terminal collaborative operations are effectively guaranteed; the entire method takes into account both the convenience of low-code development and the ability to customize high-code, providing efficient and stable technical support for team collaborative development of complex front-end applications. Attached Figure Description

[0050] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0051] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0052] Figure 2 This is a schematic block diagram of a system according to an embodiment of the present invention.

[0053] Figure 3 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation

[0054] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0055] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0056] The method for synchronously updating low-code components provided in this embodiment of the invention is executed by a computer device, and correspondingly, the system for synchronously updating low-code components runs on the computer device.

[0057] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The executing entity can be a low-code component-based synchronous update system. Depending on different requirements, the order of steps in this flowchart can be changed, and some can be omitted.

[0058] like Figure 1 As shown, the method includes:

[0059] S1. When the dynamic component library module is loaded, a corresponding AST template is generated for each low-code component, and a mapping relationship between component properties and AST template is established.

[0060] S2. In response to the user's modification operation of the target component's attributes in the first operation interface, generate first update data, update the AST template of the target component according to the first update data, and identify the differences before and after the update through the AST difference analysis algorithm;

[0061] S3. Convert the differences into a conflict-free copy data type compatible operation sequence, assign a globally unique ID and timestamp to each operation, and broadcast the operation sequence to the second operation interface through a cooperation protocol;

[0062] S4. If multiple terminals concurrently modify the same attribute, the operation sequence is conflict-resolved based on the merging rules of conflict-free copy data types or timestamp priority.

[0063] S5. In the second operation interface, update the corresponding component attributes according to the operation sequence to complete the bidirectional synchronization between the first operation interface and the second operation interface.

[0064] In one embodiment of the present invention, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0065] First, upon system startup or when a dynamic component library module is loaded, the system iterates through all registered low-code component definitions in the library. For each component, the system performs the following steps to generate its corresponding Abstract Syntax Tree (AST) template:

[0066] S101. Generate a structured AST template object: The system reads the component's metadata definition, parses it, and generates a structured JSON object as the component's AST template. This template object is a standardized description of the component's structure and contains at least the following fields:

[0067] type: Component type identifier (e.g., 'ButtonComponent'), used to uniquely identify this type of component.

[0068] `properties`: A collection of properties for a component, consisting of key-value pairs. Each property's value is also an object, which must contain fields such as `type` (the property's type, e.g., 'string', 'color', 'number') and `default` (the property's default value). For example, a button component's `text` property might be described as: `text: { type: 'string', default: 'Click Me'}`.

[0069] events: A collection of events that the component can respond to; it is an array. Each event object contains an event name (such as 'onClick') and a description of possible event parameters.

[0070] slots: Slot information for a component, used to describe the child content templates that the component can receive, including slot name, default content, and other information.

[0071] S102. Establish the mapping relationship between component properties and the AST template: To support subsequent precise two-way binding and differential updates, it is necessary to find the corresponding node in the AST template for each property of the component and establish a strong association. This process specifically includes:

[0072] Assign a path identifier: Assign a unique path identifier to each property of the component. This path identifier is usually a string in the form of dot or forward slash, and its rule is usually [component instance ID].[property name] or for nested properties, [component instance ID].[parent property name].[child property name] (e.g., "button_1.style.backgroundColor"). This path is globally unique throughout the entire application session.

[0073] Creating a mapping table: The system maintains a global mapping table (e.g., a JavaScriptMap object) in memory. This mapping table uses the path identifier generated in the steps as the key and the corresponding node object in the AST template as the value. By querying this mapping table, the system can quickly locate the specific node in the AST based on the path of an attribute, thus enabling efficient read and update operations.

[0074] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0075] The specific implementation of S201. Property modification event capture is as follows:

[0076] Instead of directly manipulating its original property objects, the system creates a proxy object for each component instance on the canvas. This is achieved using JavaScript's Proxy object. When a user modifies component properties in the visual configuration interface (the primary user interface) (such as changing button text or color in the properties panel), the following process is triggered:

[0077] Creating a proxy: When a component is instantiated, the system wraps its property object using the `new Proxy(target, handler)` method. The `handler` object defines a `set` trap function to intercept all operations that set the property value.

[0078] Intercepting and Emitting Events: When the `set` trap function is triggered, its execution logic is as follows: First, record the current value (old value) of the modified property. Perform the default assignment operation (`target[prop] = value`). Then, immediately construct a normalized property change event object and publish it using an event emitter or publish / subscribe pattern. The payload of this event object is structured data, containing at least: `componentId`: a unique instance identifier of the currently modified component (e.g., "button_123"); `propertyPath`: the complete path identifier of the modified property (e.g., "style.backgroundColor"); `oldValue`: the property value before modification; `newValue`: the new property value after modification.

[0079] S202.AST template incremental update.

[0080] Listen for the above attribute change events and update the AST template accordingly:

[0081] Locating the AST template: After receiving the propertyChanged event, the system extracts the propertyPath. Based on the mapping table between path identifiers and AST templates established during the initialization phase, the system quickly finds the precise node corresponding to the path in the AST template.

[0082] Updating node values: Instead of directly modifying the current AST template, the system employs an **immutable** data update strategy. That is, a new copy is created based on the old AST template, and then only the value field of the node located in the new copy is modified. This approach avoids side effects and facilitates subsequent difference comparisons and historical state management.

[0083] Generating a new AST: After the update is complete, the new copy is the "updated AST template object". This process only updates the affected nodes and their parent node chains, achieving efficient incremental updates and significantly outperforming the full generation of a new AST.

[0084] S203.AST differential analysis.

[0085] The system maintains a reference to the previous AST state. The new AST template obtained in S202 is compared with the old AST template:

[0086] Depth-First Search (DFS) comparison: This method recursively compares the type, attributes, and child nodes of each node in the new and old AST trees. The comparison function (deepEqual) identifies node additions (existing in the new tree but not in the old tree), deletions (existing in the old tree but not in the new tree), and updates (nodes exist but their attributes or values ​​have changed).

[0087] Generate a difference list: Record the differences identified in each comparison step as a structured difference object. Each object typically contains fields such as type (operation type), path (node ​​path), oldValue (old value, only for UPDATE type), and newValue (new value). All difference objects are collected into a list.

[0088] Difference minimization: To improve collaboration efficiency and reduce unnecessary network transmission and computation, the difference list undergoes post-processing optimization.

[0089] Filtering out properties with no substantial change: For example, for style properties (such as width), if the difference between two consecutive modifications is very small (within a certain threshold) or if the user frequently makes minor adjustments (such as continuously changing color values), it can be judged as "no substantial change" and filtered out.

[0090] Merge consecutive operations: Check the difference list; if multiple operations on the same path exist, attempt to merge them. For example, if an attribute is changed from value A to B and then from B to C in a very short period, it can be merged into a single operation that changes directly from A to C.

[0091] In one embodiment of the present invention, based on step S3, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0092] S301, Operation Conversion and Path Standardization.

[0093] The system maintains a mapping table from difference types to CRDT operation types. This process iterates through the list of AST difference objects generated by S203, performing the following transformation on each difference object:

[0094] Operation type mapping: Based on the `type` field of the difference object, convert it into the corresponding CRDT operation instruction. The mapping rules are as follows:

[0095] When type is 'ADD', a CRDT operation with operation type 'insert' is generated.

[0096] When type is 'REMOVE', a CRDT operation with operation type 'delete' is generated.

[0097] When type is 'UPDATE', a CRDT operation with operation type 'set' is generated.

[0098] Path standardization: Extract the `path` field (e.g., "style.backgroundColor") from the difference object and convert it into a standardized path format to achieve unambiguous parsing across platforms and languages. In this embodiment, the format specified by the JSON Pointer standard (RFC 6901) is preferred. The conversion rule is to replace dot separators with forward slash separators and add the root identifier ` / ` before the path. For example, the attribute path "style.backgroundColor" is converted to the standardized path " / style / backgroundColor".

[0099] Constructing an operation object: Combine the mapped operation type, the standardized path, and the newValue (for insert and set operations) or node information (for insert operations) from the difference object to form a preliminary CRDT operation object.

[0100] S302, The specific implementation of operation sequence enhancement (assigning ID and timestamp) is as follows:

[0101] Add the necessary metadata for collaboration to each initial CRDT operation object, making it an operation instruction with global uniqueness and sequence:

[0102] Generate globally unique operation IDs: To prevent duplicate application of operations (idempotency), each operation is assigned a globally unique identifier. This ID is preferably generated using a Hybrid Logical Clock (HLC) algorithm that combines a physical timestamp, machine ID, and sequence number. A typical ID format is: <physical timestamp>-<machine ID hash>-<sequence number> (e.g., "1630000000000-hostabc-1"). This ID remains unique throughout the distributed system.

[0103] Assigning a hybrid logical timestamp: Each operation is assigned a timestamp to determine the order in which they occur. This timestamp is not a simple physical clock, but rather a hybrid logical timestamp. The timestamp contains a physical time portion and a logical counter portion (e.g., "1630000000000-1"). The logical counter resets to 0 as physical time advances; it increments when physical time remains unchanged (or when a later remote operation is received), thus ensuring that the timestamps of all operations are globally comparable and strictly increasing.

[0104] Metadata encapsulation: The generated unique ID, mixed timestamp, operation type, normalized path, and operation value are encapsulated into a complete CRDT operation object rich in metadata.

[0105] S303, The specific implementation of the broadcast operation is as follows:

[0106] Send the encapsulated CRDT operation sequence to all participating clients:

[0107] Establish a communication channel: The system establishes a long-lived WebSocket connection between the client and the collaborative server. This connection is used to achieve full-duplex, low-latency real-time communication.

[0108] Data compression: Before sending the operation object via WebSocket, an incremental compression algorithm (e.g., dictionary-based LZ algorithm or a serialization compression algorithm specifically for JSON structures such as MessagePack) is applied to it. This step compares the changes before and after the operation, encodes only the differences, or packages multiple operations into a batch, significantly reducing the network transmission load.

[0109] Broadcast transmission: The compressed operation data is broadcast via WebSocket connection to all collaborative terminals that have subscribed to the same project or document session, including local secondary operation interfaces (such as source code editors) and other remote collaborative terminals (such as clients of other team members). Upon receiving the data, the recipient performs decompression and subsequent processing to complete the synchronization of operations.

[0110] Through the above specific implementation methods, the system successfully transforms the abstract AST differences into CRDT operation instructions that can be safely, efficiently, and orderly propagated and applied in a distributed system, providing a reliable data foundation for achieving eventual consistency synchronization.

[0111] In one embodiment of the present invention, based on step S4, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0112] This embodiment assumes that the collaborative terminal (client) has maintained a local state, which includes the applied component attribute state, AST template, and a set that records all processed operation IDs.

[0113] S401. The specific implementation of collision detection is as follows:

[0114] After receiving a remote CRDT operation broadcast from the server via a WebSocket connection, the collaborative terminal does not apply it immediately. Instead, it first performs conflict detection: Parsing the operation: First, the received operation object is parsed to extract its core fields: operation ID, target path (path), operation type (type), and timestamp (timestamp); Checking operation history: The system queries the local set of processed operation IDs. If the ID of the current operation already exists in this set, it indicates that the operation has been applied and is discarded to avoid duplicate execution; Detecting concurrent conflicts: If it is a new operation, its target path (path) is checked. The system compares whether there are any un-pushed operations (i.e., operations existing in the local operation buffer but not yet broadcast) targeting the same path and with a timestamp later than the local last synchronization time. If so, a concurrent modification conflict is determined to have occurred. This is because both the un-pushed local operation and the recently received remote operation modify the same attribute, and it is uncertain from a global perspective which modification occurred later.

[0115] S402. The specific implementation of conflict resolution is as follows:

[0116] Upon detecting a conflict, the system invokes the conflict resolver to adjudicate the conflict according to the following preset multi-level priority rules:

[0117] Timestamp Priority Rule: This is the preferred adjudication rule. The conflict resolver compares the mixed logical timestamps carried in the conflicting operations (locally unpushed operations and recently received remote operations). The operation with the later timestamp (i.e., a larger value) takes precedence because it represents a logically later event. The mixed logical timestamps ensure that timestamps are globally comparable even if they come from different machines.

[0118] Operation type priority rule: This rule is enabled if conflicting operations have identical timestamps (rare but possible in distributed systems) or cannot be resolved. Under this rule, delete operations have higher priority than set or insert operations. This is because delete is usually a clearly defined final operation that should override subsequent set operations; this rule is also often referred to as the "tombstone priority" rule.

[0119] Attribute-specific rules: For certain special types of attributes, the above general rules may not apply. The system has a pre-defined attribute handling strategy table. When the path of a conflicting operation matches a specific attribute (such as a style attribute) in this table, the corresponding custom merge function will be invoked, rather than simply selecting one of the operations.

[0120] Example of style property merging: For style conflicts such as `backgroundColor`, the resolver doesn't choose one over the other, but instead calls a `mergeStyleValues(localOp, remoteOp)` function. This function may blend the two color values ​​or calculate a new valid value based on CSS cascading rules. This merging strategy avoids data loss and provides a more intelligent conflict resolution experience.

[0121] S403. The specific implementation of state application and synchronization is as follows:

[0122] After the conflict is resolved, the results need to be applied locally to complete the synchronization:

[0123] Application Operation: The winning operation selected according to the priority rules (or a new fusion operation generated by attribute-specific rules) is applied to the local state. This includes updating component attribute values ​​in memory and updating the local AST template using the incremental update method described in S202.

[0124] Update view: After the state is updated, the view rendering logic is triggered (such as diff and patch of the virtual DOM) so that the UI can be updated to reflect the final state after the conflict is resolved.

[0125] Maintaining state consistency: If conflict resolution results in the use of remote operation and the discarding of local unpushed operations, the corresponding local operation buffer needs to be cleared. Conversely, if the local operation wins, it will be broadcast as usual so that other terminals can resolve conflicts using this rule. Through this mechanism, all collaborating terminals will make the same decision on the same conflict, thereby ensuring that the final state of all terminals remains consistent.

[0126] In one embodiment of the present invention, based on step S5, a possible embodiment will be given below, and its specific implementation will be described in a non-limiting manner.

[0127] S501. All cooperative terminals that receive the operation sequence perform the same operation reception and verification process. Taking the second operation interface as an example, the specific implementation is as follows:

[0128] The second user interface (such as a source code editor) (such as a client for other users) listens for and receives operation data packets broadcast by the cooperating server through the established WebSocket connection.

[0129] Data reception and decompression: First, the received data packets are subjected to the incremental decompression algorithm corresponding to that of the sending end to restore the complete operation sequence JSON array.

[0130] Parse operation metadata: Traverse the operation sequence and parse the metadata contained in each operation object one by one. This metadata includes at least: id: a globally unique identifier for the operation; type: the operation type (e.g., 'set', 'delete', 'insert'); path: the standardized target attribute path (e.g., " / style / backgroundColor"); value: the value carried by the operation (for 'set' and 'insert' operations).

[0131] Idempotency verification and deduplication: The system maintains a cached set of processed operation IDs (such as a Set data structure). Before applying any operation, it checks whether the ID already exists in this cache. If it exists, it indicates that the operation has been received repeatedly (possibly due to network retransmissions, etc.), and the system discards the operation without further processing. This mechanism ensures the idempotency of operations, meaning that no matter how many times the same operation is applied, the result is the same as the first application. This is a key technical means to guarantee the eventual consistency of distributed systems.

[0132] S502, The specific implementation of component location and status update is as follows:

[0133] For new operations that pass verification, the system applies them to the local document state:

[0134] Component instance location: Based on the parsed standardized path, the component is searched in the component tree in memory. The path parser splits the path by separators (such as ' / ') and traverses child components or property objects level by level from the root component, finally locating the target component instance to be modified and its specific property.

[0135] Calling the state update function: Based on the parsed operation type, the corresponding state update function is called, passing in the value parameter: If it is a 'set' operation, the property setting function is called to assign the value to the located property; if it is a 'delete' operation, the property deletion function is called to set the target property to undefined or remove the property from the parent object; if it is an 'insert' operation (such as adding a child component to a list), the node insertion function is called to create a new node at the specified position.

[0136] This step involves directly modifying the data model in memory to ensure that the state of local components remains consistent with the operation instructions.

[0137] The specific implementation of S503 view rendering and feedback is as follows:

[0138] After the data status is updated, a user interface update needs to be triggered to complete the synchronization loop:

[0139] Triggering View Rendering: After the data model is updated, the system notifies the view rendering engine (such as VirtualDOM-based frameworks like React and Vue, or a self-developed rendering engine). This engine executes a diffing algorithm to calculate the minimum set of user interface changes corresponding to the data changes, and finally submits the changes to the browser for re-rendering. Thus, users can intuitively see that the interface content is synchronized with the primary user interface (visual configuration interface).

[0140] In some embodiments, the low-code component synchronization update system may include multiple functional modules composed of computer program segments. The computer programs for each program segment in the low-code component synchronization update system may be stored in the memory of a computer device and executed by at least one processor to perform (see details). Figure 1 (Description) The functionality of synchronous updates for low-code components.

[0141] In this embodiment, the low-code component's synchronization update system can be divided into multiple functional modules based on the functions it performs, such as... Figure 2 As shown. The module referred to in this invention is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0142] The template loading module is used to generate a corresponding AST template for each low-code component when loading dynamic component library modules, and to establish a mapping relationship between component properties and AST templates.

[0143] The update parsing module is used to generate first update data in response to the user's modification operation of the target component's attributes in the first operation interface, update the AST template of the target component according to the first update data, and identify the differences before and after the update through the AST difference analysis algorithm.

[0144] The operation broadcast module is used to convert the differences into an operation sequence compatible with conflict-free copy data types, assign a globally unique ID and timestamp to each operation, and broadcast the operation sequence to the second operation interface through a cooperation protocol;

[0145] The conflict resolution module is used to resolve conflicts in the operation sequence based on the merging rules of the conflict-free copy data type or the timestamp priority if multiple terminals concurrently modify the same attribute.

[0146] The operation execution module is used to update the corresponding component attributes in the second operation interface according to the operation sequence, so as to complete the bidirectional synchronization between the first operation interface and the second operation interface.

[0147] Figure 3 The method for synchronously updating low-code components provided in this application embodiment can be applied to a device. The device 300 may include a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figures does not constitute a limitation of the invention; it can be a bus topology, a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0148] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0149] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.

Claims

1. A method for synchronously updating a low-code component, the method comprising: The application comprises the following steps: When the dynamic component library module is loaded, a corresponding AST template is generated for each low-code component, and a mapping relationship between the component attributes and the AST template is established; In response to a user's attribute modification operation on a target component in a first operation interface, first update data is generated, the AST template of the target component is updated according to the first update data, and differences before and after the update are identified through an AST difference analysis algorithm; The differences are converted into an operation sequence compatible with the conflict-free replicated data type, and a globally unique ID and a timestamp are assigned to each operation, and the operation sequence is broadcast to a second operation interface through a collaboration protocol; If there are concurrent modifications of the same attribute by multiple terminals, the operation sequence is conflict-resolved based on the merging rules of the conflict-free replicated data type or the timestamp priority; The corresponding component attributes are updated in the second operation interface according to the operation sequence, and the bidirectional synchronization of the first operation interface and the second operation interface is completed; In response to a user's attribute modification operation on a target component in a first operation interface, first update data is generated, the AST template of the target component is updated according to the first update data, and differences before and after the update are identified through an AST difference analysis algorithm, comprising: The property object of the target component is proxied using a JavaScript Proxy object to intercept the setting operation of the property; when the property value is modified, a normalized property change event is generated and issued, and the event load at least contains the component instance ID, the modified property path, the old value before modification and the new value after modification; According to the property path in the property change event, the corresponding node in the AST template of the target component is located, and only the value of the node is updated to generate a new AST template object, thereby completing the incremental update of the AST template; The updated AST template and the AST template before the update are compared based on depth-first traversal to identify the addition, deletion and update operations of the nodes, and a structured difference object list is generated; and the difference object list is minimized to filter the style fine-tuning without substantial changes and merge the continuous operations of the same path.

2. The method of claim 1, wherein, A corresponding AST template is generated for each low-code component, comprising: A structured template object is generated, which at least includes: A component type identifier; A set of component attributes, wherein each attribute contains an attribute name, an attribute type and a default value; A set of events that the component can respond to; Slot information of the component.

3. The method of claim 2, wherein, A mapping relationship between the component attributes and the AST template is established, comprising: A unique path identifier is assigned to each attribute of the component; A mapping table is established with the path identifier as the key and the corresponding AST template as the value.

4. The method of claim 1, wherein, The differences are converted into an operation sequence compatible with the conflict-free replicated data type, and a globally unique ID and a timestamp are assigned to each operation, and the operation sequence is broadcast to a second operation interface through a collaboration protocol, comprising: mapping the difference into a corresponding conflict-free replicated data type operation according to its operation type, and converting the attribute path in the difference into a standardized path format; the mapping behaviors include that a difference of ADD type is mapped into an insert operation, a difference of REMOVE type is mapped into a delete operation, and a difference of UPDATE type is mapped into a set operation; allocating a globally unique operation ID and a hybrid logical timestamp for each converted conflict-free replicated data type operation, and encapsulating metadata containing the ID, the timestamp, the operation type, the path, and the operation value; broadcasting the encapsulated operation sequence to the second operation interface through a WebSocket connection; before the broadcasting, applying a delta compression algorithm to the operation data to reduce network load.

5. The method of claim 1, wherein, if there are concurrent modifications of the same attribute by multiple terminals, conflict resolution is performed on the operation sequence based on a merging rule of the conflict-free replicated data type or a timestamp priority, including: when an operation from another collaborative terminal is received, checking whether there is a local operation that has not been synchronized to the terminal at the target path of the operation; if there is, it is determined as a concurrent modification conflict; merging the conflict operations according to a preset priority rule; applying the operation result generated after the merging to the local state, and updating the AST template and the view, to ensure that the final states of all terminals are consistent; the priority rule includes: a timestamp priority rule: comparing the timestamps carried in the conflict operations, and preferentially applying the operation with a later timestamp; an operation type priority rule: if the operations cannot be determined according to the timestamps or the timestamps are the same, preferentially applying the operation of the delete type; an attribute-specific rule: presetting an attribute processing strategy table, when the path of a conflict operation matches a style attribute in the table, a corresponding custom merging function is called instead of simply selecting one of the operations.

6. The method of claim 1, wherein, updating the corresponding component attributes in the second operation interface according to the operation sequence, to complete the bidirectional synchronization between the first operation interface and the second operation interface, including: the second operation interface receives the broadcasted operation sequence through the collaboration protocol, parses the operation metadata including the operation ID, type, target path, and value, and verifies the global uniqueness of the ID, and discards the repeated operations that have been processed; according to the parsed target path, locating the corresponding target component instance in the component tree of the current document; according to the operation type, calling a corresponding state update function to apply the operation value to the corresponding attribute of the target component instance; triggering the view rendering engine of the second operation interface to re-render the user interface according to the updated component state, thereby completing the visual state synchronization with the first operation interface, and sending a confirmation feedback to the coordination layer that the operation is successfully applied.

7. A system for synchronized updating of low-code components, characterized in that, including: a template loading module, configured to generate a corresponding AST template for each low-code component when the dynamic component library module is loaded, and establish a mapping relationship between the component attributes and the AST template; The update parsing module is used to generate first update data in response to the user's modification operation of the target component's attributes in the first operation interface, update the AST template of the target component according to the first update data, and identify the differences before and after the update through the AST difference analysis algorithm. The operation broadcast module is used to convert the differences into an operation sequence compatible with conflict-free copy data types, assign a globally unique ID and timestamp to each operation, and broadcast the operation sequence to the second operation interface through a cooperation protocol; The conflict resolution module is used to resolve conflicts in the operation sequence based on the merging rules of the conflict-free copy data type or the timestamp priority if multiple terminals concurrently modify the same attribute. The operation execution module is used to update the corresponding component attributes in the second operation interface according to the operation sequence, so as to complete the bidirectional synchronization between the first operation interface and the second operation interface. In response to a user's modification of the target component's attributes in the first operation interface, first update data is generated. The AST template of the target component is updated based on the first update data, and the differences before and after the update are identified using an AST difference analysis algorithm, including: The JavaScript Proxy object proxies the property object of the target component, intercepting its property setting operations; when the property value is modified, a normalized property change event is generated and emitted, the event payload of which includes at least the component instance ID, the path of the modified property, the old value before modification, and the new value after modification. Based on the attribute path in the attribute change event, locate the corresponding node in the AST template of the target component, update only the value of the node, generate a new AST template object, and thus complete the incremental update of the AST template. The updated AST template is compared with the original AST template using a depth-first traversal to identify node additions, deletions, and updates, generating a structured list of differences. This list of differences is then minimized to filter out style tweaks that do not substantially change and to merge consecutive operations with the same path.

8. A device for synchronously updating low-code components, characterized in that, include: Memory, used to store the synchronous update program for low-code components; A processor, configured to implement the steps of the low-code component synchronization update method as described in any one of claims 1-6 when executing the synchronization update procedure for the low-code component.

9. A computer readable storage medium storing a computer program, characterized in that, The readable storage medium stores a synchronization update program for a low-code component, which, when executed by a processor, implements the steps of the synchronization update method for a low-code component as described in any one of claims 1-6.

Images