Methods, electronic devices, and storage media for converting design drafts to code.

Abstract

This invention provides a method, electronic device, and storage medium for converting design drafts into code, including: acquiring structured difference data between an updated version of the design draft and the current version; analyzing the structured difference data to identify the type of change intent and the scope of impact; analyzing existing front-end code to identify business logic nodes that need to be retained; generating a target update strategy based on the type of change intent, the scope of impact, and the business logic nodes; based on the target update strategy, converting the current version of the design draft into a design syntax tree, converting the existing front-end code into a code syntax tree, representing the business logic nodes as logic syntax trees, merging the design syntax tree, code syntax tree, and logic syntax tree to retain the business logic nodes while applying the design draft update; and generating updated front-end code based on the merged comprehensive syntax tree. This invention can retain business logic during the code update process, improving the efficiency and accuracy of code updates.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method for converting design drafts into code, an electronic device, and a storage medium. Background Technology

[0002] In the current mainstream front-end development workflow, after a designer updates the design draft, the existing front-end code needs to be updated accordingly. The current method for converting design drafts to code is to use a design draft to code conversion tool to generate updated front-end code from the entire design draft, overwriting the existing front-end code.

[0003] However, this method requires a complete regeneration of the front-end code, which consumes a lot of computing resources and will cause the business logic in the existing front-end code to be completely lost. After each update of the front-end code, the developers need to manually add it back, resulting in high maintenance costs. Summary of the Invention

[0004] This invention provides a method, electronic device, and storage medium for converting design drafts into code, which can retain business logic during code updates and improve the efficiency and accuracy of code updates.

[0005] In a first aspect, the method for converting design drafts to code provided in embodiments of the present invention includes: In response to a design draft update message, the system retrieves structured difference data between the updated and current versions of the design draft. This structured difference data is analyzed to identify the type of change intent and its scope of impact. Existing front-end code is analyzed to identify business logic nodes that need to be retained; the existing front-end code corresponds to the current design draft. Based on the change intent type, scope of impact, and business logic nodes, a target update strategy is generated. Based on the target update strategy, the current version of the design draft is converted into a design syntax tree, the existing front-end code is converted into a code syntax tree, and business logic nodes are represented as logic syntax trees. The design syntax tree, code syntax tree, and logic syntax tree are merged to retain business logic nodes while applying the design draft update. Updated front-end code is generated based on the merged composite syntax tree; this updated front-end code corresponds to the updated version of the design draft.

[0006] Secondly, the design draft to code conversion method apparatus provided in the embodiments of the present invention includes: The acquisition module is used to respond to design draft update messages and acquire structured difference data between the updated version of the design draft and the current version of the design draft; The first identification module is used to analyze structured difference data to identify the type of change intent and the scope of impact; The second identification module is used to analyze the existing front-end code to identify the business logic nodes that need to be retained; the existing front-end code is the front-end code corresponding to the current design draft. The generation module is used to generate target update strategies based on change intent type, scope of impact, and business logic nodes; The merging module is used to convert the current version of the design draft into a design syntax tree, convert the existing front-end code into a code syntax tree, and represent business logic nodes as a logic syntax tree based on the target update strategy. The design syntax tree, code syntax tree, and logic syntax tree are merged to retain business logic nodes while updating the application design draft. The updated front-end code is generated based on the merged comprehensive syntax tree. The updated front-end code is the front-end code corresponding to the updated version of the design draft.

[0007] Thirdly, the electronic device provided in the embodiments of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the method of converting design drafts to code as in any embodiment of the present invention.

[0008] Fourthly, the computer-readable storage medium provided in the embodiments of the present invention stores computer instructions thereon, the computer instructions being used to cause a processor to execute a method for converting a design draft into code as described in any embodiment of the present invention.

[0009] Fifthly, the computer program product provided in the embodiments of the present invention includes a computer program that, when executed by a processor, implements the method for converting design drafts to code as described in any embodiment of the present invention.

[0010] In this embodiment of the invention, in response to a design draft update message, structured difference data between the updated and current versions of the design draft is obtained. This structured difference data is analyzed to identify the type and scope of change intent, accurately mapping design-level change intents to the code level and providing clear targets and boundaries for subsequent differentiated code updates. Existing front-end code is analyzed to identify business logic nodes that need to be retained, preventing automated updates from disrupting core business functions and ensuring the continuity and stability of interaction logic. Based on the change intent type, scope of impact, and business logic nodes, a target update strategy is generated, enabling differentiated update strategies for different types of design draft changes. Based on the target update strategy, the current version of the design draft is converted into a design syntax tree, the existing front-end code is converted into a code syntax tree, and business logic nodes are represented as logic syntax trees. The design syntax tree, code syntax tree, and logic syntax tree are merged to retain business logic nodes while applying design draft updates. Updated front-end code is generated based on the merged comprehensive syntax tree, preserving business logic during code updates, achieving precise incremental updates, avoiding the waste of computational resources caused by generating a full new version of code, and ensuring update efficiency. Attached Figure Description

[0011] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart illustrating a method for converting design drafts to code provided in an embodiment of the present invention; Figure 2 This is another flowchart illustrating the method for converting design drafts to code provided in this embodiment of the invention; Figure 3 This is a schematic diagram of a device for converting design drafts to code provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0014] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0015] Figure 1 This is a flowchart illustrating a method for converting design drafts to code according to an embodiment of the present invention. This method is applicable to scenarios where updated front-end code is generated based on an updated design draft. The method can be executed by a device for converting design drafts to code, as provided in this embodiment. This device can be implemented in software and / or hardware. In one specific embodiment, the device can be integrated into an electronic device, such as a computer or server, or it can be integrated into a software system, such as a design draft to code conversion system. The following embodiment illustrates this by integrating the design draft to code conversion device into a software system. See also... Figure 1 The method for converting design drafts to code in this embodiment may include the following steps: Step 101: In response to the design draft update message, obtain the structured difference data between the updated version of the design draft and the current version of the design draft.

[0016] A design draft is a front-end design file generated by a designer using design tools. It specifically describes the visual elements, layout structure, and style specifications of the front-end page. A design draft update message is a notification message actively pushed to the system after a version update event occurs. A design draft update message typically includes a design draft identifier and an updated version identifier. The updated version design draft is the latest version of the design draft saved on the design platform, as indicated by the design draft update message. The current version design draft refers to the design draft version corresponding to the existing front-end code, usually the version preceding the updated version design draft.

[0017] Structured difference data describes the specific changes between the updated and current versions of a design draft in a structured format. The structured format can be JSON, XML, etc. Structured difference data may include the identifier of the changed design element, the change type, the historical values ​​of the changed attributes and their current values ​​after the change, and the hierarchical path of the changed design element.

[0018] For example, a structured difference data can be "{Design draft identifier: Design draft 1, Design draft version: Version 2, Difference node list: [Change type: Modify, Change element: Node 123, Change element name: Login button, Change attribute: [{Fill color: {Historical value: #002AFF, Current value: #00A898}]]}".

[0019] Specifically, by subscribing to design drafts on the design platform, the platform can send an update message when a version of the design draft is updated. This update message includes the version number of the updated design draft. In response to the update message, a difference data request message is sent to the design platform, which includes the version number of the current design draft. The design platform calculates structured difference data based on the version numbers of the updated and current design drafts, using the data stored on it, and sends it to the design draft to code conversion system.

[0020] Step 102: Analyze the structured difference data to identify the type of change intent and the scope of impact.

[0021] The change intent type is determined based on structured difference data, and is the type of main update intent of the updated design draft relative to the current design draft.

[0022] For example, change intent types can include "visual optimization," "layout restructuring," and "component replacement." "Visual optimization" means that this design update aims to adjust the visual attributes of design elements, such as color, font, and rounded corners; "layout restructuring" means that this design update changes the structural organization of design elements on the page, such as modifying the layout mode of containers from vertical to horizontal, adjusting the order of elements, adding or deleting frames used for grouping, etc.; "component replacement" means that this design update replaces a component instance in the original design with another different component.

[0023] Specifically, structured difference data may simultaneously possess multiple change intent types. These change intent types can be represented by vectors, where each dimension represents the probability that the structured difference data belongs to the corresponding change intent type. The probabilities of each dimension are calculated independently. When the probability of a certain dimension exceeds a preset probability threshold, it can be determined that the update has a change intent of that type. For example, "[0.5,0,0,2]" represents that the current design draft change has an 80% probability of belonging to "visual optimization," a 0% probability of belonging to "layout reconstruction," and a 20% probability of belonging to "component replacement." If the preset probability threshold is 50%, the update can be determined to be of the "visual optimization" type. Multidimensional feature vectors can be extracted based on the structured difference data, and then these multidimensional feature vectors can be input into deep learning models, traditional decision tree classification models, or rule engines to identify change intent types.

[0024] The scope of impact refers to the set of front-end code affected by this design draft update event. This scope can include affected components and affected files. Specifically, design elements in the design draft have a pre-defined mapping relationship with code components in the existing front-end code. First, based on the mapping relationship, the code component identifiers corresponding to the changed design element identifiers contained in the structured difference data can be used to identify the directly affected components. Then, based on the dependencies between code components (e.g., if component A's template references component B, then component B depends on component A), the indirectly affected components can be identified. Finally, the code files containing the affected components and indirectly affected components are identified as the affected files.

[0025] Step 103: Analyze the existing front-end code to identify the business logic nodes that need to be retained.

[0026] The existing front-end code refers to the front-end code corresponding to the current design draft. The business logic nodes that need to be retained are the code snippets related to the business functions that still need to be implemented after the design draft is updated. Typical business logic nodes include event handlers starting with "on", state management hooks, application programming interface (API) call functions, and route navigation functions.

[0027] Static code analysis can be performed on existing front-end code to identify business logic nodes that need to be retained. Specifically, business logic patterns can be pre-defined; existing front-end code can be converted into a code syntax tree; the pre-defined set of business logic patterns can be matched with the nodes of the code syntax tree, and the matched nodes can be identified as business logic nodes; finally, the location of these business logic nodes in the front-end code (e.g., file path, line number, column number) and the node content can be stored in list form.

[0028] Step 104: Generate the target update strategy based on the change intent type, scope of impact, and business logic nodes.

[0029] The target update strategy is a set of operation instruction sequences used to generate updated front-end code based on the updated version design draft. It specifies the specific code update actions that should be performed for specific change intent types, specific impact scopes, and specific business logic nodes.

[0030] Specifically, for a design update with the intent type of "visual optimization", the target update strategy could be: [locate style file 1, generate the code syntax tree of file 1, generate the design syntax tree of the updated design, locate the target CSS selector A, replace the background color attribute value X, and replace the rounded corner attribute value Y]. For a design update with the intent type of "layout reconstruction", the target update strategy could be: [locate page file 2, generate the code syntax tree of file 2, generate the design syntax tree of the updated design, reorganize the node order of the code syntax tree according to the design syntax tree, and retain the original conditional rendering instructions and event bindings].

[0031] Specifically, based on the change intent type, scope of impact, and business logic nodes, the method for generating a target update strategy can be as follows: First, determine the type of scope of impact. The type of scope of impact can include the types of affected components and the types of affected files. Affected component types include CSS components, JavaScript (JS) components, TypeScript (TS) components, etc. Affected file types include .CSS style files, .vue page files, .vue component files, etc. Then, based on the affected components, determine the affected business logic areas from the business logic nodes that need to be retained, and determine the type of business logic area. The business logic area type can be an event area, a state area, an application programming interface (API) call area, a conditional rendering area, etc. Based on the enumerated values ​​of the change intent type, the types of affected components and / or the types of affected files, and the types of business logic areas, query the strategy template mapping table to determine the set of strategy template identifiers corresponding to this design draft update, and then consult the update strategy template library to obtain the update strategy template. The strategy template mapping table is a three-dimensional mapping table pre-stored in the system. The three dimensions are, in order, the change intent type, the types of affected components / affected files, and the type of business logic area. Each element of the mapping table corresponds to a strategy template identifier. The update strategy template can be a sequence of functions used to perform code updates. Finally, the update strategy template is instantiated based on the affected files and business logic nodes to generate the target update strategy. For example, the affected files and business logic nodes can be passed as parameters to the function sequence that performs the update to generate a target update strategy that can be executed directly.

[0032] Step 105: Based on the target update strategy, convert the current version design draft into a design syntax tree, convert the existing front-end code into a code syntax tree, represent business logic nodes as logic syntax trees, and merge the design syntax tree, code syntax tree, and logic syntax tree to retain business logic nodes while updating the application design draft.

[0033] A design syntax tree is an abstract syntax tree describing the design elements, their hierarchical relationships, and attribute information contained in a design draft. The nodes of a design syntax tree are design elements, and each node records its node name, node type, node identifier (i.e., design element identifier), geometric attributes, style attributes, and a list of child nodes. A code syntax tree is an abstract syntax tree describing the front-end code syntax units and their hierarchical relationships. The nodes of a code syntax tree are component or code element nodes, such as bound functions and bound state values. A logic syntax tree is an abstract syntax tree describing the business logic nodes that need to be retained and their hierarchical relationships. A logic syntax tree is usually a subtree of a code syntax tree, retaining the complete content and hierarchical context of the business logic nodes in the code syntax tree, but excluding non-logic nodes related to style and layout. Specifically, a group of logical nodes related to a specific business function can be organized into a logic syntax tree.

[0034] Specifically, the design syntax tree can be compared with the code syntax tree to identify nodes to be updated from the code syntax tree; the code syntax tree can be compared with the logic syntax tree to identify nodes to be retained from the code syntax tree; it can be determined whether there are conflicts between the nodes to be updated and the nodes to be retained. If there are conflicts, the nodes to be updated need to be re-identified according to preset rules. The method for re-identifying the nodes to be updated can be as follows: First, identify conflicting nodes from the nodes to be updated based on the nodes to be retained and determine the conflict type of the conflicting nodes; if the conflict type is a style conflict, retain the conflicting nodes in the nodes to be updated; if the conflict type is a logic conflict, delete the conflicting nodes from the nodes to be updated; after re-identifying the nodes to be updated, a conflict resolution report can also be generated to inform the developers of the conflicting nodes in this update and whether the conflicting nodes have been updated; finally, based on the design element node content corresponding to the nodes to be updated in the design syntax tree, update the nodes to be updated in the code syntax tree, while retaining the nodes to be retained in the code syntax tree, to obtain a comprehensive syntax tree.

[0035] Step 106: Generate updated front-end code based on the merged comprehensive syntax tree.

[0036] The comprehensive syntax tree is a syntax tree based on the front-end code corresponding to the updated design draft, applying the design draft changes and retaining all necessary business logic nodes. The updated front-end code is the front-end code corresponding to the updated version of the design draft.

[0037] Specifically, code generation tools can be used to convert the comprehensive syntax tree into updated front-end code. Once the updated front-end code is obtained, it can be backed up, and an update completion message can be sent to the developers via email or a notification through a user interface. The update completion message may include a list of updated code files, a change summary, a conflict resolution report, and suggested steps for manual review.

[0038] In this embodiment, in response to a design draft update message, structured difference data between the updated and current versions of the design draft is obtained. This structured difference data is analyzed to identify the type and scope of change intent, accurately mapping design-level change intents to the code level and providing clear targets and boundaries for subsequent differentiated code updates. Existing front-end code is analyzed to identify business logic nodes that need to be retained, preventing automated updates from disrupting core business functions and ensuring the continuity and stability of interaction logic. Based on the change intent type, scope of impact, and business logic nodes, a target update strategy is generated, enabling differentiated update strategies for different types of design draft changes. Based on the target update strategy, the current version of the design draft is converted into a design syntax tree, the existing front-end code is converted into a code syntax tree, and business logic nodes are represented as logic syntax trees. The design syntax tree, code syntax tree, and logic syntax tree are merged to retain business logic nodes while applying design draft updates. Updated front-end code is generated based on the merged comprehensive syntax tree, preserving business logic during code updates, achieving precise incremental updates, avoiding the waste of computational resources caused by generating a full new version of code, and ensuring update efficiency.

[0039] The following is combined Figure 2 The method for converting design drafts to code provided in the embodiments of the present invention is further explained. Figure 2 This is another flowchart illustrating the method for converting design drafts to code provided in this embodiment of the invention. (See attached diagram.) Figure 2 The method for converting design drafts to code in this embodiment may include the following steps: Step 201: Subscribe to design drafts on the design platform so that the design platform can send design draft update messages when a version of the design draft is updated.

[0040] The design update message includes the version number of the updated design draft.

[0041] A design platform is a third-party platform that provides design creation, storage, and version management. Specifically, a design platform provides design tools for designers to create and edit design drafts, and also provides application programming interfaces or network hooks that allow external systems to listen for design draft update events.

[0042] Step 202: In response to the design draft update message, send a difference data request message to the design platform so that the design platform can calculate and send structured difference data based on the updated version of the design draft and the current version of the design draft.

[0043] The difference data request message is a request message sent by the design draft to code system to the design platform. It carries at least the version identifier of the current version of the design draft and the version identifier of the updated version of the design draft.

[0044] Step 203: Obtain structured difference data from the design platform.

[0045] Specifically, a web hook can be created on the design platform to subscribe to design draft version update events. This allows the platform to proactively push update messages to the design-to-code system when a design draft is updated, with the update message containing the version number of the updated design draft. In response to the update message, the system sends a difference data request message to the design platform, carrying the version number of the current design draft. The design platform, based on the version numbers of the current and updated design drafts, uses its stored data on the updated and current design drafts to calculate and generate structured difference data, which is then returned to the design-to-code system.

[0046] Step 204: Extract multidimensional feature vectors based on structured differential data.

[0047] Multidimensional feature vectors (MVAs) are a set of numerical features extracted from structured variance data to describe the characteristics of change. MVAs can be used as input to machine learning models to identify types of change intent.

[0048] Specifically, the multidimensional feature vector can include dimensions such as changed element type, changed attribute type, changed location type, and changed scope type. Changed element type refers to the statistical characteristics of the type of the changed design element, such as the frequency or proportion of changes to text, frames, or standard components. Changed attribute type refers to the statistical characteristics of the category of changed attributes, such as the frequency or proportion of changes to background color, rounded corners, and layout mode. Changed location type describes the distribution characteristics of the changed design element's position in the design draft, such as the depth of the changed element in the design draft hierarchy, whether it is located on the root artboard, or whether it belongs to a component. Changed scope type is the statistical characteristics of the changed design element, such as the frequency or proportion of changes to a single node, batch node changes, or subtree changes.

[0049] Step 205: Input the multidimensional feature vector into the change recognition depth model to identify the change intent type.

[0050] The change recognition deep model is a deep learning model that takes multi-dimensional feature vectors as input and outputs a probability distribution of change types. Change recognition deep models can employ architectures such as multilayer perceptrons, convolutional neural networks, long short-term memory networks, or graph neural networks.

[0051] Specifically, historical design draft change data can be collected, and corresponding change intent type labels can be obtained through manual annotation as training samples. The labels are change intent type vectors, for example, [1,0,0] represents visual optimization. Multi-dimensional feature vectors are extracted from the historical design draft change data of each sample and input into the initial change recognition deep model. The loss function is calculated based on the change intent probability vector output by the model. The loss function can be the cross-entropy loss function or the mean squared error loss function. The gradient of the loss function is backpropagated to iteratively optimize the initial change recognition deep model until the loss function converges, resulting in the trained change recognition deep model.

[0052] Step 206: Based on the preset mapping relationship between design elements and code components, as well as the dependency relationship between code components, identify the affected components from the existing front-end code.

[0053] Specifically, the pre-defined mapping relationship between design elements and code components can be established by adding custom attributes to design elements in the design tool, with the attribute value being the identifier of the design element, and then annotating the corresponding design element identifier in the code component; alternatively, it can be established by storing the design element identifiers and code component identifiers in a mapping lookup table. When it is necessary to identify affected components, firstly, based on the pre-defined mapping relationship, find the code component identifier corresponding to each changed design element identifier in the structured difference data, and mark these code components as directly affected components; then, analyze the dependencies between code components, and through backpropagation of the dependency graph, mark all parent components that depend on the directly affected components as indirectly affected components.

[0054] Step 207: Identify the front-end code file to which the affected component belongs as the affected code file.

[0055] Specifically, you can compile a complete list of affected files by summarizing all the code files belonging to the directly and indirectly affected components.

[0056] Step 208: Convert the existing front-end code into a code syntax tree.

[0057] Step 209: Match the preset business logic pattern with the code syntax tree, and determine the matched node as the business logic node.

[0058] Specifically, business logic patterns can include predefined regular expressions, predefined lists of node names, lists of node attribute names, or predefined rules, such as using "^on[AZ]" to match event handling functions that begin with "on".

[0059] Step 210: Determine the types of affected components and affected files.

[0060] The affected component type refers to the technical attribute classification of the front-end code component corresponding to the design element that has changed in the design draft. The affected file type refers to the format or framework classification of the code file containing the affected component, such as a .CSS style file, a .vue page file, or a .vue component file. The affected component type, affected file type, and business logic area type can be encoded as enumeration values ​​of an enumeration body. For example, component type enumeration: {CSS component: 0, JS component: 1, TS component: 2}, file type enumeration: {CSS style file: 0, page file: 1, component file: 2}.

[0061] Step 211: Identify the affected business logic nodes from the business logic nodes based on the affected components.

[0062] Step 212: Determine the business logic region to which the affected business logic node belongs, and determine the type of the business logic region.

[0063] The business logic region is the area in the code syntax tree where business logic nodes reside. The business logic region type can also be encoded as the enumeration values ​​of an enumeration body. For example, business logic region types can be event areas, state areas, application programming interface (API) call areas, and conditional rendering areas. The event area contains event binding statements and their corresponding handler function definitions; the state area contains reactive state definitions and state read and update statements; the API call area contains function calls that send API requests and their response processing logic; and the conditional rendering area contains instructions that control the display and hiding of elements and their conditional expressions.

[0064] Step 213: Determine the update strategy template based on the change intent type, the type of affected component, the type of affected file, and the type of business logic area.

[0065] Specifically, a policy template mapping table can be pre-stored in the system. This policy template mapping table is a three-dimensional table, with the three dimensions being: change intent type, affected component type / affected file type, and business logic area type. Each element in the mapping table corresponds to a policy template identifier. The policy template identifier is used to index the specific update policy template.

[0066] An update strategy template is a predefined execution plan for a specific combination of change intent types, affected component types, affected file types, and business logic area types. It consists of a series of sequentially arranged atomic operations. Specifically, an update strategy template can be a sequence of functions used to perform code updates, executed in a specific order. When a design update matches multiple update strategy templates simultaneously, these templates can be arranged according to a preset update order and executed sequentially. For example, the preset update order rule could be: "component replacement" is executed before "layout reorganization" templates, and "layout reorganization" is executed before "visual update" templates.

[0067] Step 214: Generate the target update strategy based on the affected files, business logic nodes, and update strategy template.

[0068] Specifically, the affected files and business logic nodes can be passed as parameters to the function sequence that executes the update, generating a target update strategy that can be executed directly. For example, the target strategy for a design draft update can be [file1 = file search function (filename1), code syntax tree1 = code syntax tree generation function (file1), design syntax tree1 = design syntax tree generation function (update design draft), syntax tree merging function (code syntax tree1, design syntax tree1)].

[0069] Step 215: Based on the target update strategy, convert the current version design draft into a design syntax tree, convert the existing front-end code into a code syntax tree, and represent the business logic node as a logic syntax tree.

[0070] Step 216: Compare the design syntax tree with the code syntax tree, and determine the nodes to be updated from the code syntax tree.

[0071] A node to be updated is a node in the code syntax tree that has a mapping relationship with a design element in the design syntax tree that has changed, and for which the target update strategy requires modification. For example, if the change intent type is "visual optimization", the node to be updated is usually a style declaration node in the code syntax tree of a .CSS file, or a style-related property node in the code syntax tree of a component or page file.

[0072] If the change intent type is "layout refactoring", the nodes to be updated may be element nodes or layout container nodes in the template section of the code syntax tree of the component or page file. If the change intent type is "component replacement", the nodes to be updated mainly include: import declaration nodes of the old component in the code syntax tree of the component or page file, nodes in the template section that call the old component, and event property nodes and property passing nodes bound to the old component. These nodes need to be replaced with new component nodes.

[0073] Step 217: Compare the code syntax tree with the logic syntax tree, and determine the nodes to be retained from the code syntax tree.

[0074] Nodes to be retained are those nodes in the code syntax tree that belong to the logic syntax tree (i.e., business logic nodes) and their direct or indirect dependencies. Specifically, even if the existing code is updated according to the design draft, business logic nodes and the dependencies between nodes usually need to be retained to ensure the continuity of business functions.

[0075] For example, if an event handler function references a reactive variable, the business logic node that defines that reactive variable should also be considered a node to be retained.

[0076] Step 218: Determine if there is a conflict between the node to be updated and the node to be retained. If there is, proceed to step 219; otherwise, proceed to step 223.

[0077] Specifically, conflicts between nodes to be updated and nodes to be retained arise because the code corresponding to the design elements updated in the design draft and the code corresponding to the existing business logic have different modification requirements at the same location. Design draft updates typically focus on the visual presentation layer, adjusting visual attributes such as color, size, layout order, and component appearance; while business logic nodes involve dynamic behavior, data flow, and user interaction. Conflicts occur when the intersection of the two (i.e., the same code node) requires changes according to the design draft but needs to remain unchanged due to business logic. When conflicts exist between nodes to be updated and nodes to be retained, the pre-defined processing logic in steps 219 to 222 can automatically eliminate the conflict. After the conflict is eliminated, a conflict resolution report can be generated to inform the developer of the conflicting nodes in this update and whether updates were performed on the conflicting nodes. If the conflict cannot be eliminated automatically, a message can be sent to the developer requesting manual handling.

[0078] Step 219: Identify conflicting nodes from the nodes to be updated based on the nodes to be retained.

[0079] A conflict node is a code syntax tree node that simultaneously belongs to both the set of nodes to be updated and the set of nodes to be retained. That is, the node needs to adapt to changes in the design draft, but also needs to remain unchanged due to the business logic it carries. Specifically, the nodes in the intersection of the set of nodes to be updated and the set of nodes to be retained can be identified as conflict nodes.

[0080] Step 220: Determine the conflict type of the conflicting nodes. If the conflict type is a style conflict, proceed to step 221. If the conflict type is a logical conflict, proceed to step 222.

[0081] Conflict types are categorized based on the relationship between the design changes and business logic nodes at the conflicting nodes. The conflict type determines the resolution strategy to be adopted during subsequent merging.

[0082] Step 221: Retain conflicting nodes among the nodes to be updated.

[0083] When the conflicting node type is a style conflict, the changes to the conflicting node mainly involve visual attributes, while the business logic attached to the node has no direct functional dependency on the visual attributes. For example, the design draft requires changing the background color of button component A from blue to green. At the same time, this button component node is bound to a click-triggered event, and the change in background color will not affect the button's functionality. Therefore, the conflict type of button component node A is a style conflict.

[0084] Specifically, design changes aim to alter the visual attributes of nodes while preserving their interactive behavior. Since existing styles are often outdated visual descriptions and lack business functionality, in cases of style conflict, directly adopting the new style from the design draft to update the node to be updated will not disrupt the component's interactive behavior. Therefore, the conflicting node can be retained in the node to be updated.

[0085] Step 222: Remove conflicting nodes from the nodes to be updated.

[0086] A conflict type classified as a logical conflict means that changes to the design will contradict the business logic in the existing code. For example, the design replaces an input box component node B with a button component. The button component does not support the "send input content" event bound to the original input box component node B, causing subsequent business logic to fail. Therefore, the conflict type for the input box component node B is a logical conflict.

[0087] Specifically, when the conflicting node type is a logical conflict, if the application design changes, it will lead to the loss or abnormality of business functions. Therefore, when a logical conflict occurs, the highest priority should be to preserve the original business logic, that is, delete the conflicting node from the node to be updated and skip the update of the conflicting node.

[0088] Step 223: Update the nodes to be updated in the code syntax tree, while retaining the nodes to be retained in the code syntax tree, to obtain the comprehensive syntax tree.

[0089] Specifically, it can traverse the nodes to be updated in the code syntax tree, and find the corresponding design element in the design syntax tree based on the preset mapping relationship between design elements and code components. The current attribute value of the code node is updated according to the current attribute value of the design element to obtain the updated node to be updated. For nodes to be retained, they are skipped directly during the traversal without any modification.

[0090] Step 224: Generate updated front-end code based on the merged comprehensive syntax tree. The updated front-end code is the front-end code corresponding to the updated version design draft.

[0091] In this embodiment, a design platform subscribes to design drafts, enabling the platform to send design draft update messages when a version of the design draft is updated. In response to the design draft update message, a difference data request message is sent to the design platform, allowing the platform to calculate and send structured difference data based on the updated and current versions of the design draft. Obtaining structured difference data from the design platform enables timely response to design draft update events. The process involves: obtaining structured difference data from the design platform; extracting multi-dimensional feature vectors based on the structured difference data; and inputting these multi-dimensional feature vectors into a change recognition deep model to identify the change intent type. This model can capture subtle differences in the features of the updated design draft content across multiple dimensions and consider the dependencies between differences in different dimensions. This system improves the accuracy of identifying change intent types; based on the preset mapping relationship between design elements and code components, as well as the dependencies between code components, it identifies affected components from the existing front-end code; it identifies the front-end code files to which the affected components belong as affected code files; identifying the front-end code files to which the affected components belong as affected code files enables precise positioning of the scope of change impact, reducing redundant modifications; it converts the existing front-end code into a code syntax tree; it matches preset business logic patterns with the code syntax tree, identifying the matched nodes as business logic nodes, enabling structured extraction of business logic and ensuring the integrity of business logic during code updates; it determines the type of affected components and the affected files. The process involves: identifying the affected business logic nodes from the business logic nodes based on the affected components; determining the business logic region to which the affected business logic nodes belong and the type of the business logic region; determining an update strategy template based on the change intent type, the type of the affected components, the type of the affected files, and the type of the business logic region; generating a target update strategy based on the affected files, business logic nodes, and the update strategy template, which comprehensively considers the design draft change intent and the structural characteristics of the specific components of the code to generate a more targeted and executable update strategy; and, based on the target update strategy, converting the current version of the design draft into a design syntax tree, converting the existing front-end code into a code syntax tree, and converting the business logic node table... The code is presented as a logical syntax tree. The design syntax tree is compared with the code syntax tree to identify nodes to be updated from the code syntax tree. The code syntax tree is then compared with the logical syntax tree to identify nodes to be retained from the code syntax tree. A conflict is determined between the nodes to be updated and those to be retained. If a conflict exists, the conflicting nodes are identified from the nodes to be updated based on the nodes to be retained. The conflict type is determined. If the conflict type is a style conflict, the conflicting nodes are retained in the nodes to be updated. If the conflict type is a logical conflict, the conflicting nodes are deleted from the nodes to be updated. This process automatically resolves conflicts during code merging, avoiding logical errors caused by direct merging, and protecting business logic while maximizing the application of design updates.

[0092] Figure 3 This is a schematic diagram of a device for converting design drafts to code provided in an embodiment of the present invention, as shown below. Figure 3 As shown, the device includes: The acquisition module 301 is used to respond to the design draft update message and acquire the structured difference data between the updated version of the design draft and the current version of the design draft; The first identification module 302 is used to analyze structured difference data to identify the type of change intent and the scope of impact; The second identification module 303 is used to analyze the existing front-end code to identify the business logic nodes that need to be retained; the existing front-end code is the front-end code corresponding to the current design draft; The generation module 304 is used to generate a target update strategy based on the change intent type, the scope of impact, and the business logic node. The merging module 305 is used to convert the current version of the design draft into a design syntax tree, convert the existing front-end code into a code syntax tree, and represent business logic nodes as a logic syntax tree based on the target update strategy. The design syntax tree, code syntax tree, and logic syntax tree are merged to retain business logic nodes while updating the application design draft. The updated front-end code is generated based on the merged comprehensive syntax tree. The updated front-end code is the front-end code corresponding to the updated version of the design draft.

[0093] In one embodiment, the acquisition module 301 is specifically used for: Subscribe to design drafts on the design platform so that the platform can send design draft update messages when a version of the design draft is updated. The design draft update message includes the version number of the updated design draft. In response to a design draft update message, a difference data request message is sent to the design platform so that the design platform can calculate and send structured difference data based on the updated design draft and the current design draft. The difference data request message includes the version number of the updated design draft and the version number of the current design draft. Obtain structured difference data from the design platform.

[0094] In one embodiment, the first identification module 302 analyzes the structured difference data to identify the type of change intent, including: Extracting multidimensional feature vectors based on structured differential data; Input multidimensional feature vectors into the change recognition deep model to identify the type of change intent.

[0095] In one embodiment, the scope of impact includes affected components and affected files. The first identification module 302 analyzes the structured difference data to identify the scope of impact, including: Based on the pre-defined mapping relationship between design elements and code components, as well as the dependency relationship between code components, the affected components are identified from the existing front-end code; Identify the front-end code file containing the affected component as the affected code file.

[0096] In one embodiment, the second identification module 303 is specifically used for: Convert existing front-end code into a code syntax tree; The preset business logic pattern is matched with the code syntax tree, and the matched node is determined as the business logic node.

[0097] In one embodiment, the generation module 304 is specifically used for: Determine the types of affected components and files; The affected business logic nodes are determined from the affected components; Determine the business logic region to which the affected business logic node belongs, and determine the type of the business logic region; Determine the update strategy template based on the change intent type, the type of affected component, the type of affected file, and the type of business logic area; Generate the target update strategy based on the affected files, business logic nodes, and update strategy template.

[0098] In one embodiment, the merging module 305 merges the design syntax tree, code syntax tree, and logic syntax tree to retain business logic nodes while the application design draft is updated, including: The design syntax tree is compared with the code syntax tree, and the nodes to be updated are determined from the code syntax tree; The code syntax tree is compared with the logical syntax tree, and the nodes to be retained are determined from the code syntax tree; Determine if there is a conflict between the node to be updated and the node to be retained; If it exists, then the node to be updated is re-determined based on the node to be retained, the node to be updated in the code syntax tree is updated, and the node to be retained in the code syntax tree is retained to obtain the comprehensive syntax tree; If it does not exist, update the nodes to be updated in the code syntax tree, and retain the nodes to be retained in the code syntax tree to obtain the composite syntax tree.

[0099] In one embodiment, re-determining the node to be updated based on the node to be retained includes: Conflicting nodes are identified from the nodes to be updated based on the nodes to be retained; Determine the conflict type of the conflicting nodes; In cases where the conflict type is style conflict, the conflicting node is retained in the node to be updated; In the case of a logical conflict, remove the conflicting node from the nodes to be updated.

[0100] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is merely an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the functional modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0101] The apparatus of this invention, in response to a design draft update message, acquires structured difference data between the updated and current versions of the design draft; analyzes the structured difference data to identify the type and scope of change intent, accurately mapping design-level change intent to the code level and providing clear targets and boundaries for subsequent differentiated code updates; analyzes existing front-end code to identify business logic nodes that need to be retained, avoiding disruption of core business functions by automated updates and ensuring the continuity and stability of interaction logic; generates a target update strategy based on the change intent type, scope of impact, and business logic nodes, enabling differentiated update strategies for different types of design draft changes; based on the target update strategy, converts the current version of the design draft into a design syntax tree, converts the existing front-end code into a code syntax tree, and represents business logic nodes as logic syntax trees; merges the design syntax tree, code syntax tree, and logic syntax tree to retain business logic nodes while applying design draft updates; generates updated front-end code based on the merged comprehensive syntax tree, retaining business logic during code updates, achieving precise incremental updates, avoiding the waste of computing resources caused by generating a full new version of code, and ensuring update efficiency.

[0102] The following is for reference. Figure 4 It shows a schematic diagram of the structure of a computer system 400 suitable for implementing an electronic device according to embodiments of the present invention. Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.

[0103] like Figure 4As shown, the computer system 400 includes a Central Processing Unit (CPU) 401, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 402 or programs loaded from storage section 408 into Random Access Memory (RAM) 403. The RAM 403 also stores various programs and data required for the operation of the computer system 400. The CPU 401, ROM 402, and RAM 403 are interconnected via a bus 404. An Input / Output (I / O) interface 405 is also connected to the bus 404.

[0104] The following components are connected to I / O interface 405: input section 406 including keyboard, mouse, etc.; output section 407 including cathode ray tube, liquid crystal display, etc., and speakers, etc.; storage section 408 including hard disk, etc.; and communication section 409 including network interface card, such as modem, etc. Communication section 409 performs communication processing via a network such as the Internet. Drive 410 is also connected to I / O interface 405 as needed. Removable media 411, such as disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 410 as needed so that computer programs read from them can be installed into storage section 408 as needed.

[0105] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 409, and / or installed from removable medium 411. When the computer program is executed by central processing unit (CPU) 401, it performs the functions defined above in the system of this invention.

[0106] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs the functions defined above in the system of this invention.

[0107] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, etc., or any suitable combination thereof.

[0108] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0109] The modules and / or units described in the embodiments of the present invention can be implemented in software or hardware. The described modules and / or units can also be housed in a processor; for example, a processor can be described as including an acquisition module, a first identification module, a second identification module, a generation module, and a merging module. The names of these modules do not necessarily limit the module itself.

[0110] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to include: In response to a design draft update message, the system retrieves structured difference data between the updated and current versions of the design draft. This structured difference data is analyzed to identify the type of change intent and its scope of impact. Existing front-end code is analyzed to identify business logic nodes that need to be retained; the existing front-end code corresponds to the current design draft. Based on the change intent type, scope of impact, and business logic nodes, a target update strategy is generated. Based on the target update strategy, the current version of the design draft is converted into a design syntax tree, the existing front-end code is converted into a code syntax tree, and business logic nodes are represented as logic syntax trees. The design syntax tree, code syntax tree, and logic syntax tree are merged to retain business logic nodes while applying the design draft update. Updated front-end code is generated based on the merged composite syntax tree; this updated front-end code corresponds to the updated version of the design draft.

[0111] The technical solution of this invention, in response to a design draft update message, acquires structured difference data between the updated and current versions of the design draft; analyzes the structured difference data to identify the type and scope of change intent, accurately mapping design-level change intent to the code level and providing clear targets and boundaries for subsequent differentiated code updates; analyzes existing front-end code to identify business logic nodes that need to be retained, avoiding disruption of core business functions by automated updates and ensuring the continuity and stability of interaction logic; generates a target update strategy based on the change intent type, scope of impact, and business logic nodes, enabling differentiated update strategies for different types of design draft changes; based on the target update strategy, converts the current version of the design draft into a design syntax tree, converts the existing front-end code into a code syntax tree, and represents business logic nodes as logic syntax trees; merges the design syntax tree, code syntax tree, and logic syntax tree to retain business logic nodes while applying design draft updates; generates updated front-end code based on the merged comprehensive syntax tree, retaining business logic during code updates, achieving precise incremental updates, avoiding the waste of computing resources caused by generating a full new version of code, and ensuring update efficiency.

[0112] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the design draft to code method provided in any embodiment of this invention.

[0113] In the implementation of a computer program product, computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​as well as conventional procedural programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0114] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0115] It should be noted that the collection, use, storage, sharing, and transfer of user personal information involved in the technical solution of this invention all comply with the provisions of relevant laws and regulations, and require notification to the user and obtaining the user's consent or authorization. Where applicable, user personal information has undergone de-identification and / or anonymization and / or encryption technical processing. In addition, a corresponding operation entry is provided for the user to choose to agree to or reject the automated decision result; if the user chooses to reject, the process proceeds to the expert decision-making process.

[0116] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for converting design drafts into code, characterized in that, include: In response to a design update message, retrieve the structured difference data between the updated design draft and the current design draft; The structured difference data is analyzed to identify the type of change intent and the scope of its impact; Analyze the existing front-end code to identify the business logic nodes that need to be retained; The existing front-end code is the front-end code corresponding to the current design draft; Based on the change intent type, the scope of impact, and the business logic node, a target update strategy is generated; Based on the target update strategy, the current version design draft is converted into a design syntax tree, the existing front-end code is converted into a code syntax tree, the business logic node is represented as a logic syntax tree, and the design syntax tree, code syntax tree and logic syntax tree are merged to retain the business logic node while updating the application design draft; The updated front-end code is generated based on the merged comprehensive syntax tree, and the updated front-end code is the front-end code corresponding to the updated version design draft.

2. The method according to claim 1, characterized in that, The step of responding to a design draft update message and obtaining structured difference data between the updated and current versions of the design draft includes: Subscribe to design drafts on the design platform so that the design platform sends a design draft update message when the design draft is updated, the design draft update message including the version number of the updated design draft; In response to a design draft update message, a difference data request message is sent to the design platform, so that the design platform calculates and sends the structured difference data based on the updated version of the design draft and the current version of the design draft; the difference data request message includes the version number of the updated version of the design draft and the version number of the current version of the design draft; The structured difference data is obtained from the design platform.

3. The method according to claim 1, characterized in that, The structured difference data is analyzed to identify change intent types, including: Multidimensional feature vectors are extracted based on the structured differential data; The multidimensional feature vector is input into the change recognition depth model to identify the change intent type.

4. The method according to claim 1, characterized in that, The scope of impact includes affected components and affected files. Analysis of the structured difference data is performed to identify the scope of impact, including: Based on the pre-defined mapping relationship between design elements and code components, as well as the dependency relationship between code components, the affected components are identified from the existing front-end code; The front-end code file to which the affected component belongs is identified as the affected code file.

5. The method according to claim 1, characterized in that, Analyze the existing front-end code to identify the business logic nodes that need to be retained, including: Convert the existing front-end code into a code syntax tree; The preset business logic pattern is matched with the code syntax tree, and the matched node is determined as the business logic node.

6. The method according to claim 4, characterized in that, Based on the change intent type, the scope of impact, and the business logic node, a target update strategy is generated, including: Determine the type of the affected component and the type of the affected file; The affected business logic nodes are determined from the business logic nodes based on the affected components; Determine the business logic region to which the affected business logic node belongs, and determine the type of the business logic region; The update strategy template is determined based on the change intent type, the type of the affected component, the type of the affected file, and the type of the business logic area; A target update strategy is generated based on the affected file, the business logic node, and the update strategy template.

7. The method according to claim 1, characterized in that, The business logic nodes are represented as logic syntax trees. The design syntax tree, code syntax tree, and logic syntax tree are merged to retain the business logic nodes while the application design draft is updated. This includes: The design syntax tree is compared with the code syntax tree, and the node to be updated is determined from the code syntax tree; The code syntax tree is compared with the logical syntax tree, and the nodes to be retained are determined from the code syntax tree; Determine whether there is a conflict between the node to be updated and the node to be retained; If it exists, then the node to be updated is re-determined based on the node to be retained, the node to be updated in the code syntax tree is updated, and the node to be retained in the code syntax tree is retained to obtain the comprehensive syntax tree; If it does not exist, then update the node to be updated in the code syntax tree, and retain the node to be retained in the code syntax tree to obtain the comprehensive syntax tree.

8. The method according to claim 7, characterized in that, Based on the nodes to be retained, the nodes to be updated are re-determined, including: Conflicting nodes are identified from the nodes to be updated based on the nodes to be retained; Determine the conflict type of the conflicting nodes; If the conflict type is a style conflict, the conflicting node is retained in the node to be updated; If the conflict type is a logical conflict, the conflicting node is deleted from the node to be updated.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method of converting design drafts to code as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method of converting design drafts into code as described in any one of claims 1 to 8.

Images