A front-end code generation method and electronic device

Abstract

The embodiment of the application provides a front-end code generation method and electronic equipment, and relates to the technical field of electronic information. The method comprises the following steps: obtaining multi-source description data of a front-end page; constructing a unified data model based on the multi-source description data; the unified data model comprises interface structure, style setting, interactive behavior and business logic constraint for describing the front-end page; the business logic constraint is used for limiting the interactive behavior response condition and the data check condition of the front-end page; the business logic constraint is split and reorganized to obtain a simplified logic description; and the front-end code of the front-end page is generated according to the unified data model and the simplified logic description. The embodiment of the application can be used in the field of low-code development, can realize the automatic generation of the front-end code of complex business logic and multi-end adaptation, effectively improves the development efficiency and guarantees the consistency and maintainability of the generated code.

Description

Technical Field

[0001] This application relates to the field of electronic information technology, and in particular to a front-end code generation method and an electronic device. Background Technology

[0002] In the field of low-code development, various code generation tools and platforms have become the core driving force for accelerating the development process. Developers do not need to delve into the underlying programming languages ​​or database structures. They can quickly build applications by dragging and dropping interface elements and configuring business logic. They are especially suitable for building simple web applications and enterprise internal management systems.

[0003] However, existing solutions have limitations in terms of automation depth and systematicity. When faced with complex business logic and multi-terminal adaptation, developers still need to invest a lot of resources in manual integration, logic writing and code refactoring, failing to truly achieve an end-to-end automated closed loop from design to runnable code. Summary of the Invention

[0004] The purpose of this application is to provide a front-end code generation method and electronic device, which aims to automate the generation of front-end code for complex business logic and multi-terminal adaptation, effectively improve development efficiency and ensure the consistency and maintainability of the generated code.

[0005] Firstly, this application provides a front-end code generation method, which includes: obtaining multi-source descriptive data of a front-end page; constructing a unified data model based on the multi-source descriptive data; wherein the unified data model includes elements describing the interface structure, style settings, interactive behaviors, and business logic constraints of the front-end page; the business logic constraints are used to limit the interactive behavior response conditions and data validation conditions of the front-end page; splitting and reorganizing the business logic constraints to obtain a simplified logical description; and generating the front-end code of the front-end page based on the unified data model and the simplified logical description.

[0006] The front-end code generation method provided in this application solves the problems of scattered information and inconsistent understanding in traditional development by acquiring multi-source descriptive data of the front-end page, providing a complete input source for subsequent automated processing. Based on this data, a unified data model is constructed, including interface structure, style, interactive behavior, and business logic constraints. This transforms the originally unstructured page description, implicit in the multi-source data, into a machine-readable, semantically clear standard intermediate representation. This process integrates and abstracts the complex information of the page, laying a precise data foundation for code generation. Subsequently, the business logic constraints in the unified data model are decomposed and reorganized to obtain a simplified logical description. This step decomposes complex and coupled business rules into atomic units that are easier to process and map to code logic, effectively reducing the complexity and error risk in the subsequent code generation stage regarding logical transformation. Ultimately, front-end code is generated based on a unified data model and simplified logical description, enabling the final code to directly inherit the complete page specifications defined by the model. Furthermore, since the generation process is based on a standardized and logically simplified intermediate representation, the output code is maintainable and logically consistent. This achieves automated and high-fidelity conversion from multi-source requirement descriptions to runnable code, improving the efficiency and quality of front-end development.

[0007] In conjunction with the first aspect mentioned above, in one possible implementation, the acquisition of multi-source descriptive data includes: acquiring first descriptive information from the design draft; the first descriptive information represents the visual presentation effect and layout information of the front-end page; acquiring second descriptive information from the visual arrangement file; the second descriptive information represents the component hierarchy, event binding information, and data association relationships of the front-end page; acquiring third descriptive information from the interface definition file; the third descriptive information represents the interface information and data structure to be called by the front-end page.

[0008] In conjunction with the first aspect mentioned above, in one possible implementation, a unified data model is constructed based on multi-source descriptive data, including: determining an initial set of interface elements based on the component types and display characteristics in the first descriptive information; matching and merging the component tree structure, event binding configuration, and data binding relationships in the second descriptive information with the initial set of interface elements to form an intermediate set of interface elements; associating the data structure description in the third descriptive information with the data binding relationships in the intermediate set of interface elements to determine the data model mapping relationship; and constructing a graph structure with interface elements as nodes and dependencies and event triggering relationships between nodes as edges, based on the intermediate set of interface elements and the data model mapping relationship, as the unified data model; wherein, dependencies are used to characterize the data transmission path between interface elements; and event triggering relationships are used to characterize the state changes of interface elements caused by interactive behaviors.

[0009] In conjunction with the first aspect mentioned above, in one possible implementation, obtaining the first descriptive information from the design draft includes: segmenting the design draft into elements to identify multiple components; identifying component types based on the region boundaries and shape features of the multiple components to determine the component type corresponding to each component; for each component, extracting the component's display features in the design draft; the display features include at least one of the following: component size, component position, component color, and font style within the component. Associating the component type with the display features forms the first descriptive information.

[0010] In conjunction with the first aspect mentioned above, in one possible implementation, obtaining the second descriptive information from the visual orchestration file includes: extracting the component tree structure from the visual orchestration file; the component tree structure includes the hierarchical relationship between multiple components; for each component, extracting its event binding configuration; identifying the data binding relationship defined in the visual orchestration file to determine the association relationship between different components and the data source; and forming the second descriptive information based on the component tree structure, the event binding configuration, and the data binding relationship.

[0011] In conjunction with the first aspect mentioned above, in one possible implementation, obtaining the third description information from the interface definition file includes: extracting the path information and request method of the target interface from the interface definition file; extracting the request object and response object corresponding to the target interface from the interface definition file to determine the data structure description of the target interface; and combining the path information, request method, and data structure description as the third description information.

[0012] In conjunction with the first aspect mentioned above, one possible implementation involves splitting and reorganizing business logic constraints to obtain a simplified logical description. This includes: splitting the business logic constraints into a set of Boolean expressions; each Boolean expression representing an interactive behavior response condition or data validation condition; performing equivalent transformations and merging on the Boolean expression set to obtain a set of logical expressions; and based on the set of logical expressions, determining a state machine model that describes the front-end page interaction logic as a simplified logical description.

[0013] In conjunction with the first aspect mentioned above, in one possible implementation, the equivalent transformation and merging of the Boolean expression set includes at least the following: identifying multiple expressions with the same semantics in the Boolean expression set and merging them into a representative expression; removing redundant expressions in the Boolean expression set that are completely covered by other expressions in terms of logical function; identifying contradictory expressions in the Boolean expression set and determining the target expression from the contradictory expressions according to a preset priority rule.

[0014] In conjunction with the first aspect mentioned above, in one possible implementation, front-end code capable of running in a specified runtime environment is generated based on a unified data model and a simplified logical description, including: generating a declarative application description text based on the unified data model and the simplified logical description; and compiling the declarative application description text into front-end code conforming to the target framework based on the target framework's syntax rules.

[0015] In conjunction with the first aspect mentioned above, in one possible implementation, the method further includes: visually running the front-end code in a simulation environment to determine feedback information; the feedback information includes at least the verification results of the interface rendering effect and the correctness of the interactive response; based on the feedback information, obtaining the user's correction operations on the front-end code to determine the correction information for the unified data model; and updating the unified data model based on the correction information to optimize the front-end code.

[0016] Secondly, this application provides a front-end code generation device, comprising: a data acquisition module, a model generation module, a logic simplification module, and a code generation module. The data acquisition module is used to acquire multi-source descriptive data of the front-end page; the model generation module is used to construct a unified data model based on the multi-source descriptive data; the unified data model includes elements describing the interface structure, style settings, interactive behaviors, and business logic constraints of the front-end page; the business logic constraints are used to limit the interactive behavior response conditions and data validation conditions of the front-end page; the logic simplification module is used to decompose and reorganize the business logic constraints to obtain a simplified logic description; and the code generation module is used to generate the front-end code of the front-end page based on the unified data model and the simplified logic description.

[0017] In conjunction with the second aspect mentioned above, in one possible implementation, the data acquisition module is specifically used for: obtaining first descriptive information from the design draft; the first descriptive information represents the visual presentation effect and layout information of the front-end page; obtaining second descriptive information from the visual arrangement file; the second descriptive information represents the component hierarchy, event binding information, and data association relationships of the front-end page; obtaining third descriptive information from the interface definition file; the third descriptive information represents the interface information and data structure to be called by the front-end page.

[0018] In conjunction with the second aspect above, in one possible implementation, the model generation module is specifically used for: determining an initial set of interface elements based on the component types and display characteristics in the first description information; matching and integrating the component tree structure, event binding configuration, and data binding relationships in the second description information with the initial set of interface elements to form an intermediate set of interface elements; associating the data structure description in the third description information with the data binding relationships in the intermediate set of interface elements to determine the data model mapping relationship; and constructing a graph structure with interface elements as nodes and dependencies and event triggering relationships between nodes as edges, based on the intermediate set of interface elements and the data model mapping relationship, as a unified data model; wherein, dependencies are used to characterize the data transmission path between interface elements; and event triggering relationships are used to characterize the state changes of interface elements caused by interactive behaviors.

[0019] In conjunction with the second aspect above, in one possible implementation, the logic simplification module is specifically used to: decompose business logic constraints into a set of Boolean expressions; each Boolean expression represents an interactive behavior response condition or data validation condition; perform equivalent transformations and merging on the set of Boolean expressions to obtain a set of logical expressions; and based on the set of logical expressions, determine a state machine model describing the front-end page interaction logic as a simplified logical description.

[0020] In conjunction with the second aspect mentioned above, in one possible implementation, the code generation module is specifically used to: generate declarative application description text based on a unified data model and simplified logical description; and compile the declarative application description text into front-end code that conforms to the target framework based on the target framework's syntax rules.

[0021] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory storing processor-executable instructions; when the processor is configured to execute the instructions, the electronic device implements the method of the first aspect described above.

[0022] Fourthly, this application provides a computer-readable storage medium comprising: computer software instructions; which, when executed in an electronic device, cause the electronic device to implement the method described in the first aspect.

[0023] Fifthly, this application provides a computer program product that, when run on a computer, causes the computer to perform the steps of the relevant method described in the first aspect above, so as to implement the method of the first aspect above.

[0024] The beneficial effects of the second to fifth aspects mentioned above can be referred to the corresponding description of the first aspect, and will not be repeated here. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 A flowchart illustrating a front-end code generation method provided in an embodiment of this application; Figure 2 A flowchart illustrating a method for obtaining multi-source descriptive data provided in an embodiment of this application; Figure 3 A flowchart illustrating a method for constructing a unified data model, provided in an embodiment of this application; Figure 4 A flowchart illustrating a simplified business logic constraint method provided in this application embodiment; Figure 5 A detailed flowchart illustrating a front-end code generation method provided in this application embodiment; Figure 6 This is a schematic diagram illustrating the composition of a front-end code generation device provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of a front-end code generation device provided in an embodiment of this application. Detailed Implementation

[0027] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] It should be noted that in the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0029] In the embodiments of this application, the terms "first," "second," "third," "fourth," "fifth," and "sixth" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," "third," "fourth," "fifth," and "sixth" may explicitly or implicitly include one or more of that feature.

[0030] In embodiments of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0031] "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.

[0032] As described in the background section, existing mainstream low-code front-end development solutions have limitations in terms of automation depth and systematicity, specifically as follows: Visual editing and domain-specific language (DSL) conversion can improve output stability, but the logic still needs to be manually arranged; deep learning-based design draft to code conversion can generate presentation layer code from design drafts, but accuracy and consistency are limited; automatic generation of front-end interface layer code based on interface definition files can reduce integration testing costs, but cannot cover interaction logic; automatic generation of logic code based on data and component dynamic attributes can lower the threshold for interaction implementation, but still requires a more systematic combination and optimization mechanism.

[0033] Based on this, this application provides a front-end code generation method. By acquiring multi-source descriptive data of the front-end page, it solves the problems of scattered information and inconsistent understanding in traditional development, providing a complete input source for subsequent automated processing. Then, based on this data, a unified data model is constructed, including interface structure, style, interactive behavior, and business logic constraints. This transforms the originally unstructured page description, implicit in the multi-source data, into a machine-readable, semantically clear standard intermediate representation. This process achieves the integration and abstraction of complex page information, laying a precise data foundation for code generation. Subsequently, the business logic constraints in the unified data model are decomposed and reorganized to obtain a simplified logical description. This step decomposes complex and coupled business rules into atomic units that are easier to process and map to code logic, effectively reducing the complexity and error risk in the subsequent code generation stage regarding logical transformation. Ultimately, front-end code is generated based on a unified data model and simplified logical description, enabling the final code to directly inherit the complete page specifications defined by the model. Furthermore, since the generation process is based on a standardized and logically simplified intermediate representation, the output code is maintainable and logically consistent. This achieves automated and high-fidelity conversion from multi-source requirement descriptions to runnable code, improving the efficiency and quality of front-end development.

[0034] The front-end code generation method provided in this application can be widely applied to various software development scenarios that require rapid generation of front-end code through visual design or configuration. This application does not impose any restrictions on the business domain, application complexity, or target operating environment of the specific application scenario.

[0035] For example, embodiments of this application can be applied to rapid development scenarios for complex enterprise-level management back-end systems (such as ERP and CRM). Faced with a large number of page requirements that include complex form validation, dynamic tables, and multi-step processes, the method provided in this application can directly generate front-end code with a clear structure, complete logic, and consistent style based on product documents and design drafts, greatly reducing the repetitive workload of developers manually writing and integrating business logic.

[0036] For example, the embodiments of this application can be applied to e-commerce operation activity page development scenarios that require high customization and frequent iteration. Faced with short-term and ever-changing marketing activities (such as promotional special pages and interactive game pages), the method provided by this application allows operations or design personnel to quickly generate front-end code adapted to different terminal devices by adjusting the description data, realizing rapid page launch and efficient iteration.

[0037] For example, the embodiments of this application can be applied to scenarios where cross-platform applications need to be developed (such as when both WeChat mini-program and web application versions need to be generated simultaneously). When the same business requirement needs to be implemented on multiple platforms, the method provided by this application can generate front-end code that conforms to different operating environment specifications based on the same set of multi-source description data, effectively ensuring the consistency of multi-platform application experience and business logic, and reducing the cost of multi-platform development.

[0038] The following describes in detail a front-end code generation method provided by the embodiments of this application, with reference to specific examples and accompanying drawings.

[0039] The front-end code generation method provided in this application embodiment can be implemented by a front-end code generation system deployed in a computing device. This system can be modularly designed, either deployed as an independent software module in the developer's host or server environment, or deeply integrated with existing low-code platforms, possessing full-process capabilities for data parsing, model building, logic transformation, and code generation.

[0040] Figure 1 This is a flowchart illustrating a front-end code generation method provided in an embodiment of this application. For example, as shown... Figure 1 As shown, it includes the following: S101. Obtain multi-source description data from the front-end page.

[0041] In this embodiment, multi-source descriptive data refers to a data set obtained from different sources that can comprehensively characterize the core information required for front-end page development. It covers key development dimensions such as front-end page interface presentation, component association, interaction configuration, and data interaction, and serves as the foundational input for subsequently building a unified data model and generating target code.

[0042] In some embodiments, multi-source description data may come from design draft files, visual layout files, and interface definition files.

[0043] In some embodiments, the front-end code generation system can obtain design draft files by connecting to the export interface of mainstream design tools, obtain visual arrangement files by the project export function of the visual arrangement platform, and obtain interface definition files by receiving OpenAPI or Swagger format files uploaded by developers.

[0044] In one possible implementation, the specific implementation of step S101 is described below. Figure 2 The corresponding implementation examples are described in detail here.

[0045] As can be seen from step S101, by integrating multiple sources of data such as design drafts, visual arrangement files, and interface definition files, the core input requirements of front-end development can be fully covered, avoiding the manual alignment costs caused by the dispersion of multiple sources of data in traditional development. At the same time, it provides complete and consistent basic data support for the subsequent construction of a unified data model, effectively reducing code generation errors caused by missing or inconsistent data.

[0046] S102. Construct a unified data model based on multi-source descriptive data.

[0047] The unified data model includes elements describing the interface structure, style settings, interactive behaviors, and business logic constraints of the front-end pages. Business logic constraints are used to define the response conditions for interactive behaviors and the data validation conditions of the front-end pages.

[0048] In this embodiment, the unified data model refers to a structured data set formed by integrating, matching, and associating descriptive data from different sources. This model can comprehensively and consistently represent the core features of the front-end page. Specifically, the interface structure describes the hierarchical relationship and layout of each component on the front-end page; style settings define the visual presentation attributes of each component; interactive behaviors depict the operations triggered by the components and the data flow logic; and business logic constraints are a set of rules that limit the conditions for interactive behaviors to take effect and the compliance of data.

[0049] In some embodiments, the unified data model may include: a set of components, a component tree structure, and hierarchical relationships between components to describe the front-end page interface structure; display characteristics of each component, such as size, position, color, and font style, to describe style settings; event binding configurations, data binding relationships, and state change rules after event triggering to describe interactive behaviors; and interactive behavior response conditions and data validation conditions to describe business logic constraints. These conditions may specifically be manifested as Boolean expressions that limit the timing of operation triggering, validation rules that limit data format or range, etc., and all content is interconnected to form a complete model system.

[0050] In some embodiments, the front-end code generation system can parse multi-source descriptive data to extract the component types and display features corresponding to the interface structure, the event binding configurations and data binding relationships corresponding to the interactive behaviors, and the verification rules and response conditions corresponding to the business logic constraints, thereby obtaining all the basic information required to build a unified data model.

[0051] In one possible implementation, the specific implementation of step S102 is described below. Figure 3 The corresponding implementation examples are described in detail here.

[0052] As shown in step S102, by constructing a unified data model, fragmented descriptive data scattered in design drafts, visualization layout files, and interface definition files can be integrated into a standardized and structured whole. This eliminates information barriers and inconsistencies between multiple data sources, enabling the interface structure, style settings, interactive behaviors, and business logic constraints of the front-end page to be uniformly represented. This provides a consistent and complete data foundation for the subsequent simplification of business logic constraints and the accurate generation of front-end code, effectively avoiding logical conflicts or information loss caused by data dispersion.

[0053] S103. Decompose and reorganize the business logic constraints to obtain a simplified logical description.

[0054] In this embodiment, business logic constraints refer to the set of rules in the unified data model used to limit the response conditions and data validation conditions of front-end page interactive behaviors, covering the preconditions for triggering interactive operations, the verification standards for data compliance, and the associated conditions for state changes. Simplified logical description refers to a non-redundant, low-complexity, and easily parsed logical expression form formed after processing business logic constraints through decomposition, equivalent transformation, and merging, which accurately retains the core logical rules and removes duplicate or conflicting content.

[0055] In some embodiments, business logic constraints may include: interactive behavior response conditions, such as the requirement for a complete form to be filled in for a button click to take effect, or the permission verification conditions to be met for a pop-up window to be displayed; and data validation conditions, such as format validation rules for data in input boxes, range restriction rules for numerical data, and non-empty validation rules for required fields. These constraints may exist in the unified data model in the form of scattered rule statements or implicit logical relationships.

[0056] In some embodiments, the simplified logical description may include: a set of Boolean expressions after merging and redundancy elimination, a state machine model that can clearly characterize the interaction and state transition relationship, and a simplified description that clarifies the triggering priority of each logical rule. These contents fully retain the core constraint logic while removing repeated, conflicting or redundant expressions.

[0057] In some embodiments, the front-end code generation system can parse the constructed unified data model and extract rule information related to interface interaction behavior and data validation from the model, including the preconditions for interaction response, the specific standards for data validation, and the dependencies of state changes, thereby obtaining the business logic constraints that need to be split and reorganized.

[0058] In one possible implementation, the specific implementation of step S103 is described below. Figure 4 The corresponding implementation examples are described in detail here.

[0059] As can be seen from step S103, by splitting and reorganizing business logic constraints, logical redundancy can be effectively eliminated, and the problems of logical fragmentation and conflict can be solved. Complex constraint rules are transformed into concise and clear simplified logical descriptions, which not only reduces the complexity of logical parsing in the subsequent code generation process, but also improves the readability and maintainability of the generated code. It avoids code execution abnormalities caused by logical redundancy or conflict, and provides a reliable logical foundation for efficiently generating accurate and compliant front-end code.

[0060] S104. Generate the front-end code for the front-end page based on the unified data model and simplified logical description.

[0061] In this embodiment, the front-end code is a code file that conforms to the syntax rules of a specified runtime environment and can be run directly or after compilation in the target environment, enabling the visual presentation and interactive functions of the front-end page. The runtime environment refers to the software environment in which the front-end code ultimately needs to be deployed and run, encompassing different front-end frameworks (such as React, Vue, Angular), runtime terminals (such as web browsers, mobile application containers), and system versions, etc.

[0062] In some embodiments, the front-end code may include: structural code related to page layout, style code related to component style, logic code related to interactive behavior, interface call code related to data request and processing, and auxiliary code such as engineering configuration files and dependency lists.

[0063] In some embodiments, the runtime environment may include: different types of front-end development frameworks, such as React, Vue, Angular, and Flutter; different runtime terminal environments, such as PC web browsers, mobile H5 browsers, iOS native application containers, and Android native application containers; and version specifications and adaptation requirements for each environment.

[0064] In some embodiments, the front-end code generation system can extract core information such as interface structure, style settings, and interactive behaviors by parsing the completed unified data model file, obtain simplified business logic rules by reading the simplified logic description file after splitting and reorganizing, and obtain information such as syntax rules and adaptation requirements corresponding to the specified runtime environment by receiving the target runtime environment parameters selected by the developers in the system interface or reading the preset environment configuration file, and then integrate all the basic information required to generate the front-end code.

[0065] In some embodiments, the front-end code generation system can also: visually load and run the generated front-end code in a simulated runtime environment, render the front-end page in real time and simulate various interactive operations, and collect feedback information such as whether the interface rendering effect meets design expectations and whether the interactive response matches the verification results of the simplified logic description. Based on this feedback information, the system receives user modifications to the front-end code, parses the corresponding logic adjustments, style modifications, and other requirements, and transforms them into correction information for the unified data model. The system updates the relevant fields and relationships of the unified data model according to the correction information, and then regenerates the front-end code based on the updated unified data model, thereby completing the iterative optimization of the front-end code.

[0066] In one possible implementation, the front-end code generation system can first generate a declarative application description text independent of a specific framework based on the interface structure, style settings, and business logic rules in the simplified logic description within a unified data model. This text fully describes all features and logic of the front-end page using standardized syntax. Then, it invokes the framework adapter corresponding to the specified runtime environment. This adapter has built-in syntax rules, component mapping relationships, and engineering configuration templates for the target framework. The adapter compiles the declarative application description text into front-end code that conforms to the syntax rules of the specified runtime environment. Simultaneously, it automatically integrates engineering capabilities such as API call layer, form validation, route management, access control, and internationalization adaptation, ultimately generating a complete front-end code package that can be directly deployed.

[0067] As shown in step S104, generating front-end code for the specified runtime environment based on a unified data model and simplified logical description ensures that the generated code fully covers the interface presentation and interaction logic requirements of the front-end page. The simplified logical description also reduces code complexity and conforms to the syntax rules and adaptation requirements of the target framework, minimizing compatibility issues in the target environment. Furthermore, the additional operations of simulation running and feedback optimization allow for timely detection and correction of deviations in the code, improving the accuracy and usability of the front-end code, significantly reducing the cost of manual code writing and debugging, and shortening the front-end development cycle.

[0068] In this embodiment of the application, in step S101 above, the front-end code generation system can obtain corresponding front-end description information based on the design draft, visual arrangement file, and interface definition file, respectively. For example, as shown... Figure 2 As shown, the above step S101 can be specifically implemented as S201-S203: S201. Obtain the first description information from the design draft.

[0069] The first descriptive information represents the visual presentation effect and layout information of the front-end page.

[0070] In this embodiment, the design draft refers to a visual file generated by a user interface (UI) design tool, used to intuitively present the overall visual effect and layout structure of the front-end page, and serves as the carrier of the visual and layout design intent of the front-end page. The first descriptive information is structured data extracted from the design draft, which can accurately characterize the visual presentation effect (such as component style, color matching, etc.) and layout information (such as component position, hierarchical relationship, etc.) of the front-end page, and is one of the core inputs for building a unified data model.

[0071] In some embodiments, the design draft may include: vector format files, bitmap format files, or interactive prototype files generated by UI design tools. These files cover the overall layout framework of the front-end page, the division of various functional modules, the visual representation of various interface components such as buttons, input boxes, text labels, and charts, as well as layout features such as the relative position, spacing, and alignment of components.

[0072] In some embodiments, the first description information may include: visual presentation-related feature data such as type identifiers, size parameters, color values, font styles and sizes, border styles, and shadow effects of various interface components, as well as layout-related feature data such as the coordinate position of the component on the page, the proportion of the component to the overall page, the spacing and alignment rules between components, and the hierarchical relationship of the components. This information is organized in a standardized key-value pair format to facilitate subsequent system parsing and processing.

[0073] In some embodiments, the front-end code generation system can directly read the original layer data of the design draft from the online project file of the UI design tool by connecting to the open interface of the UI design tool, or it can receive the design draft file (such as PSD, XD, PNG, SVG format) submitted by the user at the system upload portal, or it can obtain the design draft content by scanning the visual prototype screenshot of the front-end page, and then extract the corresponding first description information from these design drafts from different sources.

[0074] In some embodiments, the front-end code generation system can also: perform preprocessing operations on the acquired design draft, including normalizing the design draft image to unify the resolution, reducing noise to remove color interference, scaling or cropping to focus on the core page area, and filtering non-functional decorative elements (such as design annotations and auxiliary lines) in the design draft. Furthermore, it can perform integrity verification on the extracted first descriptive information; if key features such as component size or position are detected as missing, it automatically pushes supplementary prompts to the user to ensure the completeness and accuracy of the first descriptive information.

[0075] In one possible implementation, the front-end code generation system can first perform format parsing and image preprocessing on the received design files, removing irrelevant and interfering elements and unifying image resolution and color space. Then, using image processing / deep learning methods, the preprocessed design files are segmented into interface elements, identifying various components such as buttons, input boxes, and text areas on the page, and marking the pixel boundaries of these components. Next, feature extraction is performed on each identified component to obtain visual features such as component type, size, color, and font, as well as layout features such as the component's coordinates and screen percentage on the page. Finally, these extracted feature data are integrated according to a preset data structure to generate standardized first descriptive information and stored in the system's temporary data warehouse.

[0076] As can be seen from step S201, extracting the first descriptive information from the design draft can transform the unstructured visual and layout content of the design draft into structured data that the system can parse. This replaces the tedious process of manually organizing the design draft information, greatly reducing human error. At the same time, the preprocessing operation improves the accuracy of feature extraction, ensuring that the first descriptive information can truly restore the design intent of the design draft. This provides a reliable basis for the restoration of the interface structure and style settings in the subsequent unified data model construction, ensuring that the final generated front-end code is highly consistent with the design expectations in terms of visual and layout aspects.

[0077] S202. Obtain the second description information from the visual orchestration file.

[0078] The second descriptive information represents the component hierarchy, event binding information, and data association relationships of the front-end page.

[0079] In this embodiment, the visual orchestration file refers to a structured file generated by a low-code / no-code visual development platform, used to record the orchestration logic and interaction configuration of front-end page components. It serves as a digital carrier of the page design intent during the visual development process. The second descriptive information is structured data extracted from this type of file, which can accurately characterize the component hierarchy, event binding rules, and data association logic of the front-end page. It is one of the core inputs for building a unified data model.

[0080] In some embodiments, the visual orchestration files may include: structured files in JSON, XML, or custom formats generated by a low-code / no-code platform. These files contain core content such as unique identifiers for each UI component, associated fields between parent and child components, event triggering types and corresponding action configurations, data source binding rules, and dynamic adjustment logic for component properties. Some files may also contain auxiliary content such as orchestration version information and component library dependency lists.

[0081] In some embodiments, the second description information may include: nesting relationships between the root component and its child components at each level, the order and display priority of components in the hierarchical structure, event types such as button clicks, input box content changes, and page loading completion, as well as the triggering conditions and associated actions (such as route jumps, backend interface calls, local state modifications, and pop-up displays) corresponding to each event, binding rules between components and backend interface data sources, local cache data sources, and global state data sources, as well as data synchronization directions (one-way binding, two-way binding), data format conversion rules, etc. All information is organized in a standardized key-value pair and hierarchical structure to facilitate subsequent system parsing and integration.

[0082] In some embodiments, the front-end code generation system can directly read the saved visual orchestration files from the project management module of the visual orchestration platform by connecting to the platform's open interface, or receive visual orchestration files (JSON / XML format) submitted locally by users through the system's file upload entry, or parse the project compressed package exported by the visual orchestration tool to extract the core orchestration files, and then extract the corresponding second description information from these orchestration files from different sources.

[0083] In some embodiments, the front-end code generation system may also: perform semantic verification on the extracted second description information, check whether there is circular nesting in the component hierarchy, whether the event binding points to an undefined trigger action, and whether the data association points to an invalid data source; if an anomaly is detected, generate corresponding prompt information.

[0084] In one possible implementation, the front-end code generation system first parses the received visual orchestration file, identifying core modules such as component nodes, hierarchical relationship fields, event configuration nodes, and data binding nodes. Then, it extracts the unique identifier of each component and the parent / child component relationship information, constructing a component hierarchy tree structure with component identifiers as nodes. Next, it parses the event configuration nodes, extracting key information such as event type, triggering conditions, and associated actions to form a standardized event binding information set. Then, it parses the data binding nodes, extracting the mapping relationships between components and various data sources, data synchronization directions, format conversion rules, etc., forming a data relationship set. Finally, it integrates the component hierarchy tree structure, the event binding information set, and the data relationship set according to a preset structured template to generate complete second description information and stores it in the system's temporary data warehouse.

[0085] As can be seen from step S202, extracting the second description information from the visual orchestration file can transform the non-standardized interactive configuration logic in the visual orchestration process into structured data that the system can parse. This replaces the tedious process of manually sorting out the component hierarchy, event binding and data association rules in the orchestration file, reducing the probability of human misunderstanding or information omission.

[0086] S203. Obtain third-party description information from the interface definition file.

[0087] The third descriptive information represents the interface information and data structure that the front-end page needs to call.

[0088] In this embodiment, the interface definition file refers to a structured file written in accordance with standardized interface description specifications, used to define the interaction interface between the front-end page and the back-end service. It serves as a standardized carrier of interface functions and data interaction rules. The third description information is structured data extracted from this type of file, which can accurately characterize the interface access rules and data interaction structure required by the front-end page, and is one of the core inputs for building a unified data model.

[0089] In some embodiments, the interface definition file may include a JSON / YAML format file written in accordance with mainstream interface description specifications such as OpenAPI, RAML, and API Blueprint. These files cover core content such as basic meta-information of the interface, request configuration, response configuration, authentication rules, and error code definitions. Some files may also include auxiliary content such as interface version information, request frequency limits, and the service module to which the interface belongs.

[0090] In some embodiments, the third description information may include: a unique interface identifier, access path, request method, request header parameter configuration, URL path parameter and query parameter definition for representing interface information; field names, field types, field constraints (required / optional, length limit, etc.), and default values ​​for the request body object for representing data structure; the hierarchical structure of the response body object, the data type and definition of each field; and the interface authentication method, error code and corresponding description information, data return format, etc.

[0091] In some embodiments, the front-end code generation system can directly read published interface definition files from the interface documentation module of the interface management platform by connecting to the platform's open interface, or receive interface definition files submitted locally by users through the system's file upload entry, or parse the interface documentation compressed package uploaded by users to extract interface definition files that conform to standardized specifications, and then extract the corresponding third-party description information from these interface definition files from different sources.

[0092] In one possible implementation, the front-end code generation system can first parse the received interface definition file, identifying core modules such as basic interface information nodes, request configuration nodes, response configuration nodes, and authentication rule nodes. Then, it extracts interface information such as the access path, request method, and request header parameters for each interface, forming a standardized set of interface information. Next, it parses the field definitions of the request and response bodies, extracting field names, types, constraints, etc., to construct a hierarchical data structure model. Then, it parses the authentication rules and error code definitions, supplementing them into the corresponding interface information. Finally, it integrates the interface information set and the data structure model according to a preset structured template, generating complete third-party description information and storing it in the system's temporary data warehouse.

[0093] As can be seen from step S203, extracting third-party description information from the interface definition file can transform the abstract rules in the standardized interface document into structured data that the system can parse, replacing the tedious process of manually sorting out interface information and data structure, and reducing the probability of human omissions or misunderstandings.

[0094] In this embodiment of the application, in step S102 above, the front-end code generation system can construct a unified data model based on the front-end description information extracted from the design draft, visual arrangement file, and interface definition file. For example, as shown... Figure 3 As shown, step S102 above can be specifically implemented as S301-S304: S301. Determine the initial set of interface elements based on the component types and display characteristics in the first description information.

[0095] In this embodiment of the application, the initial set of interface elements is constructed based on the component types and display features in the first description information. It includes a set of basic interface elements and core visual attributes of the front-end page and is the initial construction basis of the unified data model.

[0096] In some embodiments, the initial set of interface elements may include: a unique identifier for each interface element, component type (such as button, input box, text area, etc.), size, position, color, font style and other display characteristics, as well as the basic attribute configuration corresponding to the element. All elements exist as independent entries and are associated with a unique identifier.

[0097] In some embodiments, the front-end code generation system can directly obtain the component types and display features required to build a unified data model by reading the first description information stored in the temporary data warehouse, or it can receive the first description information in real time through the output interface of the preceding steps to ensure the timeliness and completeness of data acquisition.

[0098] S302. Match and merge the component tree structure, event binding configuration and data binding relationship in the second description information with the initial interface element set to form an intermediate interface element set.

[0099] In this embodiment of the application, the intermediate interface element set is a set of elements that combines visual attributes and interactive logic, formed by merging the component tree structure, event binding configuration and data binding relationship in the second description information with the initial interface element set.

[0100] In some embodiments, the intermediate interface element set may include: all visual attribute information in the initial interface element set, the hierarchical nesting relationship corresponding to the overlay component tree structure, the event type and associated action corresponding to the event binding configuration, the data source type and binding rules corresponding to the data binding relationship, and each element entry is associated with newly added interaction-related information through a unique identifier.

[0101] In some embodiments, the front-end code generation system can directly obtain the component tree structure, event binding configuration, and data binding relationship required to build a unified data model by reading the second description information stored in the temporary data warehouse, or it can receive the second description information in real time through the output interface of the preceding steps to ensure the timeliness and completeness of data acquisition.

[0102] S303. Associate the data structure description in the third description information with the data binding relationship in the intermediate interface element set to determine the data model mapping relationship.

[0103] In this embodiment of the application, the data model mapping relationship is the corresponding association established between the data structure in the third description information and the data binding relationship in the intermediate interface element set, which clarifies the adaptation rules between interface elements and backend data.

[0104] In some embodiments, the data model mapping relationship may include: name mapping between data binding fields in the intermediate interface element set and request / response body fields in the third description information, data type adaptation rules (such as conversion rules between front-end string types and back-end integer types), field constraint association (such as the correspondence between required fields in front-end input boxes and required field constraints in back-end fields), etc.

[0105] In some embodiments, the front-end code generation system can directly obtain the data structure description required to build a unified data model by reading the third description information stored in the temporary data warehouse, or it can receive the third description information in real time through the output interface of the preceding steps to ensure the timeliness and completeness of data acquisition.

[0106] S304. Based on the mapping relationship between the intermediate interface element set and the data model, construct a graph structure with interface elements as nodes and the dependencies and event triggering relationships between nodes as edges, as a unified data model.

[0107] Among them, dependency relationships are used to characterize the data transmission path between interface elements, and event triggering relationships are used to characterize the state changes of interface elements caused by interactive behaviors.

[0108] In this embodiment, dependency relationships are association rules that characterize the path of data transmission between different interface elements, clarifying the flow logic of data from the data source to the target element. Event triggering relationships are association rules that characterize the state changes of interface elements caused by interactive behaviors, clarifying the correspondence between events and element state changes.

[0109] In some embodiments, dependencies may include: the data propagation path from interface response fields to UI display elements, the data propagation path from parent components to child components, and the data sharing path between sibling components.

[0110] In some embodiments, event triggering relationships may include: a button click event triggering a change in the disabled state of an input field, a form submission event triggering a change in the displayed state of a pop-up window, and a data loading completion event triggering a change in the rendered state of a list component.

[0111] In one possible implementation, steps S301-S304 are implemented as follows: The front-end code generation system first parses the first description information, extracts the component type and display features such as size, position, and color, assigns a unique identifier to each component, and integrates this information into an initial set of interface elements containing multiple independent interface elements. Next, it traverses the component tree structure in the second description information, matches and merges the hierarchical relationship with the corresponding elements in the initial set of interface elements using the component's unique identifier, and then associates the event binding configuration and data binding relationship with the corresponding interface elements, supplementing the element's interactive attributes to form an intermediate set of interface elements. Then, it extracts the data structure description from the third description information, compares each data binding field in the intermediate set of interface elements, establishes the correspondence between field names, data types, and constraints, and determines the data model mapping relationship. Finally, each interface element in the intermediate interface element set is used as a node. The data transmission path between nodes is sorted out according to the data model mapping relationship and dependency edges are constructed. The logic of element state change caused by interaction behavior is sorted out according to the event binding configuration and event triggering edges are constructed. The resulting graph structure can be used as intermediate representation (IR), that is, unified data model, and stored in the system's model repository.

[0112] As shown in steps S301-S304, by integrating multi-source descriptive information to construct a unified data model, fragmented data scattered across design drafts, visualization layout files, and interface definition files can be transformed into a structured and logically clear whole, effectively eliminating information barriers and inconsistencies between multi-source data. The graph structure design, with interface elements as nodes and dependencies and event triggering relationships as edges, clearly represents the interface features, interaction logic, and data flow rules of the front-end page, providing a consistent and complete data foundation for simplifying subsequent business logic constraints and accurately generating front-end code.

[0113] In this embodiment, the front-end code generation system can obtain simplified logical descriptions by splitting and reorganizing business logic constraints to generate declarative application description text. For example, Figure 4 As shown, it includes S401-S403: S401. Decompose business logic constraints into a set of Boolean expressions.

[0114] Each Boolean expression represents an interactive behavior response condition or a data validation condition.

[0115] In this embodiment, the Boolean expression set is a collection of multiple independent Boolean expressions formed by decomposing business logic constraints. Each Boolean expression combines condition factors through logical operators (AND / OR / NOT) to accurately represent the response condition or data validation condition of a single interactive behavior.

[0116] In some embodiments, the set of Boolean expressions may include: Boolean expressions representing the conditions for a button click to take effect (such as "the input box content is not empty and the verification code has been verified"), Boolean expressions representing the conditions for form submission validation (such as "the mobile phone number is in the correct format and the password length is ≥8 characters or the passwordless login flag is true"), and Boolean expressions representing the conditions for a pop-up window to display a response (such as "the user's permission level is ≥3 and the unread announcement flag is true"). Each expression consists of conditional factors (such as field values ​​and status flags) and logical operators, and independently corresponds to a specific interaction or validation rule.

[0117] In some embodiments, the front-end code generation system can extract all interactive behavior response conditions and data validation conditions from the business logic constraint module of the model by parsing the unified data model that has been built and stored in the model repository. Alternatively, it can read the structured business logic constraint information stored in the unified data model in real time through the system's logic rule parsing interface, thereby obtaining the original business logic constraints for decomposition and providing basic data for subsequent decomposition into a set of Boolean expressions.

[0118] S402. Perform equivalent transformations and merging on the set of Boolean expressions to obtain the set of logical expressions.

[0119] In the embodiments of this application, equivalent transformation and merging are logical simplification operations performed on a set of Boolean expressions, aiming to eliminate redundancy, resolve conflicts, and simplify the logical expression form. The set of logical expressions is a set of Boolean expressions without redundancy or conflicts obtained after equivalent transformation and merging, retaining the core logical rules and possessing simplicity.

[0120] In some embodiments, the set of logical expressions may include: a representative Boolean expression after merging (replacing multiple original expressions with the same semantics), a core Boolean expression retained after removing redundancy (without functional coverage issues), and a target Boolean expression after priority filtering (to resolve contradiction issues). All expressions maintain logical integrity and can fully cover the core rules of the original business logic constraints.

[0121] In some embodiments, when performing equivalent transformations and merging on a set of Boolean expressions, the front-end code generation system can use a semantic parsing algorithm to identify multiple Boolean expressions with the same semantics in the set and merge them into a representative expression that can cover the core logic. Logic coverage analysis removes redundant expressions in the set that are functionally completely covered by other expressions, reducing invalid logic rules. A conflict detection algorithm identifies contradictory expressions in the set and, based on preset priority rules (such as "data validation conditions have higher priority than interactive response conditions" and "the latest configured rule has higher priority than historical rules"), determines the final target expression to be retained from the contradictory expressions. Furthermore, syntax validation can be performed on the set of logical expressions after equivalent transformation and merging to ensure that all expressions use the correct logical operators and that conditional factors are valid, preventing logical errors in subsequent state machine model construction.

[0122] S403. Based on the set of logical expressions, determine the state machine model that describes the interaction logic of the front-end page, as a simplified logical description.

[0123] In this embodiment, the state machine model is a finite state machine built upon a set of logical expressions to describe the interaction logic of the front-end page. It includes an initial state, trigger states, state transition conditions, and a final state, and can intuitively depict the correspondence between interactive behaviors and state changes. The simplified logical description is a concise logical expression form that can be parsed by the system, centered on the state machine model. It is the final presentation form of business logic constraints after decomposition and simplification.

[0124] In some embodiments, the state machine model may include: the initial state of the front-end page (such as the form not filled in), various trigger states (such as the input box content change state, the button click state), state transition conditions (i.e., Boolean expressions in the logical expression set), the final state (such as the form submission successful state, the submission failure state), and the corresponding UI element behaviors during the state transition process (such as button disable / enable, pop-up show / hide), forming a closed-loop state transition logic that clearly represents the UI state changes caused by interactive behaviors.

[0125] In one possible implementation, steps S401-S403 are implemented as follows: The front-end code generation system first reads the business logic constraints in the unified data model. Using a rule decomposition algorithm, each complete constraint rule is broken down into independent Boolean expressions composed of condition factors and logical operators. All the decomposed expressions are then integrated to form a set of Boolean expressions. Next, this set undergoes equivalent transformation and merging. Expressions with the same semantics are first identified and merged. Redundant expressions with overlapping functions are removed. Contradictory expressions are then detected and processed to determine the target expression, resulting in a simplified set of logical expressions. Subsequently, based on each Boolean expression in the logical expression set, state nodes of the front-end page (such as initial state, triggered state, and completed state) are defined, and transition conditions (i.e., Boolean expressions) and subsequent behaviors (changes in interface element states) between state nodes are established, constructing a finite state machine model that can fully describe the interaction logic. Finally, this state machine model is stored in a preset structured format as a simplified logical description for subsequent code generation steps.

[0126] As shown in steps S401-S403, by decomposing business logic constraints into a set of Boolean expressions, performing equivalent transformations and merging, and constructing a state machine model, a simplified logical description is obtained. This transforms potentially redundant and conflicting complex business logic constraints into a concise, non-redundant, and conflict-free standardized logical expression, effectively solving the problems of fragmented and heavily coupled business logic. The decomposition and simplification of Boolean expressions removes repetitive or invalid logical rules, reducing the complexity of logic parsing during subsequent code generation. The construction of the state machine model depicts the flow of interaction logic, enabling the system to accurately understand and transform the interaction rules of the front-end page.

[0127] In summary, Figure 5 This is a detailed flowchart illustrating a front-end code generation method provided in an embodiment of this application. For example, as shown... Figure 5As shown, the front-end code generation method takes multi-source data as input, which includes three types of data: design drafts, visual arrangement files, and interface definition documents. The method aggregates this multi-source data into a unified intermediate representation, and then sequentially performs type inference and consistency verification, dependency analysis and constraint collection, logic minimization, and state machine generation. Based on the results of the above processing, a declarative application description text is generated, followed by the generation of target platform code. The generated target platform code then undergoes code quality acceptance. If the acceptance fails, manual corrections are made, and the correction information is fed back to the unified intermediate representation for re-execution of subsequent processing steps. If the acceptance passes, the artifact is directly output.

[0128] The front-end code generation method provided in this application solves the problems of scattered information and inconsistent understanding in traditional development by acquiring multi-source descriptive data of the front-end page, providing a complete input source for subsequent automated processing. Then, based on this data, a unified data model is constructed, including interface structure, style, interactive behavior, and business logic constraints. This transforms the originally unstructured page description, implicit in the multi-source data, into a machine-readable, semantically clear standard intermediate representation. This process achieves the integration and abstraction of complex page information, laying a precise data foundation for code generation. Subsequently, the business logic constraints in the unified data model are decomposed and reorganized to obtain a simplified logical description. This step decomposes complex and coupled business rules into atomic units that are easier to process and map to code logic, effectively reducing the complexity and error risk in the subsequent code generation stage regarding logical transformation. Ultimately, front-end code is generated based on a unified data model and simplified logical description, enabling the final code to directly inherit the complete page specifications defined by the model. Furthermore, since the generation process is based on a standardized and logically simplified intermediate representation, the output code is maintainable and logically consistent. This achieves automated and high-fidelity conversion from multi-source requirement descriptions to runnable code, improving the efficiency and quality of front-end development.

[0129] In an exemplary embodiment, Figure 6 This is a schematic diagram illustrating the composition of a front-end code generation device provided in an embodiment of this application. Figure 6As shown, the front-end code generation device includes: a data acquisition module 601, a model generation module 602, a logic simplification module 603, and a code generation module 604. The data acquisition module 601 is used to acquire multi-source descriptive data of the front-end page. The model generation module 602 is used to construct a unified data model based on the multi-source descriptive data. The unified data model includes elements describing the interface structure, style settings, interactive behaviors, and business logic constraints of the front-end page. Business logic constraints are used to limit the interactive behavior response conditions and data validation conditions of the front-end page. The logic simplification module 603 is used to decompose and reorganize the business logic constraints to obtain a simplified logic description. The code generation module 604 is used to generate the front-end code of the front-end page based on the unified data model and the simplified logic description.

[0130] In this embodiment of the application, the data acquisition module 601 is specifically used for: obtaining first description information from the design draft; the first description information represents the visual presentation effect and layout information of the front-end page; obtaining second description information from the visual arrangement file; the second description information represents the component hierarchy, event binding information and data association relationship of the front-end page; obtaining third description information from the interface definition file; the third description information represents the interface information and data structure to be called by the front-end page.

[0131] In this embodiment, the model generation module 602 is specifically used for: determining an initial set of interface elements based on the component types and display characteristics in the first description information; matching and merging the component tree structure, event binding configuration, and data binding relationships in the second description information with the initial set of interface elements to form an intermediate set of interface elements; associating the data structure description in the third description information with the data binding relationships in the intermediate set of interface elements to determine a data model mapping relationship; and constructing a graph structure with interface elements as nodes and dependencies and event triggering relationships between nodes as edges, based on the intermediate set of interface elements and the data model mapping relationship, as a unified data model; wherein, dependencies are used to characterize the data transmission path between interface elements; and event triggering relationships are used to characterize the state changes of interface elements caused by interactive behaviors.

[0132] In this embodiment, the logic simplification module 603 is specifically used to: split the business logic constraints into a set of Boolean expressions; each Boolean expression represents an interactive behavior response condition or data validation condition; perform equivalent transformation and merging on the Boolean expression set to obtain a set of logical expressions; and based on the set of logical expressions, determine a state machine model describing the front-end page interaction logic as a simplified logic description.

[0133] In this embodiment of the application, the code generation module 604 is specifically used to: generate declarative application description text based on a unified data model and a simplified logical description; and compile the declarative application description text into front-end code that conforms to the target framework based on the syntax rules of the target framework.

[0134] In an exemplary embodiment, this application also provides an electronic device, which may be the front-end code generation device in the above method embodiments. Figure 7 This is a schematic diagram of a front-end code generation device provided in an embodiment of this application. Figure 7 As shown, the front-end code generation apparatus may include: a processor 701 and a memory 702; the memory 702 stores instructions executable by the processor 701; when the processor 701 is configured to execute instructions, it causes an electronic device, network device, or manager to implement the system functions described in the foregoing method embodiments.

[0135] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual 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.

[0136] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0137] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0138] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0139] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0140] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A front-end code generation method, characterized in that, The method includes: Retrieve multi-source description data from the front-end page; Based on the multi-source description data, a unified data model is constructed; the unified data model includes the interface structure, style settings, interactive behaviors, and business logic constraints of the front-end page; the business logic constraints are used to limit the interactive behavior response conditions and data validation conditions of the front-end page. The business logic constraints are broken down and reorganized to obtain a simplified logical description; Based on the unified data model and the simplified logical description, the front-end code of the front-end page is generated.

2. The method according to claim 1, characterized in that, The acquisition of multi-source description data of the front-end page includes: Obtain first descriptive information from the design draft; the first descriptive information characterizes the visual presentation effect and layout information of the front-end page; Obtain the second description information from the visual orchestration file; the second description information represents the component hierarchy, event binding information, and data association relationships of the front-end page; Obtain third description information from the interface definition file; the third description information represents the interface information and data structure to be called by the front-end page.

3. The method according to claim 2, characterized in that, The construction of a unified data model based on the multi-source description data includes: Based on the component types and display characteristics in the first description information, determine the initial set of interface elements; The component tree structure, event binding configuration, and data binding relationship in the second description information are matched and merged with the initial interface element set to form an intermediate interface element set; Associate the data structure description in the third description information with the data binding relationship in the intermediate interface element set to determine the data model mapping relationship; Based on the mapping relationship between the intermediate interface element set and the data model, a graph structure is constructed with interface elements as nodes and dependencies and event triggering relationships between nodes as edges, serving as a unified data model; wherein, the dependencies are used to characterize the data transmission path between interface elements; and the event triggering relationships are used to characterize the state changes of interface elements caused by interactive behaviors.

4. The method according to claim 2, characterized in that, The step of obtaining the first descriptive information from the design draft includes: The design draft is segmented into elements to determine multiple components; Based on the region boundaries and shape features of the multiple components, component type identification is performed to determine the component type corresponding to each component; For each component, extract the display features of the component in the design draft; the display features include at least one of the following: component size, component position, component color, and font style in the component; Associating the component type with the display feature forms the first description information.

5. The method according to claim 2, characterized in that, The step of obtaining the second description information from the visual orchestration file includes: Extract the component tree structure from the visual orchestration file; the component tree structure includes the hierarchical relationship between multiple components; For each component, extract its event binding configuration; Identify the data binding relationships defined in the visualization orchestration file to determine the association between different components and the data source; The second description information is formed based on the component tree structure, event binding configuration, and data binding relationship.

6. The method according to claim 2, characterized in that, The step of obtaining the third description information from the interface definition file includes: Extract the path information and request method of the target interface from the interface definition file; Extract the request object and response object corresponding to the target interface from the interface definition file, and determine the data structure description of the target interface; The path information, the request method, and the data structure description are combined to form the third description information.

7. The method according to claim 1, characterized in that, The process of splitting and reorganizing the business logic constraints to obtain a simplified logical description includes: The business logic constraints are broken down into a set of Boolean expressions; each Boolean expression represents an interactive behavior response condition or a data validation condition. The Boolean expression set is transformed and merged to obtain the logical expression set; Based on the set of logical expressions, a state machine model is determined to describe the interaction logic of the front-end page, serving as a simplified logical description.

8. The method according to claim 7, characterized in that, The equivalent transformation and merging of the Boolean expression set includes at least one of the following: Identify multiple expressions with the same semantics in the set of Boolean expressions and merge them into a representative expression; Remove redundant expressions from the set of Boolean expressions that are logically completely covered by other expressions; Identify contradictory expressions in the set of Boolean expressions, and determine the target expression from the contradictory expressions according to a preset priority rule.

9. The method according to any one of claims 1-8, characterized in that, The step of generating the front-end code for the front-end page based on the unified data model and the simplified logical description includes: Based on the unified data model and the simplified logical description, a declarative application description text is generated. Based on the target framework's syntax rules, the declarative application description text is compiled into front-end code that conforms to the target framework.

10. The method according to claim 9, characterized in that, The method further includes: The front-end code is run visually in a simulation environment to determine the feedback information; the feedback information includes at least the verification results of the interface rendering effect and the correctness of the interaction response. Based on the feedback information, obtain the user's correction operation on the front-end code, and determine the correction information for the unified data model; The unified data model is updated based on the correction information to optimize the front-end code.

11. An electronic device, characterized in that, The electronic device includes: a processor and a memory; The memory stores instructions that the processor can execute; When the processor is configured to execute the instructions, it causes the electronic device to implement the method as described in any one of claims 1-10.

Images