Front-end application construction method and device based on virtual node tree, equipment and medium

Abstract

Embodiments of the present disclosure disclose a virtual node tree-based front-end application construction method, device, equipment and medium. A specific implementation of the method includes: performing node semantic analysis processing on an obtained target view description file to obtain view semantic information; performing hierarchical structure fusion processing on the view semantic information to obtain a virtual node tree; performing node-by-node classification construction processing on the virtual node tree to obtain a component structure file set; performing staged attribute injection processing on the component structure file set to obtain a front-end application file set; performing deviation directional correction processing on the front-end application file set to obtain a target front-end application file set; obtaining a front-end application resource package and deploying the front-end application resource package on a target server; and rendering and presenting a front-end interface corresponding to the target view description file on a display interface of a terminal device. The implementation can reduce the rendering resource consumption when the terminal device presents the front-end interface.

Description

Technical Field

[0001] The embodiments of this disclosure relate to the field of computer technology, and more specifically to a method, apparatus, device, and medium for building front-end applications based on virtual node trees. Background Technology

[0002] A front-end application is an application that runs on a terminal device and interacts with the user interface (e.g., a web application running in a browser). A virtual node tree is tree-like data organized according to the relationships between the component nodes in a view description file, and can be used as the basis for generating front-end application files. The typical method for building a front-end application is as follows: First, the obtained view description file is parsed to obtain the structured data of each node. Then, a design-to-code (D2C) tool is used to generate the front-end application files based on the structured data. Finally, the front-end application files are compiled to obtain a front-end application resource package, which is then deployed to a server for terminal devices to access and display the front-end interface.

[0003] However, in practice, it has been found that when using the above method to build front-end applications, the following technical problem often occurs: When constructing a front-end application for terminal devices from a view description file with a complex structure (e.g., a view description file with deep node nesting levels and a variety of style values) (e.g., a front-end application for online preview on mobile terminals), if the code conversion tool is designed to generate the front-end application file node by node according to the node hierarchy in the view description file, then nodes in the view description file that are only used to determine the hierarchical relationship between multiple child nodes and are not used to present interface content will also form corresponding page elements when the front-end application runs, increasing the number of nodes and nesting levels in the runtime page structure, resulting in increased rendering resource consumption when the terminal device presents the front-end interface.

[0004] The information disclosed in this background section is only intended to enhance the understanding of the background of the present disclosure concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0006] Some embodiments of this disclosure propose a method, apparatus, device, and medium for building front-end applications based on virtual node trees to solve one or more of the technical problems mentioned in the background section above.

[0007] In a first aspect, some embodiments of this disclosure provide a front-end application construction method based on a virtual node tree, comprising: in response to receiving a front-end application construction request sent by a terminal device, obtaining a target view description file corresponding to the front-end application construction request; performing node semantic parsing processing on the target view description file to obtain view semantic information; performing hierarchical structure fusion processing on the view semantic information to obtain a virtual node tree; performing node-by-node classification construction processing on the virtual node tree according to the component semantic information and layout semantic information included in the view semantic information to obtain a component structure file set; performing phased attribute injection processing on the component structure file set according to the view semantic information to obtain a front-end application file set; performing deviation orientation correction processing on the front-end application file set according to the virtual node tree to obtain a target front-end application file set; performing engineering compilation processing on the target front-end application file set to obtain a front-end application resource package, and deploying the front-end application resource package on a target server; and in response to the target server receiving an access request sent by the terminal device, rendering and presenting a front-end interface corresponding to the target view description file on the display interface of the terminal device.

[0008] Secondly, some embodiments of this disclosure provide a front-end application building apparatus based on a virtual node tree, comprising: an acquisition unit configured to acquire a target view description file corresponding to the front-end application building request in response to receiving a front-end application building request sent by a terminal device; a semantic parsing unit configured to perform node semantic parsing processing on the target view description file to obtain view semantic information; a fusion unit configured to perform hierarchical structure fusion processing on the view semantic information to obtain a virtual node tree; and a building unit configured to perform node-by-node classification building processing on the virtual node tree according to the component semantic information and layout semantic information included in the view semantic information to obtain a component structure file set; The attribute injection unit is configured to perform phased attribute injection processing on the component structure file set according to the aforementioned view semantic information to obtain a front-end application file set; the correction unit is configured to perform deviation-oriented correction processing on the aforementioned front-end application file set according to the aforementioned virtual node tree to obtain a target front-end application file set; the compilation unit is configured to perform engineering compilation processing on the aforementioned target front-end application file set to obtain a front-end application resource package, and deploy the aforementioned front-end application resource package on the target server; the rendering unit is configured to respond to the aforementioned target server receiving an access request sent by the aforementioned terminal device, and render and present the front-end interface corresponding to the aforementioned target view description file on the display interface of the aforementioned terminal device.

[0009] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, such that when the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any implementation of the first aspect.

[0010] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the method as described in any implementation of the first aspect.

[0011] The above embodiments of this disclosure have the following beneficial effects: The front-end application construction method based on virtual node trees in some embodiments of this disclosure can reduce the rendering resource consumption when a terminal device presents a front-end interface. Specifically, the reason for the increased rendering resource consumption when a terminal device presents a front-end interface is that when constructing a complex view description file into a front-end application for the terminal device, if a code-to-code tool is designed to generate the front-end application file node by node according to the node hierarchy in the view description file, then nodes in the view description file that are only used to determine the hierarchical relationship between multiple child nodes and are not used to present interface content will also form corresponding page elements when the front-end application runs, increasing the number of nodes and nesting levels in the runtime page structure, resulting in increased rendering resource consumption when the terminal device presents a front-end interface. Based on this, the front-end application construction method based on virtual node trees in some embodiments of this disclosure can first, in response to receiving a front-end application construction request sent by the terminal device, obtain the target view description file corresponding to the front-end application construction request. Here, the target view description file provides the data foundation for subsequent node semantic parsing processing. Then, node semantic parsing processing is performed on the target view description file to obtain view semantic information. Here, the target view description file is parsed into view semantic information describing each node and the relationships between nodes, providing component semantic information, layout semantic information, and style markup information for subsequent hierarchical structure fusion processing and node-by-node classification and construction processing. Next, hierarchical structure fusion processing is performed on the view semantic information to obtain a virtual node tree. Here, the semantic, layout, style, and interaction information scattered in the view semantic information is merged into a unified tree structure, providing a comparison benchmark for the node hierarchy structure for subsequent node-by-node classification and construction processing and deviation-oriented correction processing. Then, based on the component semantic information and layout semantic information included in the view semantic information, node-by-node classification and construction processing is performed on the virtual node tree to obtain a component structure file set. Here, each node in the virtual node tree is distinguished by the structural representation it uses in the generated component structure file, ensuring that nodes that are not used to present interface content but only to determine the hierarchical relationship of child nodes do not form corresponding host page elements, reducing the number of host page elements and nesting levels in the page structure formed by the component structure file during terminal device rendering. Subsequently, based on the view semantic information, phased attribute injection processing is performed on the component structure file set to obtain the front-end application file set. Here, style references and interactive events are injected into the component structure file set in stages, providing a front-end application file set with style references and interactive events for subsequent deviation-oriented correction processing. Then, based on the virtual node tree, deviation-oriented correction processing is performed on the front-end application file set to obtain the target front-end application file set.Here, the node hierarchy of the front-end application file set is corrected using a virtual node tree as a comparison benchmark. This reduces redundant nesting levels and unnecessary host page elements that are inconsistent with the view description file in the target front-end application file set, further reducing the number of host page elements and nesting levels in the page structure formed during terminal device rendering. Next, the target front-end application file set is compiled to obtain a front-end application resource package, which is then deployed to the target server. Here, the target front-end application file set, after node hierarchy correction, is compiled into a front-end application resource package that can be loaded and run by the terminal device, reducing the number of host page elements and nesting levels in the page structure corresponding to the front-end application resource package deployed on the target server. Finally, in response to the target server receiving an access request from the terminal device, the front-end interface corresponding to the target view description file is rendered on the terminal device's display interface. Here, the reduction in the number of host page elements and nesting levels reduces the number of page elements that the terminal device needs to create and maintain when rendering the front-end interface, thus reducing the rendering resource consumption when the terminal device presents the front-end interface. Therefore, this front-end application construction method based on a virtual node tree can reduce the rendering resource consumption when the terminal device presents the front-end interface. Attached Figure Description

[0012] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0013] Figure 1 This is a flowchart of some embodiments of the front-end application construction method based on the virtual node tree disclosed herein; Figure 2 This is a schematic diagram of the structure of some embodiments of the front-end application building apparatus based on the virtual node tree according to the present disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0014] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0015] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0016] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0017] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0018] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0019] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0020] Figure 1 A flow 100 is shown illustrating some embodiments of a front-end application building method based on a virtual node tree according to this disclosure. This front-end application building method based on a virtual node tree includes the following steps: Step 101: In response to receiving a front-end application build request from a terminal device, obtain the target view description file corresponding to the front-end application build request.

[0021] In some embodiments, the execution entity (e.g., an electronic device) of the aforementioned front-end application construction method based on a virtual node tree can, in response to receiving a front-end application construction request sent by a terminal device, obtain the target view description file corresponding to the front-end application construction request. The terminal device can be an electronic device with a display screen and supporting front-end interface rendering. For example, the terminal device can include, but is not limited to, at least one of the following: smartphone, tablet computer, desktop computer, laptop computer. The front-end application construction request can be a network request sent by the terminal device. The front-end application construction request includes a design file identifier, which can be a unique number assigned to a design file by a design tool. The front-end application corresponding to the front-end application construction request can include a single-page application (SPA) or a multiple-page application (MPA) of one or more front-end interfaces (e.g., homepage, detail page, settings page, login page). The target view description file can be a structured data file generated by the design tool for the design file corresponding to the design file identifier, describing the interface element composition, hierarchical relationship between elements, element layout, element style, and interaction behavior between elements of the target front-end interface. For example, the design tool mentioned above could be Figma, the design file identifier could be a file key assigned by Figma to the design file, and the target view description file could be a JSON file returned by Figma. In practice, the execution entity can read the design file identifier included in the front-end application build request, call the interface provided by the design tool, and obtain the target view description file corresponding to the design file identifier.

[0022] Step 102: Perform node semantic parsing on the target view description file to obtain view semantic information.

[0023] In some embodiments, the execution entity may perform node semantic parsing processing on the target view description file to obtain view semantic information. The view semantic information may be structured data describing the nodes included in the target view description file and the relationships between them. The view semantic information may include component semantic information, layout semantic information, and style tag information. A node may be a data unit describing an interface element in the target view description file. For example, the interface element may include, but is not limited to, at least one of the following: button, input box, drop-down menu, card, list item, pop-up, and navigation bar. The component semantic information may be structured data describing the content role, component reference relationships, and interaction event information of each node. The layout semantic information may be structured data describing the arrangement of each node and its child nodes. The style tag information may be structured data describing the style values ​​used in the target view description file and the reference relationships between each node and the style values.

[0024] In some optional implementations of certain embodiments, the above-mentioned node semantic parsing processing of the target view description file to obtain view semantic information may include the following steps: The first step involves performing structured parsing on the target view description file to obtain the corresponding node hierarchy data, component association data, layout parameter data, and style attribute data. The node hierarchy data can be structured data describing the parent-child relationships between the nodes included in the target view description file. For example, if a card node contains a button node and a text node, then the card node is the parent node, and the button node and text node are the child nodes of the card node. The component association data can be structured data describing the component reference relationships and interaction event information of each node. The component reference relationship can be the association between a node and its component reference source. For example, if both the "Submit" and "Cancel" button nodes in a login interface reference the same button component, then the component reference relationship of each of these two nodes records that their reference source is the same button component. The interaction event information can be the interface behavior information triggered when a node is operated. For example, clicking a button node may redirect to another target front-end interface. The layout parameter data can be structured data describing the arrangement of each node. For example, a group of nodes may be arranged sequentially from top to bottom within its parent node. The aforementioned style attribute data can be structured data describing the visual appearance of each node. For example, a button component might have a background color of "#1890FF" and rounded corners of 8 pixels. In practice, the executing entity can use a parser (e.g., a JSON parser) corresponding to the file format of the target view description file to parse the target view description file. The parsed parent-child containment relationships between nodes, component reference relationships and interaction event information, node arrangement, and visual appearance of each node are respectively determined as node hierarchy data, component association data, layout parameter data, and style attribute data.

[0025] The second step involves semantic association recognition processing of the aforementioned node-level data and component-related data to obtain component semantic information. This component semantic information may include semantic type labels for each node, a list of parent-child node identifiers, component reference relationships, and interaction event information. The semantic type labels may be functional category labels for the nodes (e.g., buttons, input boxes, cards, icons, text). The parent-child node identifier list may be a list composed of the node's parent node identifier and a set of child node identifiers. The parent node identifier may be the identifier of the parent node to which the node directly depends. The child node identifiers in the set of child node identifiers may be the identifiers of the child nodes directly contained in the node. The interaction event information may include the node's triggering method (e.g., click, hover), action type (e.g., jump, state switch, show, hide), and the target node identifier on which the action is applied. In practice, the executing entity may first match the names and types of each component included in the aforementioned node-level data with a preset component type mapping table to obtain the semantic type labels for each component. The aforementioned component type mapping table can be a key-value table with component names and types as keys and semantic type tags as values. For example, the key "Button" in the above component type mapping table corresponds to the value "Button", and the key "Input" corresponds to the value "Input Box". Then, the parent-child containment relationships between the components included in the above node hierarchy data are determined as a list of parent-child node identifiers for each component. Finally, the semantic type tags of each component, the list of parent-child node identifiers, and the component reference relationships and interaction event information of each component included in the above component association data are determined as component semantic information.

[0026] The third step involves semantic mapping of the layout parameter data to obtain layout semantic information. This layout semantic information can include the layout direction, alignment, distribution, padding, child element spacing, and size pattern of each node. The layout direction can be the arrangement direction of a group of nodes within its parent node (e.g., horizontal or vertical arrangement). The alignment can be the alignment position of the nodes within the arrangement direction (e.g., start alignment, center alignment, end alignment). The size pattern can be the method of determining the width and height of the nodes (e.g., fixed size, content-adaptive, filling the parent node). In practice, the executing entity can match the layout parameters of each node included in the layout parameter data with a preset layout semantic mapping table to obtain the layout semantic description of each node. The layout semantic description of each node, along with the values ​​of its numerical layout parameters (e.g., padding, child element spacing), is then used to determine the layout semantic information. The layout semantic mapping table can be a mapping table with layout parameters as keys and layout semantic descriptions as values. For example, in the layout semantic mapping table above, the key "HORIZONTAL" corresponds to the value "horizontal arrangement" and the key "FILL" corresponds to the value "fill the parent node".

[0027] The fourth step involves processing the style attribute data into style variable tags to obtain style tag information. This style tag information can include a set of style tag variables and a set of node reference relationships. A style tag variable can be a style value expressed as a variable, which can be referenced by multiple nodes included in the target view description file. A node reference relationship can be a correspondence between a node and the style tag variable it references. For example, the background color of a button node might reference a style tag variable identified as "primary color". In practice, the executing entity can first deduplicate the style attribute values ​​of each node included in the style attribute data, identifying each deduplicated style value as a style tag variable and assigning a variable identifier to it, thus obtaining a set of style tag variables. Then, for each node included in the style attribute data, the variable identifiers of the style tag variables corresponding to the values ​​of each style attribute of that node are determined as the node reference relationship for that node. Finally, the set of style tag variables and the set of node reference relationships constituted by the node reference relationships of each node are defined as the style tag information.

[0028] The fifth step is to determine the above component semantic information, the above layout semantic information, and the above style markup information as view semantic information.

[0029] In addressing the technical problems mentioned above by adopting technical solutions, considering the application scenario where the same visual intent in the view description file corresponds to multiple style values ​​with similar but different values ​​(e.g., due to collaborative design by multiple people or merging of multiple design drafts, the same theme color corresponds to multiple similar color values, and the same spacing specification corresponds to multiple similar spacing values), the following technical problem often arises: Since the style values ​​corresponding to the same visual intent in the view description file exist in the form of multiple approximately discrete values, if each style value is generated as is, the generated front-end application file will contain a large number of style declarations with similar but different values. This increases the size of the front-end application resource package and the number of style rules that need to be matched when the terminal device displays the front-end interface, leading to increased rendering resource consumption when the terminal device displays the front-end interface. Considering the following requirements for this application scenario: multi-style differentiation and quantization, adaptive quantization benchmark, and traceable node style references, we decided to adopt the following solution: Optionally, the above-mentioned node semantic parsing processing of the target view description file to obtain view semantic information may include the following steps: The first step is to generate style attribute data, component semantic information, and layout semantic information based on the target view description file mentioned above. As an example, the implementation of this step can refer to the implementation methods of steps one through three in some optional implementation methods of step 102, which will not be repeated here.

[0030] The second step involves classifying and extracting the style attribute data to obtain a color attribute set, a spacing attribute set, a rounded corner attribute set, and a font parameter set. The color attributes in the color attribute set can be the color values ​​of nodes (e.g., background color, text color, stroke color). The spacing attributes in the spacing attribute set can be the spacing values ​​of nodes (e.g., padding, child element spacing). The rounded corner attributes in the rounded corner attribute set can be the rounded corner radius values ​​of nodes. The font parameters in the font parameter set can be the font values ​​of nodes (e.g., font size, font weight, line height). In practice, the executing entity can match the attribute name of each style attribute in the style attribute data with a preset attribute classification table to determine the attribute category to which the style attribute belongs, and then assign the style attribute to the attribute set corresponding to its category, thus obtaining the color attribute set, spacing attribute set, rounded corner attribute set, and font parameter set. The preset attribute classification table can be a mapping table with the attribute name of the style attribute as the key and the attribute category as the value. For example, in the preset attribute category table above, the value corresponding to the key "backgroundColor" is the color category, and the value corresponding to the key "paddingLeft" is the spacing category.

[0031] The third step involves performing a color space conversion on the aforementioned color attribute set to obtain a color coordinate set. The color coordinates in this set can be the coordinate values ​​of a color attribute in the CIELAB color space. In practice, the executing entity can, for each color attribute in the set, convert its color value into its coordinate value in the CIELAB color space using the conversion formula, thus obtaining the corresponding color coordinates. These color coordinates constitute the color coordinate set.

[0032] The fourth step involves performing color difference aggregation on the aforementioned color coordinate set to obtain an initial color marker set. The initial color markers in this set can be markers formed by merging a group of color coordinates with a color difference less than a preset color difference threshold, with the center coordinate of that group representing the color. The color difference can be the distance between two color coordinates in the CIELAB color space. The preset color difference threshold can be a critical value used to determine whether two color coordinates have been merged into the same initial color marker. For example, the preset color difference threshold could be 2.0. In practice, the execution entity can perform the following color difference aggregation steps: First, each color coordinate in the aforementioned color coordinate set is determined as a color group, resulting in a color group set. Then, for each color group in the aforementioned color grouping set, the color difference between the center coordinates of any two color groups is calculated. The two color groups with the smallest color difference that is less than the aforementioned preset color difference threshold are merged into one color group, and the mean coordinate of each color coordinate within the merged color group is determined as the center coordinate of the merged color group. This merging process is repeated until the color difference between the center coordinates of any two color groups in the aforementioned color grouping set is not less than the aforementioned preset color difference threshold. Finally, for each color group in the aforementioned color grouping set, the center coordinate of the color group is determined as a representative color, and the representative color is determined as an initial color mark. The resulting initial color marks constitute an initial color mark set.

[0033] The fifth step involves performing contrast adaptation processing on the initial color tag set based on the aforementioned style attribute data, resulting in a color tag set. Here, each color tag in the color tag set can be a color value representing a group of approximate colors with a color difference less than the aforementioned preset color difference threshold, used for node reference. In practice, the executing entity can first, for each node in the aforementioned style attribute data that simultaneously possesses a foreground color and a background color, determine the initial color tag to which the node's foreground color is merged and the initial color tag to which the node's background color is merged as a color tag pair. Then, for each color tag pair, according to the relative brightness formula of WCAG (Web Content Accessibility Guidelines), calculate the relative brightness of the two initial color tags of the color tag pair. Divide the sum of the larger of the two relative brightness values ​​and a preset constant by the quotient of the smaller value and the aforementioned preset constant to determine the contrast of the color tag pair. Color tag pairs with a contrast less than the preset contrast threshold are determined as color tag pairs to be adapted. The aforementioned contrast can be the ratio of the relative brightness of two colors. The aforementioned preset constant can be a constant used in the aforementioned relative brightness formula to avoid division by zero. For example, the preset constant can be 0.05. The preset contrast threshold can be a critical value for determining whether the contrast of a color marker pair meets the standard. For example, the preset contrast threshold can be 4.5. Then, for each color marker pair to be adapted, along the lightness component of the CIELAB color space, the lightness component of the foreground initial color marker in the color marker pair is gradually adjusted according to a preset lightness step size until the contrast of the color marker pair is not less than the preset contrast threshold, thus obtaining the adapted color marker corresponding to the foreground initial color marker. Wherein, when the relative brightness of the foreground initial color marker is less than the relative brightness of the background initial color marker, the lightness component is adjusted in a decreasing direction; when the relative brightness of the foreground initial color marker is not less than the relative brightness of the background initial color marker, the lightness component is adjusted in an increasing direction. The preset lightness step size can be the magnitude of each adjustment of the lightness component. For example, the preset lightness step size can be 1. Finally, the adapted color markers obtained from the above adjustments in each color marker pair to be adapted, and the initial color markers in the above initial color marker set that have not been adjusted, are determined as a color marker set.

[0034] Step 6: Perform adaptive step size recognition processing on the aforementioned spacing attribute set and rounded corner attribute set to obtain the target spacing step size value and the target rounded corner step size value. The target spacing step size value can be a reference value that approximates an integer multiple of each spacing value in the aforementioned spacing attribute set. The target rounded corner step size value can be a reference value that approximates an integer multiple of each rounded corner value in the aforementioned rounded corner attribute set. In practice, the executing entity can first, for each candidate step size value in the preset candidate step size value set, calculate the absolute value of the difference between each spacing value in the aforementioned spacing attribute set and the nearest integer multiple of that candidate step size value. Then, sum the absolute values ​​of the differences corresponding to each spacing value to obtain the total spacing deviation corresponding to that candidate step size value. The candidate step size value with the smallest total spacing deviation is determined as the target spacing step size value. Then, for each candidate step size value in the aforementioned candidate step size value set, the absolute value of the difference between each rounded corner value in the aforementioned rounded corner attribute set and the nearest integer multiple of the candidate step size value is calculated. The absolute values ​​of the differences corresponding to each rounded corner value are added together to obtain the total rounded corner deviation corresponding to the candidate step size value. The candidate step size value with the smallest total rounded corner deviation is determined as the target rounded corner step size value. The aforementioned preset candidate step size value set can be a pre-defined set of values ​​for selecting step size values ​​(for example, a set including 2 pixels, 4 pixels, and 8 pixels).

[0035] Step 7: Based on the target spacing step size and the target rounded corner step size, perform step size quantization mapping on the spacing attribute set and the rounded corner attribute set respectively to obtain a spacing marker set and a rounded corner marker set. The spacing markers in the spacing marker set can be spacing values ​​that are integer multiples of the target spacing step size, used for node reference. The rounded corner markers in the rounded corner marker set can be rounded corner values ​​that are integer multiples of the target rounded corner step size, used for node reference. In practice, the execution entity can first, for each spacing value in the spacing attribute set, divide the spacing value by the target spacing step size, round the quotient to an integer, and multiply the integer by the target spacing step size to determine the spacing marker corresponding to that spacing value. The resulting spacing markers constitute the spacing marker set. Then, for each rounded corner value in the above rounded corner attribute set, the quotient of the rounded corner value divided by the above target rounded corner step value is rounded to an integer, and the product of the integer and the above target rounded corner step value is determined as the rounded corner mark corresponding to the rounded corner value. The resulting rounded corner marks constitute a rounded corner mark set.

[0036] Step 8: Perform fuzzy matching on the above font parameter set to obtain a font tag set. The font tags in this set can be representative font sizes used by nodes to represent a group of merged font parameters. In practice, the executing entity can first group font parameters whose font size differences are within a preset range, resulting in several font parameter groups. Then, for each font parameter group, the average font size of each font parameter in that group is rounded to an integer to determine the representative font size of that group. Finally, the representative font size of each font parameter group is assigned as a font tag, and the resulting font tags constitute a font tag set. The preset font size difference range can be a critical range (e.g., 1 pixel) for determining whether two font parameters are merged into the same font tag.

[0037] Step nine involves performing node reference association processing on the style attribute data based on the aforementioned color mark set, spacing mark set, rounded corner mark set, and font mark set to obtain style mark information. This style mark information may include a set of style mark variables and a set of node reference relationships. The style mark variables in the style mark variable set can be style values ​​expressed as variables that can be referenced by multiple nodes included in the target view description file. The node reference relationships in the node reference relationship set can be the correspondence between a node's style attribute and the variable identifier of the style mark variable referenced by that style attribute. For example, the background color attribute of a button node references a style mark variable identified as "primary color." In practice, the executing entity can first determine each mark in the aforementioned color mark set, spacing mark set, rounded corner mark set, and font mark set as a style mark variable, and assign a variable identifier to each style mark variable to obtain a set of style mark variables. Then, for each node included in the above style attribute data, the following steps are performed for each style attribute of that node: First, match the attribute name of the style attribute with the above-preset attribute classification table to determine the attribute category to which the style attribute belongs, and determine the tag set corresponding to the attribute category as the target tag set for the style attribute; wherein, the color category corresponds to the above color tag set, the spacing category corresponds to the above spacing tag set, the rounded corner category corresponds to the above rounded corner tag set, and the font category corresponds to the above font tag set. Second, for the style attribute of the color category, determine the color tag with the smallest color difference between the coordinates of the color value of the style attribute in the CIELAB color space and each color tag in the above target tag set as the style tag variable referenced by the style attribute; for the style attributes of the spacing category, rounded corner category, and font category, determine the tag with the smallest absolute value of the difference between the value of the style attribute and each tag in the above target tag set as the style tag variable referenced by the style attribute. Third, determine the correspondence between the style attribute and the variable identifier of the referenced style tag variable as the node reference relationship of the style attribute of that node. Finally, the set of style markup variables and the set of node reference relationships consisting of the node reference relationships of each style attribute of each node are determined as style markup information.

[0038] Step 10: Determine the above component semantic information, the above layout semantic information, and the above style markup information as view semantic information.

[0039] The above-described technical solution and its related content, as an inventive point of this disclosure, combined with steps "107" and "108" below, solve the second technical problem: "increased size of front-end application resource package and increased rendering resource consumption when the terminal device presents the front-end interface." Factors leading to increased size of the front-end application resource package and increased rendering resource consumption of the terminal device are often as follows: Since the style values ​​corresponding to the same visual intent in the view description file exist in the form of multiple approximately discrete values, if each style value is generated as is, the generated front-end application file will contain a large number of style declarations with similar but different values. This increases the size of the front-end application resource package on the one hand, and increases the number of style rules that need to be matched when the terminal device presents the front-end interface on the other hand, leading to increased rendering resource consumption when the terminal device presents the front-end interface. Solving these factors can reduce the size of the front-end application resource package and the rendering resource consumption when the terminal device presents the front-end interface. To achieve this effect, this disclosure first generates style attribute data, component semantic information, and layout semantic information based on the target view description file. Secondly, the style attribute data is processed by attribute classification and extraction to obtain a color attribute set, a spacing attribute set, a rounded corner attribute set, and a font parameter set. Here, style attribute data is broken down into four attribute sets based on their visual meaning: color, spacing, rounded corners, and font. This provides a classification basis for subsequent quantification of each attribute. Next, the color attribute set undergoes color space transformation to obtain a color coordinate set. Then, color difference aggregation is performed on the color coordinate set to obtain an initial color tag set. Subsequently, based on the style attribute data, contrast adaptation processing is applied to the initial color tag set to obtain a color tag set. Here, multiple color values ​​with similar values ​​in the color attribute set are aggregated into a common color tag, preventing the generation of distinct style declarations for each similar color value and reducing the number of similar but distinct color style declarations in the front-end application file. Then, adaptive step size recognition processing is performed on the spacing and rounded corner attribute sets to obtain target spacing step size values ​​and target rounded corner step size values. Next, step size quantization mapping processing is performed on the spacing and rounded corner attribute sets respectively based on the target spacing and rounded corner step size values ​​to obtain the spacing tag set and rounded corner tag set. Finally, fuzzy matching processing is performed on the font parameter set to obtain the font tag set. Here, based on the adaptively identified step size, the spacing and rounded corner values ​​are quantized into integer multiples of the step size. Multiple font parameters with similar font sizes are grouped into a common font tag. This prevents multiple spacing, rounded corner, and font parameters with similar values ​​from generating distinct style declarations individually, reducing the number of similar but distinct spacing, rounded corner, and font style declarations in the front-end application file. Then, based on the color tag set, spacing tag set, rounded corner tag set, and font tag set, node reference association processing is performed on the style attribute data to obtain style tag information.Finally, the component semantic information, layout semantic information, and style tag information are determined as view semantic information. Here, the style attributes of each node are associated with a style tag variable that is a common approximation of numerical values. This allows each node to express a similar style value by referencing the same style tag variable, reducing the number of style values ​​that need to be declared in the front-end application file. This reduces the size of the front-end application resource package and the number of style rules that need to be matched when the terminal device renders the front-end interface, thereby reducing the rendering resource consumption when the terminal device renders the front-end interface. Therefore, the above technical solution and its related content, combined with steps "107" and "108" below, can reduce the size of the front-end application resource package and the rendering resource consumption when the terminal device renders the front-end interface.

[0040] Step 103: Perform hierarchical structure fusion processing on the view semantic information to obtain a virtual node tree.

[0041] In some embodiments, the execution entity may perform hierarchical structure fusion processing on the view semantic information to obtain a virtual node tree. The virtual node tree may be a tree structure data where each node in the target view description file is a tree node, the parent-child containment relationships between nodes are edges, and each tree node is associated with the description information of its corresponding node. The description information may describe the semantics, layout, style, and interaction attributes of the nodes. Each tree node in the virtual node tree corresponds to a node in the target view description file. For example, the root node of the virtual node tree corresponds to a login card node, and this root node connects to two child nodes, which respectively correspond to an input box node and a submit button node.

[0042] In some optional implementations of certain embodiments, the hierarchical fusion processing of the aforementioned view semantic information to obtain a virtual node tree includes: The first step is to construct a node hierarchy tree based on the component semantic information included in the aforementioned view semantic information. This node hierarchy tree can be a tree structure where each node in the target view description file is a tree node, the parent-child containment relationships between nodes are edges, and each tree node is associated with the semantic type label and component reference relationship of its corresponding node. For example, the tree node corresponding to the submit button node in the aforementioned node hierarchy tree is associated with the semantic type label "button" of that submit button node. In practice, the executing entity can use a tree structure construction tool (e.g., Python's anytree library) to create a tree node for each node included in the aforementioned component semantic information, write the semantic type label and component reference relationship of that node into the node attributes of that tree node, and set the tree node corresponding to the parent node identifier included in the parent-child node identifier list of that node as the parent node of that tree node, thus obtaining the node hierarchy tree.

[0043] The second step involves performing parameter mapping on the node hierarchy tree based on the layout semantic information included in the view semantic information, resulting in a layout node tree. This layout node tree can be a tree structure data where each tree node is associated with its layout parameters, building upon the node hierarchy tree. For example, the tree node corresponding to the submit button node in the layout node tree, in addition to being associated with the semantic type label "button," is also associated with the layout parameter "center aligned" for that submit button node. In practice, the executing entity can write the layout parameters of the corresponding node, included in the layout semantic information, into the node attributes of each tree node in the node hierarchy tree to obtain the layout node tree.

[0044] The third step involves performing reference association processing on the layout node tree based on the style tag information included in the view semantic information, thereby obtaining a style node tree. This style node tree can be a tree structure data based on the layout node tree, where each tree node is also associated with the variable identifier of the style tag variable referenced by that node. For example, the tree node corresponding to the submit button node in the style node tree, in addition to being associated with the semantic type label "button" and the layout parameter "center alignment," is also associated with the variable identifier "primary color" of the style tag variable referenced by the submit button node. In practice, the executing entity can, for each tree node in the layout node tree, write the variable identifier of the style tag variable referenced by the corresponding node in the node reference relationship set included in the style tag information into the node attribute of that tree node to obtain the style node tree.

[0045] Fourth, based on the interaction event information included in the semantic information of the aforementioned components, the style node tree is subjected to event binding processing to obtain the aforementioned virtual node tree. In practice, the aforementioned execution entity can write the interaction event information of the corresponding node, which is included in the semantic information of the aforementioned components, into the node attributes of the aforementioned tree node for each tree node in the style node tree to obtain the virtual node tree.

[0046] Step 104: Based on the component semantic information and layout semantic information included in the view semantic information, perform node-by-node classification and construction processing on the virtual node tree to obtain the component structure file set.

[0047] In some embodiments, the execution entity can perform node-by-node classification and construction processing on the virtual node tree based on the component semantic information and layout semantic information included in the view semantic information, to obtain a component structure file set. The component structure files in the component structure file set can be source code files describing the component structure corresponding to a node, without describing the component's style and interaction. The component structure can include component declarations, attribute interfaces, and sub-component reference relationships. The component declaration can be the definition of the component's name and its boundaries. The attribute interface can be the parameter definition for the component to receive input data (e.g., a button component receiving button text and whether it is disabled). The sub-component reference relationships can be references between a component and its contained sub-components (e.g., a card component referencing a button component and a text component).

[0048] In some optional implementations of certain embodiments, the process of classifying and constructing the virtual node tree node by node based on the component semantic information and layout semantic information included in the view semantic information to obtain a component structure file set may include the following steps: The first step involves performing a hierarchical traversal and sorting process on the virtual node tree to obtain the sequence of nodes to be constructed, as well as the set of already constructed files and deviation constraint information. The sequence of nodes to be constructed can be a sequence of nodes in the virtual node tree arranged in ascending order of depth. The set of already constructed files can be a collection of component structure files corresponding to each node that has generated its corresponding component structure file; in this step, the set of already constructed files is empty. The deviation constraint information can be deviation information used to constrain the regeneration of component structure files for the current node to be constructed; in this step, the deviation constraint information is empty. In practice, the execution entity can first use BFS (Breadth First Search) to traverse each node level by level from the root node of the virtual node tree, arranging the traversed nodes in ascending order of depth to obtain the sequence of nodes to be constructed.

[0049] The second step involves performing the following construction steps based on the above-mentioned sequence of nodes to be constructed, the above-mentioned component semantic information, the above-mentioned layout semantic information, the above-mentioned constructed file set, and the above-mentioned deviation constraint information: Sub-step 1: Determine the first node to be constructed in the above sequence of nodes to be constructed as the current node to be constructed, and determine the above sequence of nodes to be constructed after removing the current node to be constructed as the remaining node sequence.

[0050] Sub-step 2 involves determining the node construction type identifier of the currently to-be-built node based on the aforementioned virtual node tree, and extracting the target node semantic record from the aforementioned component semantic information and layout semantic information. The node construction type identifier can be an identifier representing the structural representation of the node in the generated component structure file. The node construction type identifier can include page element construction type identifiers and pass-through construction type identifiers. The component structure corresponding to the page element construction type identifier forms a host page element corresponding to that node during terminal device rendering; the component structure corresponding to the pass-through construction type identifier does not form a host page element corresponding to that node during terminal device rendering. The host page element can be a page element (e.g., an element in the browser's Document Object Model (DOM) tree) created by the browser during front-end rendering that carries the interface content or structure. The target node semantic record can be the semantic type tag, component reference relationship, and layout parameters of the component corresponding to the currently to-be-built node. In practice, the executing entity can first read the description information associated with the currently to-be-built node in the aforementioned virtual node tree to determine whether the currently to-be-built node meets the preset page element construction conditions. The aforementioned page element construction conditions can be conditions used to determine whether a node needs to form a corresponding host page element during rendering, and may include, but are not limited to, at least one of the following: the node itself carries text, image, or graphic content; the node itself carries fill, stroke, shadow, or rounded corner visual styles; the node provides layout constraints (e.g., arrangement direction, padding, child element spacing) for its child nodes; and the node is associated with interactive event information. In response to determining that the currently constructed node satisfies at least one of the aforementioned page element construction conditions, the page element construction type identifier is determined as the node construction type identifier of the currently constructed node; in response to determining that the currently constructed node does not satisfy any of the aforementioned page element construction conditions and the currently constructed node has child nodes in the aforementioned virtual node tree, the pass-through construction type identifier is determined as the node construction type identifier of the currently constructed node; in response to determining that the currently constructed node does not satisfy any of the aforementioned page element construction conditions and the currently constructed node does not have child nodes in the aforementioned virtual node tree, the page element construction type identifier is determined as the node construction type identifier of the currently constructed node. Then, the semantic type label and component reference relationship of the component corresponding to the current node to be built in the above component semantic information, and the layout parameters of the component corresponding to the current node to be built in the above layout semantic information are determined as the target node semantic record.

[0051] Sub-step 3: Based on the node construction type identifier, perform context-adaptive extraction processing on the constructed file set to obtain cascading context information. The cascading context information can be the component structure files corresponding to nodes in the constructed file set that are associated with the currently to-be-built node. In practice, the execution entity can, in response to determining that the currently to-be-built node is the root node of the virtual node tree, determine the empty set as cascading context information; in response to determining that the node construction type identifier is a page element construction type identifier, determine the component structure files corresponding to the parent node of the currently to-be-built node in the constructed file set as cascading context information; in response to determining that the node construction type identifier is a pass-through construction type identifier, determine the component structure files corresponding to the parent node of the currently to-be-built node in the constructed file set, and the component structure files corresponding to each child node of the parent node in the constructed file set as cascading context information. Child nodes of the parent node whose corresponding component structure files have not yet been generated are not included in the cascading context information.

[0052] Sub-step 4: Based on the aforementioned cascading context information, node construction type identifier, target node semantic record, and deviation constraint information, generate the initial component structure file corresponding to the currently constructed node. This initial component structure file can be a source code file describing the component declaration, attribute interfaces, and sub-component reference relationships of the component corresponding to the currently constructed node. In practice, the executing entity can input the aforementioned cascading context information, node construction type identifier, target node semantic record, deviation constraint information, and preset generation constraint information into the structure file generation model to obtain the initial component structure file corresponding to the currently constructed node. The preset generation constraint information can be pre-defined information used to constrain the generation scope and output format of the structure file generation model. For example, the preset generation constraint information can include, but is not limited to, at least one of the following: target front-end framework identifier, target programming language identifier, component naming rules, and an identifier indicating whether the generation of corresponding host page elements is allowed. The structure file generation model can be a model accessed through a preset calling method that performs constrained code generation processing on the input target node semantic record and outputs a source code file. The aforementioned preset invocation methods may include, but are not limited to, at least one of the following: invoking the structure file generation model deployed on a remote server through a preset application programming interface; loading the preset structure file generation model weight file and running it locally; or accessing a server with the aforementioned structure file generation model deployed through a preset network interface. For example, the aforementioned structure file generation model may be a Qwen2.5-Coder model or a DeepSeek-Coder model. Wherein, in response to the aforementioned node construction type identifier being a page element construction type identifier, the aforementioned preset generation constraint information is used to constrain the aforementioned structure file generation model to generate a component structure including the host page element corresponding to the aforementioned currently to-be-built node; in response to the aforementioned node construction type identifier being a pass-through construction type identifier, the aforementioned preset generation constraint information is used to constrain the aforementioned structure file generation model to generate a component structure that does not include the host page element corresponding to the aforementioned currently to-be-built node and only combines the references of each sub-component.

[0053] Sub-step 5 involves extracting structural fingerprints from the initial component structure file and the subtree in the virtual node tree rooted at the current node to be built, respectively, to obtain the target structural fingerprint and the baseline structural fingerprint. The target structural fingerprint characterizes the initial component structure file in terms of root structure type, number of host page elements, number of child component references, and layout direction. The baseline structural fingerprint characterizes the subtree in terms of root structure type, number of host page elements, number of child component references, and layout direction. The root structure type can be the category of the outermost structure of the component's returned structure. For example, the root structure type can be a host page element, or a composite structure that does not generate host page elements corresponding to nodes but only combines the references of each child component (e.g., the Fragment structure in the React framework). In practice, the aforementioned execution entity can first use a code syntax parsing tool (e.g., a Babel parser) to perform syntax parsing on the initial component structure file, obtaining the abstract syntax tree corresponding to the initial component structure file, and then use the syntax tree traversal interface of the code syntax parsing tool (e.g., the traverse interface of the Babel parser) to traverse the abstract syntax tree. Then, for the four structural dimensions—root structure type, number of host page elements, number of child component references, and layout direction—the values ​​of the target structure fingerprint and the base structure fingerprint for each structural dimension are determined respectively. For the root structure type, when the outermost node of the component return structure in the above abstract syntax tree is a host page element node, the value of the root structure type in the target structure fingerprint is determined to be the host page element. When the outermost node is a composite structure that does not generate a host page element corresponding to the node but only combines the references of each child component, the value of the root structure type in the target structure fingerprint is determined to be the composite structure. When the node construction type identifier is a page element construction type identifier, the value of the root structure type in the base structure fingerprint is determined to be the host page element. When the node construction type identifier is a pass-through construction type identifier, the value of the root structure type in the base structure fingerprint is determined to be the composite structure. For the number of host page elements, the number of the outermost host page element nodes in the component return structure in the above abstract syntax tree is determined to be the value of the number of host page elements in the target structure fingerprint. When the node construction type identifier is a page element construction type identifier, the value of the number of host page elements in the base structure fingerprint is determined to be 1. When the node construction type identifier is a pass-through construction type identifier, the value of the number of host page elements in the base structure fingerprint is determined to be 0. For the number of child component references, the number of child component reference nodes in the above abstract syntax tree is determined as the value of the number of child component references in the target structure fingerprint; the number of child nodes of the root node of the above subtree in the above virtual node tree is determined as the value of the number of child component references in the base structure fingerprint. For the layout direction, when the outermost node of the component return structure in the above abstract syntax tree has a layout direction attribute, the value of the layout direction attribute is determined as the value of the layout direction in the target structure fingerprint; when the outermost node does not have a layout direction attribute (for example, the outermost node is a Fragment structure in the React framework), the value of the layout direction in the target structure fingerprint is determined to be null; when the node construction type identifier is a page element construction type identifier, the layout direction in the layout parameters associated with the root node of the above subtree is determined as the value of the layout direction in the base structure fingerprint; when the node construction type identifier is a pass-through construction type identifier, the value of the layout direction in the base structure fingerprint is determined to be null.

[0054] Sub-step 6 involves performing fingerprint comparison processing on the target structure fingerprint and the baseline structure fingerprint to obtain a fingerprint deviation value. This fingerprint deviation value characterizes the degree of structural difference between the initial component structure file and the subtree. The fingerprint deviation value can be a value between 0 and 1, with a larger value indicating a greater degree of difference. In practice, the executing entity can perform an equality comparison of the target structure fingerprint value with the baseline structure fingerprint value for each of the four structural dimensions: root structure type, number of host page elements, number of child component references, and layout direction. Structural dimensions with unequal values ​​are identified as differing structural dimensions. Then, the ratio of the number of differing structural dimensions to the total number of the four structural dimensions is determined as the fingerprint deviation value.

[0055] Sub-step 7 involves performing a state update process on the construction step based on the fingerprint deviation value and the remaining node sequence, until a component structure file set is obtained. This state update process can involve updating the constructed file set, the node sequence to be constructed, and the deviation constraint information based on whether the fingerprint deviation value exceeds a preset fingerprint deviation threshold and whether the remaining node sequence is empty, and outputting the component structure file set when a termination condition is met. The preset fingerprint deviation threshold can be a critical value used to determine whether there is a structural deviation between the initial component structure file and the subtree. For example, the preset fingerprint deviation threshold could be 0.2.

[0056] In some optional implementations of the embodiments, the above-mentioned state update processing of the construction step based on the fingerprint deviation value and the remaining node sequence until the component structure file set is obtained may include the following steps: In the first step, in response to determining that the fingerprint deviation value is less than or equal to the preset fingerprint deviation threshold and that the remaining node sequence is empty, the initial component structure file is added to the constructed file set to obtain the component structure file set.

[0057] The second step involves, in response to determining that the fingerprint deviation value is less than or equal to the preset fingerprint deviation threshold and that the remaining node sequence is not empty, adding the initial component structure file to the already constructed file set, identifying the remaining node sequence as the node sequence to be constructed, and identifying the preset empty constraint information as deviation constraint information, to execute the construction step again. The preset empty constraint information may be information that contains no content.

[0058] The third step involves, in response to determining that the fingerprint deviation value is greater than the preset fingerprint deviation threshold, generating target deviation constraint information based on the target structural fingerprint and the reference structural fingerprint, and defining the target deviation constraint information as deviation constraint information to execute the construction step again. The target deviation constraint information can be composed of deviation records corresponding to different structural dimensions where the target structural fingerprint and the reference structural fingerprint have different values. These deviation records may include the name of the different structural dimension, the value of the target structural fingerprint in that different structural dimension, and the value of the reference structural fingerprint in that different structural dimension. In practice, the executing entity may, in response to determining that the fingerprint deviation value is greater than the preset fingerprint deviation threshold, define the names of each different structural dimension, the values ​​of the target structural fingerprint in each different structural dimension, and the values ​​of the reference structural fingerprint in each different structural dimension as target deviation constraint information, and define the target deviation constraint information as deviation constraint information to execute the construction step again.

[0059] Step 105: Based on the view semantic information, perform phased attribute injection processing on the component structure file set to obtain the front-end application file set.

[0060] In some embodiments, the execution entity can perform phased attribute injection processing on the component structure file set based on the view semantic information to obtain a front-end application file set. The front-end application files in the front-end application file set can be source code files constituting the front-end application. These front-end application files can be interaction injection files or style variable files. The interaction injection file can be a source code file describing the component structure, style references, and interaction events corresponding to a node's component. The style variable file can be a source code file storing the correspondence between the variable identifiers of style marker variables and the style values ​​of those style marker variables.

[0061] In some optional implementations of certain embodiments, the process of performing phased attribute injection on the component structure file set based on the aforementioned view semantic information to obtain the front-end application file set may include the following steps: The first step is to process the style markup information included in the aforementioned view semantic information into style variable files, resulting in a style variable file set. In practice, the executing entity can, for each style markup variable in the style markup variable set included in the aforementioned style markup information, determine the variable identifier and style value of the style markup variable as a variable declaration statement according to the variable declaration format corresponding to the target style scheme; and determine the variable declaration statements corresponding to each style markup variable as the file content of the style variable file, thus obtaining the style variable file set. The aforementioned target style scheme can be the style implementation scheme adopted by the target front-end framework (e.g., CSS custom properties, SCSS variables). For example, when the aforementioned target style scheme is a CSS custom property, the style markup variable identified as "primary color" with a style value of "#1890FF" is determined as the variable declaration statement "--primary color: #1890FF;".

[0062] The second step involves injecting style references into the component structure file set based on the node reference relationship set included in the style markup information, resulting in a style injection file set. The style injection files in this set can be source code files that inject reference statements for style markup variables into the component structure files at various style attribute locations. In practice, the executing entity can, for each component structure file in the component structure file set, determine the variable identifiers of each style markup variable referenced by the corresponding node in the node reference relationship set as the target variable identifier set for that component structure file. It can then add reference statements for each variable identifier in the target variable identifier set to the style attribute locations of the component structure file, and add import statements for the corresponding style variable files in the style variable file set, thus obtaining the style injection file corresponding to that component structure file. The resulting style injection files constitute the style injection file set. The style attribute locations can be the code locations in the component structure file used to declare the component's visual style.

[0063] The third step involves performing interaction event binding processing on the style injection file set based on the component semantic information included in the view semantic information, resulting in an interaction injection file set. In practice, the execution entity can perform the following steps for each style injection file in the style injection file set: First, determine the interaction event information of the corresponding node in the style injection file from the interaction event information included in the component semantic information as the target interaction event information set corresponding to the style injection file. Second, if the target interaction event information set is empty, determine the style injection file as the interaction injection file corresponding to that style injection file; if the target interaction event information set is not empty, for each target interaction event information in the target interaction event information set, match the triggering method and action type included in the target interaction event information with a preset event mapping table to determine the event binding code template corresponding to the target interaction event information, fill the target node identifier of the action included in the target interaction event information into the event binding code template to obtain the event binding code corresponding to the target interaction event information, and add the event binding code to the style injection file to obtain the interaction injection file corresponding to the style injection file. The aforementioned preset event mapping table can be a mapping table with triggering method and action type as keys and event binding code templates as values. For example, the event binding code templates corresponding to the keys "click" and "jump" in the aforementioned preset event mapping table are click event listener code templates. The resulting interaction injection files constitute an interaction injection file set.

[0064] The fourth step is to determine the front-end application file set by combining the above-mentioned interaction injection file set and the above-mentioned style variable file set.

[0065] Step 106: Based on the virtual node tree, perform deviation-oriented correction processing on the front-end application file set to obtain the target front-end application file set.

[0066] In some embodiments, the execution entity may perform deviation-oriented correction processing on the front-end application file set according to the virtual node tree to obtain a target front-end application file set; wherein, the target front-end application file in the target front-end application file set may be the source code file used to build a front-end application that can be run and rendered by a terminal device to present a target front-end interface.

[0067] In addressing the technical problems mentioned above by adopting technical solutions, the following technical problem arises in the application scenario: building a front-end application for the complex view description file corresponding to the data management page of an enterprise-level back-end management system (e.g., a page containing multi-layered nested data tables, form groups, and operation control groups). This scenario often presents the following technical problem three: Due to the deep nesting hierarchy of the nodes in the complex view description file, if there is a deviation in the node hierarchy structure between the generated front-end application file and the virtual node tree, the deviation in the hierarchy structure of the upstream node will propagate layer by layer along the parent-child containment relationship to its descendant nodes. This results in redundant nesting levels and extra host page elements in the front-end application file that are inconsistent with the view description file. This increases the number of host page elements and the nesting hierarchy in the page structure when the terminal device displays the front-end interface, leading to increased rendering resource consumption when the terminal device displays the front-end interface. Considering the following requirements for this application scenario: locatable hierarchical deviations, traceable deviation propagation chains, controllable correction range, and consistent hierarchical structure, we have decided to adopt the following solution: In some optional implementations of certain embodiments, the process of performing deviation-oriented correction processing on the front-end application file set based on the virtual node tree to obtain the target front-end application file set may include the following steps: The first step is to extract the syntax tree from the aforementioned front-end application file set to obtain a component syntax tree set. The component syntax tree in this set can be an abstract syntax tree corresponding to an interaction injection file within the front-end application file set. Each syntax tree node in the abstract syntax tree corresponds to a syntax unit (e.g., component declaration, property declaration, style reference statement, event binding code, style rule) within the interaction injection file. In practice, the execution entity can first use the code syntax parsing tool to perform syntax parsing on the interaction injection file set included in the front-end application file set, obtaining the abstract syntax tree corresponding to each interaction injection file. Then, the obtained abstract syntax tree set is identified as the component syntax tree set, and the node identifier carried in the filename of the interaction injection file (e.g., "node_12" in the filename "node_12.jsx") is identified as the node identifier corresponding to the component syntax tree.

[0068] The second step involves extracting hierarchical structure differences from the virtual node tree to obtain a hierarchical deviation value. This hierarchical deviation value characterizes the degree of difference between the component syntax tree set and the virtual node tree in terms of node hierarchy. The value can be a number between 0 and 1. A larger value indicates a greater difference in the node hierarchy. In practice, the execution entity can first, for each component syntax tree in the component syntax tree set, use the syntax tree traversal interface of a code syntax parsing tool (e.g., the traverse interface of a Babel parser) to access the sub-component reference nodes in the component return structure of the component syntax tree. The correspondence between the node identifiers of the component syntax tree and the node identifiers of the sub-components referenced by the accessed sub-component reference nodes is determined as the generation reference relationship of the corresponding nodes in the component syntax tree. The node identifiers of the sub-components referenced by the sub-component reference nodes are the node identifiers carried in the filename of the interactive injection file corresponding to that sub-component in the import declaration of the component syntax tree. Then, for each tree node in the aforementioned virtual node tree, the correspondence between the node identifier of the tree node and the node identifiers of its various child nodes is determined as the baseline reference relationship for the tree node. Finally, for each of the aforementioned generated reference relationships, in response to the determination that the set of node identifiers of the sub-components referenced in the generated reference relationship is different from the set of node identifiers of the child nodes in the corresponding baseline reference relationship, the generated reference relationship is determined as a differential reference relationship. The ratio of the number of the aforementioned differential reference relationships to the number of the aforementioned generated reference relationships is determined as the hierarchical deviation value.

[0069] The third step involves extracting reference differences from the component syntax tree set based on the style tag information included in the view semantic information, thereby obtaining a style deviation degree value. This style deviation degree value characterizes the degree of difference between the component syntax tree set and the node reference relationship set included in the style tag information in terms of style references. It can be a value between 0 and 1, with a larger value indicating a greater degree of difference. In practice, the executing entity can first, for each node reference relationship in the node reference relationship set, determine that if the variable identifier included in the style reference statement of the corresponding node differs from the variable identifier included in the node reference relationship, then the node reference relationship is identified as a differing node reference relationship. Then, the ratio of the number of differing node reference relationships to the number of node reference relationships in the node reference relationship set is determined as the style deviation degree value.

[0070] The fourth step involves performing a layout constraint comparison on the component syntax tree set based on the layout semantic information included in the view semantic information, to obtain a layout deviation value. This layout deviation value characterizes the degree of difference between the component syntax tree set and the layout semantic information in terms of node arrangement; it can be a value between 0 and 1, with a larger value indicating a greater degree of difference. In practice, the executing entity can first, for each layout parameter of each node included in the layout semantic information, determine if the value of the layout parameter differs from the corresponding value in the layout attribute declaration of the node in the component syntax tree, identifying this as a difference layout parameter. Then, the ratio of the number of difference layout parameters to the number of layout parameters included in the layout semantic information is determined as the layout deviation value.

[0071] The fifth step involves performing deviation weight mapping on the aforementioned hierarchical deviation value, style deviation value, and layout deviation value to obtain the file deviation value. This file deviation value characterizes the overall difference between the aforementioned front-end application file set, the aforementioned virtual node tree, and the aforementioned view semantic information. It can be a value between 0 and 1, with larger values ​​indicating greater differences. In practice, the executing entity can multiply each of the hierarchical deviation value, style deviation value, and layout deviation value by its corresponding preset weight, then sum the results to determine the file deviation value. The preset weights can be pre-defined values ​​representing the proportion of the difference in the corresponding comparison dimension within the overall difference. The sum of the preset weights for each comparison dimension is 1, and the preset weight corresponding to the hierarchical deviation value is greater than the preset weights corresponding to the style deviation value and the layout deviation value. For example, the preset weights for the hierarchical, style, and layout deviation values ​​can be 0.5, 0.25, and 0.25, respectively.

[0072] Step 6: In response to determining that the deviation value of the aforementioned files is greater than a preset deviation threshold, deviation node localization processing is performed on the aforementioned component syntax tree set according to the aforementioned virtual node tree to obtain a node deviation information set. The aforementioned preset deviation threshold can be a critical value for determining whether the aforementioned front-end application file set needs deviation node localization. For example, the aforementioned preset deviation threshold can be 0.2. The node deviation information in the aforementioned node deviation information set can be information representing the deviation between the reference, style, or layout of a tree node presented in the generated front-end application file and the reference, style, or layout described by the aforementioned view semantic information and the aforementioned virtual node tree. The aforementioned node deviation information can include a node identifier and at least one dimension deviation item. The aforementioned dimension deviation item can be a record reflecting the difference between the presentation of the aforementioned tree node in the generated front-end application file and the description of the aforementioned view semantic information and the aforementioned virtual node tree on a comparison dimension. The aforementioned comparison dimension can include a hierarchy dimension, a style dimension, and a layout dimension. The dimension deviation item of the aforementioned hierarchy dimension can include a reference difference item and a path difference item. The aforementioned reference difference item can be a record reflecting the difference between the child components referenced by the aforementioned tree node itself and the child nodes of the aforementioned tree node in the aforementioned virtual node tree. The aforementioned path difference item can be a record reflecting the difference between the path taken by the root node to the aforementioned tree node during rendering and the corresponding path in the aforementioned virtual node tree. In practice, the aforementioned execution entity can perform the following positioning steps for each tree node in the aforementioned virtual node tree: First, in response to determining that the set of node identifiers of the child components referenced by the aforementioned tree node in the reference relationship expressed by the aforementioned component syntax tree set is different from the set of node identifiers of the child nodes of the aforementioned tree node in the aforementioned virtual node tree, the hierarchy dimension, the set of node identifiers of the child nodes of the aforementioned tree node in the aforementioned virtual node tree, and the set of node identifiers of the child components referenced by the aforementioned tree node in the aforementioned component syntax tree set are determined as a reference difference item for the aforementioned tree node. The second step involves determining the path formed by the node identifiers traversed from the root node of the aforementioned virtual node tree along the parent-child containment relationship to the aforementioned tree node as the baseline path, and determining the path formed by the node identifiers traversed from the root node to the aforementioned tree node in the reference relationship expressed by the aforementioned component syntax tree set as the generation path. In response to the determination that the baseline path and the generation path are different, the hierarchy dimension, the baseline path, and the generation path are determined as a path difference item for the aforementioned tree node. The third step involves determining that the variable identifiers included in the style reference statements of the aforementioned tree node in the component syntax tree are different from the variable identifiers referenced by the aforementioned tree node in the aforementioned style markup information, and the style dimension, the variable identifiers referenced by the aforementioned tree node in the aforementioned style markup information, and the variable identifiers included in the style reference statements of the aforementioned tree node in the aforementioned component syntax tree are determined as a style dimension deviation item for the aforementioned tree node.Fourth, in response to the determination that the values ​​of the layout attribute declarations of the aforementioned tree nodes in the component syntax tree differ from the values ​​of the layout parameters of the aforementioned tree nodes in the aforementioned layout semantic information, the layout dimension, the values ​​of the layout parameters of the aforementioned tree nodes in the aforementioned layout semantic information, and the values ​​of the layout attribute declarations of the aforementioned tree nodes in the aforementioned component syntax tree are determined as a layout dimension deviation item for the aforementioned tree node. Finally, the node identifier of each tree node with at least one dimension deviation item (including reference difference item, path difference item, style dimension deviation item, and layout dimension deviation item) and the obtained dimension deviation items are determined as the node deviation information of the aforementioned tree node, and the obtained node deviation information constitutes the node deviation information set.

[0073] Optionally, the execution entity may, in response to determining that the deviation value of the aforementioned file is less than or equal to the aforementioned preset deviation threshold, identify the aforementioned front-end application file set as the target front-end application file set and not perform subsequent deviation node location processing, hierarchical deviation transmission relationship identification processing, and hierarchical progressive correction processing.

[0074] Step 7: Based on the aforementioned virtual node tree, perform hierarchical deviation propagation relationship identification processing on the aforementioned node deviation information set to obtain the upstream deviation information set and the propagation deviation information set. The upstream deviation information in the upstream deviation information set can be node deviation information where the deviation originates from the node's own reference differences, style dimension deviations, or layout dimension deviations. The propagation deviation information in the propagation deviation information set can be node deviation information where the node's own references, style references, and layout attribute declarations are identical, but path differences occur during rendering only due to reference differences of its ancestor nodes propagating along the parent-child containment relationship. The ancestor nodes can be each tree node ascending level by level from the parent node of the aforementioned tree node along the parent-child containment relationship towards the root node. In practice, the aforementioned execution entity can perform the following identification steps for each node deviation information in the aforementioned node deviation information set: in response to determining that the aforementioned node deviation information contains at least one of reference differences, style dimension deviations, and layout dimension deviations, the aforementioned node deviation information is identified as upstream deviation information; in response to determining that the aforementioned node deviation information contains only path differences, the aforementioned node deviation information is identified as propagation deviation information. The obtained upstream deviation information constitutes the upstream deviation information set, and the obtained transmission deviation information constitutes the transmission deviation information set.

[0075] Step 8: Based on the aforementioned upstream deviation information set and the aforementioned propagation deviation information set, perform hierarchical progressive correction processing on the aforementioned front-end application file set to obtain the target front-end application file set. In practice, the aforementioned execution entity can first arrange each upstream deviation information in the aforementioned upstream deviation information set in order of increasing depth of the corresponding tree node hierarchy to obtain the upstream deviation information sequence. The aforementioned hierarchy depth can be the number of edges traversed from the root node of the aforementioned virtual node tree to the tree node. Then, for each upstream deviation information in the above upstream deviation information sequence, the component syntax tree corresponding to the above upstream deviation information is determined as the syntax tree to be corrected, and the following correction steps are performed: In response to determining that the above upstream deviation information contains reference difference items, the sub-component reference nodes in the component return structure of the above syntax tree to be corrected are added or deleted using the syntax tree node operation interface of the code syntax parsing tool (e.g., the node addition and deletion interface of the Babel parser), so that the node identifier of the sub-component referenced by each added or deleted sub-component reference node is the same as the node identifier of the child node of the above tree node in the above virtual node tree; In response to determining that the above upstream deviation information contains style dimension deviation items, the style reference statement corresponding to the style dimension deviation item in the above syntax tree to be corrected is replaced or supplemented with the reference statement corresponding to the variable identifier referenced by the above tree node in the above style markup information; In response to determining that the above upstream deviation information contains layout dimension deviation items, the value of the layout attribute declaration corresponding to the layout dimension deviation item in the above syntax tree to be corrected is replaced or supplemented with the value of the layout parameter of the above tree node in the above layout semantic information. Next, the corrected syntax trees corresponding to each upstream deviation information are converted into corresponding source code files to obtain the corrected front-end application files, as well as the component syntax trees corresponding to each propagation deviation information in the above propagation deviation information set, which are not corrected. Finally, the corrected front-end application files and the front-end application files in the above front-end application file set that have not been corrected are determined as the target front-end application file set.

[0076] The above technical solution and its related content, as an inventive point of this disclosure, together with step "Step 108" below, solve the third technical problem, "increased rendering resource consumption when the terminal device presents the front-end interface." Factors leading to increased rendering resource consumption when the terminal device presents the front-end interface are often as follows: Due to the deep nesting hierarchy of the nodes in the complex view description file, if there is a deviation in the node hierarchy structure between the generated front-end application file and the virtual node tree, the deviation in the hierarchy structure of the upstream node will propagate layer by layer along the parent-child containment relationship to its descendant nodes. This results in redundant nesting hierarchies and extra host page elements in the front-end application file that are inconsistent with the view description file, thereby increasing the number of host page elements and the nesting hierarchy in the page structure when the terminal device presents the front-end interface, leading to increased rendering resource consumption when the terminal device presents the front-end interface. Solving the above factors can reduce the rendering resource consumption when the terminal device presents the front-end interface. To achieve this effect, this disclosure first performs syntax tree extraction processing on the front-end application file set to obtain a component syntax tree set. Second, based on the virtual node tree, it performs hierarchical structure difference extraction processing on the component syntax tree set to obtain a hierarchical deviation degree value. Next, based on the style tag information included in the view semantic information, reference difference extraction processing is performed on the component syntax tree set to obtain the style deviation degree value. Then, based on the layout semantic information included in the view semantic information, layout constraint comparison processing is performed on the component syntax tree set to obtain the layout deviation degree value. Subsequently, deviation weight mapping processing is performed on the hierarchy deviation degree value, style deviation degree value, and layout deviation degree value to obtain the file deviation degree value. Here, the preset weight corresponding to the hierarchy deviation degree value is greater than the preset weights corresponding to the style deviation degree value and the layout deviation degree value, ensuring that the proportion of hierarchy structure differences in the file deviation degree value is higher than that of style differences and layout differences. This avoids the file deviation degree value falling below the preset deviation degree threshold due to small style differences and layout differences, thereby preventing the hierarchical structure differences that would propagate along the parent-child containment relationship to descendant nodes from being missed and not corrected. Then, in response to determining that the file deviation degree value is greater than the preset deviation degree threshold, deviation node location processing is performed on the component syntax tree set according to the virtual node tree to obtain the node deviation information set. Here, deviation node localization is only performed when the file deviation value exceeds a preset deviation threshold. This avoids performing deviation node localization and subsequent hierarchical correction on front-end application file sets with deviations within the preset threshold, thus reducing the processing resources consumed by the deviation orientation correction process. Next, based on the virtual node tree, hierarchical deviation transmission relationship identification processing is performed on the node deviation information set to obtain the upstream deviation information set and the transmission deviation information set.Here, the upstream deviation information originating from the node itself is distinguished from the propagation deviation information formed by the propagation along the parent-child containment relationship due to the indistinguishable nature of the node itself and only due to the reference difference of the ancestor node. This allows the hierarchical progressive correction process to only correct the front-end application file corresponding to the upstream deviation information, reducing the number of front-end application files that need to be corrected. Finally, based on the upstream deviation information set and the propagation deviation information set, the hierarchical progressive correction process is performed on the front-end application file set to obtain the target front-end application file set. Here, the hierarchical progressive correction process only applies to the front-end application file corresponding to the upstream deviation information. The front-end application file corresponding to the propagation deviation information is restored to the same level as the virtual node tree as the reference relationship corresponding to the upstream deviation information is corrected, without the need for separate correction. This eliminates the situation where descendant nodes are mounted through additional reference paths or the same component subtree is rendered repeatedly through different reference paths, reducing the nesting level of the page structure and repeated rendering processing when the terminal device presents the front-end interface. Therefore, the above technical solution and its related content, combined with step "Step 108" below, can reduce the rendering resource consumption when the terminal device presents the front-end interface.

[0077] Step 107: Compile the target front-end application file set to obtain the front-end application resource package, and deploy the front-end application resource package on the target server.

[0078] In some embodiments, the executing entity may perform engineering compilation on the target front-end application file set to obtain a front-end application resource package, and deploy the front-end application resource package on the target server. The front-end application resources in the front-end application resource package may be output files that can be directly loaded and run by the browser of the terminal device (e.g., static resource files such as Hypertext Markup Language files, Cascading Style Sheets, and JavaScript files). The target server may be a server that provides access services to the front-end application resource package. In practice, the executing entity may use front-end build tools (e.g., Webpack, Vite) to perform dependency resolution, code transpilation, and packaging on the target front-end application file set to obtain a front-end application resource package, and upload the front-end application resource package to the static resource directory of the target server to obtain a front-end application resource package deployed on the target server.

[0079] Step 108: In response to the target server receiving the access request sent by the terminal device, render and present the front-end interface corresponding to the aforementioned target view description file on the terminal device's display interface.

[0080] In some embodiments, in response to the target server receiving an access request from the terminal device, a front-end interface corresponding to the target view description file is rendered and presented on the display interface of the terminal device. The access request may be a network request sent by the terminal device to the target server to obtain the front-end application resource package. The display interface may be an area on the terminal device's screen used to display the front-end interface. In practice, the target server may, in response to receiving the access request from the terminal device, return the front-end application resource package to the terminal device; the terminal device's browser may load and render the front-end application resource package, presenting the front-end interface corresponding to the target view description file on the terminal device's display interface.

[0081] The above embodiments of this disclosure have the following beneficial effects: The front-end application construction method based on virtual node trees in some embodiments of this disclosure can reduce the rendering resource consumption when a terminal device presents a front-end interface. Specifically, the reason for the increased rendering resource consumption when a terminal device presents a front-end interface is that when constructing a complex view description file into a front-end application for the terminal device, if a code-to-code tool is designed to generate the front-end application file node by node according to the node hierarchy in the view description file, then nodes in the view description file that are only used to determine the hierarchical relationship between multiple child nodes and are not used to present interface content will also form corresponding page elements when the front-end application runs, increasing the number of nodes and nesting levels in the runtime page structure, resulting in increased rendering resource consumption when the terminal device presents a front-end interface. Based on this, the front-end application construction method based on virtual node trees in some embodiments of this disclosure can first, in response to receiving a front-end application construction request sent by the terminal device, obtain the target view description file corresponding to the front-end application construction request. Here, the target view description file provides the data foundation for subsequent node semantic parsing processing. Then, node semantic parsing processing is performed on the target view description file to obtain view semantic information. Here, the target view description file is parsed into view semantic information describing each node and the relationships between nodes, providing component semantic information, layout semantic information, and style markup information for subsequent hierarchical structure fusion processing and node-by-node classification and construction processing. Next, hierarchical structure fusion processing is performed on the view semantic information to obtain a virtual node tree. Here, the semantic, layout, style, and interaction information scattered in the view semantic information is merged into a unified tree structure, providing a comparison benchmark for the node hierarchy structure for subsequent node-by-node classification and construction processing and deviation-oriented correction processing. Then, based on the component semantic information and layout semantic information included in the view semantic information, node-by-node classification and construction processing is performed on the virtual node tree to obtain a component structure file set. Here, each node in the virtual node tree is distinguished by the structural representation it uses in the generated component structure file, ensuring that nodes that are not used to present interface content but only to determine the hierarchical relationship of child nodes do not form corresponding host page elements, reducing the number of host page elements and nesting levels in the page structure formed by the component structure file during terminal device rendering. Subsequently, based on the view semantic information, phased attribute injection processing is performed on the component structure file set to obtain the front-end application file set. Here, style references and interactive events are injected into the component structure file set in stages, providing a front-end application file set with style references and interactive events for subsequent deviation-oriented correction processing. Then, based on the virtual node tree, deviation-oriented correction processing is performed on the front-end application file set to obtain the target front-end application file set.Here, the node hierarchy of the front-end application file set is corrected using a virtual node tree as a comparison benchmark. This reduces redundant nesting levels and unnecessary host page elements that are inconsistent with the view description file in the target front-end application file set, further reducing the number of host page elements and nesting levels in the page structure formed during terminal device rendering. Next, the target front-end application file set is compiled to obtain a front-end application resource package, which is then deployed to the target server. Here, the target front-end application file set, after node hierarchy correction, is compiled into a front-end application resource package that can be loaded and run by the terminal device, reducing the number of host page elements and nesting levels in the page structure corresponding to the front-end application resource package deployed on the target server. Finally, in response to the target server receiving an access request from the terminal device, the front-end interface corresponding to the target view description file is rendered on the terminal device's display interface. Here, the reduction in the number of host page elements and nesting levels reduces the number of page elements that the terminal device needs to create and maintain when rendering the front-end interface, thus reducing the rendering resource consumption when the terminal device presents the front-end interface. Therefore, this front-end application construction method based on a virtual node tree can reduce the rendering resource consumption when the terminal device presents the front-end interface.

[0082] Further reference Figure 2 As an implementation of the methods shown in the above figures, this disclosure provides some embodiments of a front-end application building apparatus based on a virtual node tree. These apparatus embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, this virtual node tree-based front-end application building apparatus can be specifically applied to various electronic devices.

[0083] like Figure 2As shown, a front-end application building device 200 based on a virtual node tree includes: an acquisition unit 201, a semantic parsing unit 202, a fusion unit 203, a building unit 204, an attribute injection unit 205, a correction unit 206, a compilation unit 207, and a rendering unit 208. The acquisition unit is configured to: in response to receiving a front-end application building request sent by a terminal device, acquire the target view description file corresponding to the front-end application building request. The semantic parsing unit is configured to: perform node semantic parsing processing on the target view description file to obtain view semantic information. The fusion unit is configured to: perform hierarchical structure fusion processing on the view semantic information to obtain a virtual node tree. The building unit is configured to: perform node-by-node classification building processing on the virtual node tree according to the component semantic information and layout semantic information included in the view semantic information to obtain a component structure file set. The attribute injection unit is configured to: perform staged attribute injection processing on the component structure file set according to the view semantic information to obtain a front-end application file set. The correction unit is configured to perform deviation-oriented correction processing on the aforementioned front-end application file set based on the aforementioned virtual node tree, to obtain the target front-end application file set. The compilation unit is configured to perform engineering compilation processing on the aforementioned target front-end application file set to obtain a front-end application resource package, and to deploy the aforementioned front-end application resource package to the target server. The rendering unit is configured to, in response to the target server receiving an access request sent by the aforementioned terminal device, render and present the front-end interface corresponding to the aforementioned target view description file on the display interface of the aforementioned terminal device.

[0084] It is understandable that the units and references described in the front-end application building device 200 based on the virtual node tree are... Figure 1 The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the front-end application building device 200 based on the virtual node tree and the units contained therein, and will not be repeated here.

[0085] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device (e.g., an electronic device) 300 suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0086] like Figure 3As shown, the electronic device 300 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0087] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0088] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure 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 device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0089] It should be noted that, in some embodiments of this disclosure, the computer-readable medium described above may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may 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, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may 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 some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, 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: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0090] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0091] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs. When the electronic device executes the aforementioned one or more programs, the electronic device causes the following actions: In response to receiving a front-end application build request sent by a terminal device, the electronic device obtains a target view description file corresponding to the front-end application build request; performs node semantic parsing processing on the target view description file to obtain view semantic information; performs hierarchical structure fusion processing on the view semantic information to obtain a virtual node tree; performs node-by-node classification and construction processing on the virtual node tree based on the component semantic information and layout semantic information included in the view semantic information to obtain a component structure file set; performs phased attribute injection processing on the component structure file set based on the view semantic information to obtain a front-end application file set; performs deviation orientation correction processing on the front-end application file set based on the virtual node tree to obtain a target front-end application file set; performs engineering compilation processing on the target front-end application file set to obtain a front-end application resource package, and deploys the front-end application resource package on a target server; In response to the target server receiving an access request sent by the terminal device, the electronic device renders and presents a front-end interface corresponding to the target view description file on the display interface of the terminal device.

[0092] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar 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 a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0093] 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 this disclosure. 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 the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can 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.

[0094] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor may be described as including an acquisition unit, a semantic parsing unit, a fusion unit, a construction unit, an attribute injection unit, a correction unit, a compilation unit, and a rendering unit. The names of these units do not necessarily limit the unit itself; for example, the acquisition unit may also be described as "in response to receiving a front-end application construction request sent by a terminal device, acquiring the target view description file corresponding to the front-end application construction request."

[0095] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0096] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A method for building a front-end application based on a virtual node tree, characterized in that, include: In response to receiving a front-end application build request sent by a terminal device, the target view description file corresponding to the front-end application build request is obtained. The front-end application build request includes a design file identifier. The target view description file is a structured data file generated by the design tool for the design file corresponding to the design file identifier, which describes the interface element composition, hierarchical relationship between elements, element layout, element style and interaction behavior between elements of the target front-end interface. The target view description file is subjected to node semantic parsing to obtain view semantic information, wherein the view semantic information includes component semantic information, layout semantic information and style tag information; The view semantic information is subjected to hierarchical structure fusion processing to obtain a virtual node tree; Based on the component semantic information and layout semantic information included in the view semantic information, the virtual node tree is classified and constructed node by node to obtain a component structure file set. The component structure file set describes the component structure of a component corresponding to a node, but does not describe the style and interaction of the component. The component structure includes component declaration, attribute interface and sub-component reference relationship. The component declaration defines the name and boundary of the component. The attribute interface defines the parameters for the component to receive input data. The sub-component reference relationship is the reference of the component to each of its sub-components. Based on the view semantic information, a phased attribute injection process is performed on the component structure file set to obtain a front-end application file set. This includes: processing the style markup information included in the view semantic information into style variable files to obtain a style variable file set; performing style reference injection processing on the component structure file set based on the node reference relationship set included in the style markup information to obtain a style injection file set; performing interaction event binding processing on the style injection file set based on the component semantic information included in the view semantic information to obtain an interaction injection file set; and determining the interaction injection file set and the style variable file set as the front-end application file set. Based on the virtual node tree, the front-end application file set undergoes deviation-oriented correction processing to obtain a target front-end application file set, including: performing syntax tree extraction processing on the front-end application file set to obtain a component syntax tree set; performing hierarchical structure difference extraction processing on the component syntax tree set based on the virtual node tree to obtain a hierarchical deviation degree value; performing reference difference extraction processing on the component syntax tree set based on style tag information included in the view semantic information to obtain a style deviation degree value; performing layout constraint comparison processing on the component syntax tree set based on layout semantic information included in the view semantic information to obtain a layout deviation degree value; and performing the... The hierarchical deviation value, the style deviation value, and the layout deviation value are subjected to deviation weight mapping processing to obtain a file deviation value; in response to determining that the file deviation value is greater than a preset deviation threshold, deviation node positioning processing is performed on the component syntax tree set according to the virtual node tree to obtain a node deviation information set; hierarchical deviation transmission relationship identification processing is performed on the node deviation information set according to the virtual node tree to obtain an upstream deviation information set and a transmission deviation information set; hierarchical progressive correction processing is performed on the front-end application file set according to the upstream deviation information set and the transmission deviation information set to obtain a target front-end application file set; The target front-end application file set is processed by engineering compilation to obtain a front-end application resource package, and the front-end application resource package is deployed on the target server; In response to the target server receiving an access request sent by the terminal device, a front-end interface corresponding to the target view description file is rendered and presented on the display interface of the terminal device.

2. The method according to claim 1, characterized in that, The node semantic parsing process of the target view description file to obtain view semantic information includes: The target view description file is subjected to structured parsing processing to obtain the node hierarchy data, component association data, layout parameter data and style attribute data corresponding to the target view description file; Semantic association recognition processing is performed on the node-level data and the component-related data to obtain component semantic information; The layout parameter data is semantically mapped to obtain layout semantic information; The style attribute data is processed to mark style variables to obtain style mark information; The component semantic information, the layout semantic information, and the style tag information are determined as view semantic information.

3. The method according to claim 1, characterized in that, The hierarchical structure fusion processing of the view semantic information to obtain a virtual node tree includes: Based on the component semantic information included in the view semantic information, construct a node hierarchy tree; Based on the layout semantic information included in the view semantic information, the node hierarchy tree is subjected to parameter mapping processing to obtain the layout node tree; Based on the style tag information included in the view semantic information, the layout node tree is referenced and associated to obtain the style node tree; Based on the interactive event information included in the component semantic information, the style node tree is subjected to event binding processing to obtain the virtual node tree.

4. The method according to claim 1, characterized in that, The virtual node tree is then classified and constructed node by node based on the component semantic information and layout semantic information included in the view semantic information, resulting in a component structure file set, including: The virtual node tree is traversed and sorted hierarchically to obtain the sequence of nodes to be constructed, as well as the constructed file set and deviation constraint information. Based on the sequence of nodes to be built, the component semantic information, the layout semantic information, the built file set, and the deviation constraint information, the following construction steps are performed: The first node to be constructed in the sequence of nodes to be constructed is determined as the current node to be constructed, and the sequence of nodes to be constructed after removing the current node to be constructed is determined as the remaining node sequence; Based on the virtual node tree, determine the node construction type identifier of the current node to be constructed, and extract the target node semantic record from the component semantic information and the layout semantic information; Based on the node construction type identifier, the constructed file set is subjected to context adaptive extraction processing to obtain cascaded context information; Based on the cascading context information, the node construction type identifier, the target node semantic record, and the deviation constraint information, an initial component structure file corresponding to the current node to be constructed is generated. Structural fingerprint extraction is performed on the initial component structure file and the subtree in the virtual node tree rooted at the current node to be constructed, respectively, to obtain the target structural fingerprint and the baseline structural fingerprint; The target structure fingerprint and the reference structure fingerprint are compared to obtain the fingerprint deviation value. Based on the fingerprint deviation value and the remaining node sequence, the construction step is updated until the component structure file set is obtained.

5. The method according to claim 4, characterized in that, The step of updating the state of the construction step based on the fingerprint deviation value and the remaining node sequence until the component structure file set is obtained includes: In response to determining that the fingerprint deviation value is less than or equal to a preset fingerprint deviation threshold and the remaining node sequence is empty, the initial component structure file is added to the constructed file set to obtain the component structure file set; In response to determining that the fingerprint deviation value is less than or equal to the preset fingerprint deviation threshold and the remaining node sequence is not empty, the initial component structure file is added to the built file set, and the remaining node sequence is determined as the node sequence to be built, and the preset empty constraint information is determined as deviation constraint information, so as to execute the construction step again; In response to determining that the fingerprint deviation value is greater than the preset fingerprint deviation threshold, target deviation constraint information is generated based on the target structure fingerprint and the reference structure fingerprint, and the target deviation constraint information is determined as deviation constraint information to execute the construction step again.

6. A front-end application building device based on a virtual node tree, characterized in that, include: The acquisition unit is configured to, in response to receiving a front-end application build request sent by a terminal device, acquire a target view description file corresponding to the front-end application build request, wherein the front-end application build request includes a design file identifier, and the target view description file is a structured data file generated by a design tool for the design file corresponding to the design file identifier, which describes the interface element composition, hierarchical relationship between elements, element layout, element style, and interaction behavior between elements of the target front-end interface. The semantic parsing unit is configured to perform node semantic parsing processing on the target view description file to obtain view semantic information, wherein the view semantic information includes component semantic information, layout semantic information and style tag information; The fusion unit is configured to perform hierarchical structure fusion processing on the view semantic information to obtain a virtual node tree; The building unit is configured to perform node-by-node classification and building processing on the virtual node tree based on the component semantic information and layout semantic information included in the view semantic information, to obtain a component structure file set. The component structure file set contains a component structure file that describes the component structure corresponding to a node, but does not describe the style and interaction of the component. The component structure includes a component declaration, attribute interface, and sub-component reference relationship. The component declaration defines the name and boundaries of the component. The attribute interface defines the parameters for the component to receive input data. The sub-component reference relationship is the reference of the component to each of its contained sub-components. The attribute injection unit is configured to perform phased attribute injection processing on the component structure file set according to the view semantic information to obtain a front-end application file set, including: processing the style markup information included in the view semantic information into style variable files to obtain a style variable file set; performing style reference injection processing on the component structure file set according to the node reference relationship set included in the style markup information to obtain a style injection file set; performing interaction event binding processing on the style injection file set according to the component semantic information included in the view semantic information to obtain an interaction injection file set; and determining the interaction injection file set and the style variable file set as the front-end application file set. The correction unit is configured to perform deviation-oriented correction processing on the front-end application file set based on the virtual node tree to obtain a target front-end application file set, including: performing syntax tree extraction processing on the front-end application file set to obtain a component syntax tree set; performing hierarchical structure difference extraction processing on the component syntax tree set based on the virtual node tree to obtain a hierarchical deviation degree value; performing reference difference extraction processing on the component syntax tree set based on style tag information included in the view semantic information to obtain a style deviation degree value; and performing layout constraint comparison processing on the component syntax tree set based on layout semantic information included in the view semantic information to obtain a layout deviation degree value. The hierarchical deviation value, style deviation value, and layout deviation value are subjected to deviation weight mapping processing to obtain a file deviation value. In response to determining that the file deviation value is greater than a preset deviation threshold, deviation node positioning processing is performed on the component syntax tree set according to the virtual node tree to obtain a node deviation information set. Based on the virtual node tree, hierarchical deviation transmission relationship identification processing is performed on the node deviation information set to obtain an upstream deviation information set and a transmission deviation information set. Based on the upstream deviation information set and the transmission deviation information set, hierarchical progressive correction processing is performed on the front-end application file set to obtain a target front-end application file set. The compilation unit is configured to perform engineering compilation processing on the target front-end application file set to obtain a front-end application resource package, and to deploy the front-end application resource package on the target server; The rendering unit is configured to render a front-end interface corresponding to the target view description file on the display interface of the terminal device in response to the target server receiving an access request sent by the terminal device.

7. An electronic device, characterized in that, include: One or more processors; Storage device, on which one or more programs are stored, When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-5.

8. A computer-readable medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1-5.

Images