Page style processing method and device, electronic equipment and storage medium

Abstract

The application relates to the technical field of computer front-end development, and discloses a page style processing method and device, electronic equipment and a storage medium, which comprise the following steps: obtaining design analysis data of a target interface; identifying the component semantic type of a target element in the design analysis data, and determining a target front-end component corresponding to the target element according to the component semantic type; performing conflict evaluation on the design analysis data based on the native interaction logic style of the target front-end component, and determining static conflict attributes; filtering and extracting visual attributes between the target element and the target front-end component according to the static conflict attributes, and obtaining target incremental styles; and fusing the target incremental styles with underlying codes of the target front-end component to generate page layout codes. The application can be applied to financial and medical informationization data page construction scenes, and can avoid the technical problems of invalidation of component interaction logic and dislocation and shielding of interface layout caused by direct covering of static design styles on native interaction states of front-end components.

Description

Technical Field

[0001] This application relates to the field of computer front-end development technology, and can be applied to data page display and UI style management scenarios such as financial data terminal display and medical information interface construction. In particular, it relates to a page style processing method, device, electronic device and storage medium. Background Technology

[0002] In the field of web and application development, when converting static visual design files into front-end page code and combining them with existing front-end component libraries, the common approach is to directly extract all the visual attributes of the design draft and overlay them with the basic styles of the component library, or to directly override the original styles of the component through the generated static styles.

[0003] The inventors realized that existing style processing solutions rely excessively on the surface visual attributes of static interfaces, lacking the recognition of the inherent business logic semantics and dynamic interaction states of front-end components. Especially in application scenarios involving financial transaction terminals, medical electronic information, etc., which contain dense core data or frequent overlapping interactions, this forced overlay processing method can easily cause the static visual attributes in the design draft to destroy the native dynamic interaction logic of the component library, making the component interaction functions malfunction at runtime, and thus causing technical problems such as misalignment and obstruction of core business operations and key data display. Summary of the Invention

[0004] This invention provides a page style processing method, apparatus, electronic device, and storage medium to solve the technical problem that existing style processing solutions cause component interaction logic failure and interface layout misalignment and obstruction due to static design styles directly covering the native interactive state of front-end components.

[0005] To achieve the above objectives, a first aspect of this application proposes a page style processing method, including: Obtain the design analysis data of the target interface; Identify the component semantic type of the target element in the design parsing data, and determine the target front-end component corresponding to the target element based on the component semantic type; Based on the native interaction logic style of the target front-end component, the design parsing data is evaluated for conflict, and static conflict attributes are determined. Based on the static conflict attributes, the visual attributes between the target element and the target front-end component are filtered and extracted to obtain the target incremental style; The target incremental style is integrated with the underlying code of the target front-end component to generate page layout code.

[0006] To achieve the above objectives, a second aspect of this application provides a page style processing apparatus, the apparatus comprising: The acquisition module is used to acquire the design parsing data of the target interface; The identification module is used to identify the component semantic type of the target element in the design parsing data, and determine the target front-end component corresponding to the target element based on the component semantic type. The determination module is used to perform conflict assessment on the design parsing data based on the native interaction logic style of the target front-end component, and determine the static conflict attributes; The extraction module is used to filter and extract the visual attributes between the target element and the target front-end component based on the static conflict attributes, so as to obtain the target incremental style; The generation module is used to integrate the target incremental style with the underlying code of the target front-end component to generate page layout code.

[0007] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0008] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0009] The above-mentioned page style processing method, device, electronic device, and storage medium can acquire the design analysis data of the target interface; identify the component semantic type of the target element in the design analysis data, and determine the target front-end component corresponding to the target element based on the component semantic type; perform conflict assessment on the design analysis data based on the native interaction logic style of the target front-end component to determine static conflict attributes; filter and extract the visual attributes between the target element and the target front-end component based on the static conflict attributes to obtain the target incremental style; and integrate the target incremental style with the underlying code of the target front-end component to generate page layout code. In this application, targeting page construction scenarios involving dense data and high-frequency interactions, such as financial data terminal display and medical information interface construction, this solution first identifies the target front-end component corresponding to the target element by performing component semantic type identification on the design analysis data, thereby mapping the flat layer data in the static design draft into front-end component nodes with standard behavioral characteristics. Second, this solution introduces conflict assessment based on native interaction logic styles to detect attribute fields in the visual attributes of the design draft that have overlapping conflicts with the native interaction logic and mark them as static conflict attributes. In the subsequent filtering and extraction steps, these conflict fields are accurately removed to extract the target incremental style, separating the static decoration style from the dynamic interaction logic of the component itself from the data source, avoiding the risk of cascading pollution when style code is merged. Furthermore, in the final code fusion stage, this solution performs targeted fusion of the target incremental style with the underlying code of the target front-end component, so that the final generated page layout code retains the inherent interactive response mechanism of the basic component at both the physical and logical levels. Through the above processing from component semantic matching, interaction state conflict assessment, incremental field removal to code structure integration, this solution enables the final generated page layout code to have a flexible structure based on the actual logical semantics of the components. It can solve the technical problems of existing style processing solutions causing component interaction logic failure and interface layout misalignment and occlusion due to static design styles directly covering the native interaction state of front-end components. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram of an application environment for a page style processing method according to an embodiment of the present invention; Figure 2 This is a flowchart of the page style processing method provided in the embodiments of this application; Figure 3 This is another flowchart of the page style processing method provided in the embodiments of this application; Figure 4 This is another flowchart of the page style processing method provided in the embodiments of this application; Figure 5 This is another flowchart of the page style processing method provided in the embodiments of this application; Figure 6 This is another flowchart of the page style processing method provided in the embodiments of this application; Figure 7 This is another flowchart of the page style processing method provided in the embodiments of this application; Figure 8 This is another flowchart of the page style processing method provided in the embodiments of this application; Figure 9 This is a schematic diagram of the structure of the page style processing device provided in the embodiments of this application; Figure 10 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 11 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0013] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0014] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0015] In the field of web development, the common techniques for converting visual design drafts into front-end page code are code generation based on absolute coordinate positioning or layout transformation based on row and column cutting based on fixed physical boundaries.

[0016] The inventors realized that existing conversion schemes rely excessively on the surface physical boundaries of elements for cutting or positioning, lacking the identification and analysis of the page's inherent logical semantic structure and the true visual layering intent. Especially in application scenarios involving finance, healthcare, etc., which contain dense data or frequent layered interactions, this approach is prone to causing misalignment, obstruction, or functional failure of critical business data when adapting to multiple terminals, resulting in poor maintainability of the final generated code.

[0017] Based on this, embodiments of this application provide a page style processing method, apparatus, device, and storage medium, aiming to solve the technical problem that existing solutions lack the ability to parse the page's logical semantic structure and true layering intent due to excessive reliance on surface physical boundaries, resulting in poor maintainability of the generated code and easy occurrence of misalignment and obstruction of business data.

[0018] The page style processing method, apparatus, device, and storage medium provided in the embodiments of this application are specifically described through the following embodiments. First, the page style processing method in the embodiments of this application is described.

[0019] The page style processing method provided in this embodiment of the invention can be applied to, for example, Figure 1In this application environment, the client communicates with the server via a network. The server can obtain the design parsing data of the target interface from the client; identify the component semantic type of the target element in the design parsing data, and determine the target front-end component corresponding to the target element based on the component semantic type; perform conflict assessment on the design parsing data based on the native interaction logic style of the target front-end component to determine static conflict attributes; filter and extract the visual attributes between the target element and the target front-end component based on the static conflict attributes to obtain the target incremental style; integrate the target incremental style with the underlying code of the target front-end component to generate page layout code, and feed the page layout code back to the client. In this application, targeting page construction scenarios involving dense data and high-frequency interactions, such as financial data terminal display and medical information interface construction, this solution first identifies the target front-end component corresponding to the target element by performing component semantic type identification on the design analysis data, thereby mapping the flat layer data in the static design draft into front-end component nodes with standard behavioral characteristics. Second, this solution introduces conflict assessment based on native interaction logic styles to detect attribute fields in the visual attributes of the design draft that have overlapping conflicts with the native interaction logic and mark them as static conflict attributes. In the subsequent filtering and extraction steps, these conflict fields are accurately removed to extract the target incremental style, separating the static decoration style from the dynamic interaction logic of the component itself from the data source, avoiding the risk of cascading pollution when style code is merged. Furthermore, in the final code fusion stage, this solution performs targeted fusion of the target incremental style with the underlying code of the target front-end component, so that the final generated page layout code retains the inherent interactive response mechanism of the basic component at both the physical and logical levels. Through the aforementioned processes—from component semantic matching, interaction state conflict assessment, incremental field removal, to structured code integration—this solution enables the final generated page layout code to possess a flexible structure arranged according to the actual logical semantics of the components. This solves the technical problems of existing style processing solutions, where static design styles directly override the native interaction states of front-end components, leading to component interaction logic failure and misaligned / obstructed interface layouts. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a dedicated server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0020] Figure 2 This is an optional flowchart of the page style processing method provided in the embodiments of this application. Figure 2 The method may include, but is not limited to, steps S201 to S205.

[0021] Step S201: Obtain the design analysis data of the target interface.

[0022] Step S202: Identify the component semantic type of the target element in the design parsing data, and determine the target front-end component corresponding to the target element based on the component semantic type.

[0023] Step S203: Based on the native interaction logic style of the target front-end component, perform conflict assessment on the design parsing data and determine the static conflict attributes.

[0024] Step S204: Based on the static conflict attributes, filter and extract the visual attributes between the target element and the target front-end component to obtain the target incremental style.

[0025] Step S205: Integrate the target incremental style with the underlying code of the target front-end component to generate page layout code.

[0026] In step S201 of some embodiments, in the automated construction scenario of front-end D2C (Design to Code), the target interface is usually represented as a static visual design file output by the designer (e.g., source files generated by specific design tools such as Sketch and Figma). These source files are mostly a collection of vector graphics and layer configurations in physical form, and cannot directly participate in the code compilation logic of the front-end project. Therefore, it is necessary to convert these unstructured visual graphic files into a low-level data stream that the algorithm program can directly read, traverse, and calculate.

[0027] Furthermore, at the underlying data structure level of the computer, design analysis data manifests as structured DSL (Domain Specific Language) data, typically stored using lightweight data exchange formats such as JSON. This DSL data is not simply image pixel slices, but rather an abstract node tree generated after deconstructing the original design draft using specific design tool plugins. During the parsing and conversion process, each layer and its internal element nodes in the design draft are scanned one by one, converting the original visual representation into a cross-platform data description, thus serving as a unified data protocol connecting the design and development ends. Specifically, the aforementioned design analysis data contains a rich array of interconnected technical parameter dimensions. First, it contains fully extracted visual attribute information, covering static parameters such as layout coordinates, size data, color values, font styles, and border styles for each element. Second, it includes hierarchical relationships and nested structures; during layer parsing, the parent-child relationships and spatial wrapping context between element nodes are recorded simultaneously, providing a basis for subsequently reconstructing the DOM (Document Object Model) structure of the page. Third, the parsed data also includes identified component library tag information; that is, during the parsing phase, it scans and distinguishes in advance which nodes in the design draft have preset reference tags to the underlying component library, and which nodes belong to purely custom drawing layers. Through the above acquisition and deep parsing process, the static visual design draft is losslessly transformed into structured parsed data containing full visual features, spatial nesting topology, and component reference tags, providing basic data support and contextual information for subsequent accurate identification of the component semantics of target elements, style difference comparison, and conflict isolation.

[0028] In step S202 of some embodiments, after obtaining the structured design analysis data, since the parsed target elements are mostly flat layers lacking inherent interactive logic, it is necessary to assign them actual business meaning. Semantic analysis can be performed by comprehensively considering the visual presentation characteristics and contextual structure of the target elements to identify the component type of the target element in the real business scenario. For example, identifying a rectangular layer containing text and background color as essentially representing a button component with clickable functionality, or identifying a text node with an outer border as representing an input box component. After clarifying the component semantic type of the target element, a search and association is performed in the pre-accessed front-end component library to find a standard code component matching the semantic type and identify it as the target front-end component. This step establishes a logical mapping between the physical layer and the front-end component with dynamic behavior, enabling subsequent style processing to have a clear component object reference.

[0029] Please see Figure 3In some embodiments, step S202 may include, but is not limited to, steps S301 to S302.

[0030] Step S301: Extract multi-dimensional visual features from the design analysis data, and match the multi-dimensional visual features with the standard style feature models of each UI component in the preset UI component feature library to determine the component semantic type of the target element.

[0031] Step S302: Extract the component identifier corresponding to the component semantic type, and retrieve the target component configuration information corresponding to the component identifier in the preset component mapping table to obtain the target front-end component.

[0032] In step S301 of some embodiments, multidimensional visual features refer to data parsed from the design source file that characterizes the visual and physical attributes of a certain layer element. These typically include the boundary size ratio of the layer element, the text context content, the aspect ratio, and the sub-layer relationship structure or parent wrapping node contained within the layer element in the entire view topology. The UI component feature library refers to a pre-built knowledge base storing feature data for various standard front-end controls. The standard style feature model of each UI component is a benchmark model obtained by statistically summarizing the visual attribute distribution and internal structure of a large number of known standard components. In practical applications, such as in the electronic medical record management interface of a medical information system, if a target element contains a specific rectangular border, placeholder text context such as "Please enter patient vital signs," and a specific cursor layer structure nested within it, these attributes constitute the multidimensional visual features of the element. By inputting these multidimensional visual features into a preset UI component feature library and performing similarity or rule matching with the style feature models of each standard component in the library, when the matching degree with the feature model of the standard input box component meets the set requirements, the component semantic type of the target element can be determined as an input box type. Similarly, in the scenario of a financial transaction terminal, if a layer element has a specific highlighted background and contains text features such as "Confirm," its component semantic type can be determined as a button type through feature matching, thereby achieving semantic classification of flat, unstructured layer data.

[0033] In step S302 of some embodiments, the component identifier refers to a text label used to uniquely indicate and distinguish a specific control category in the front-end component engineering system. The component mapping table, as a configuration relational data structure, internally maintains the correspondence between abstract component semantic labels and code entities in the specific front-end engineering component library. After clarifying the component semantic type of the target element, the corresponding component identifier is extracted and used as a search key to perform a matching query in the component mapping table, thereby retrieving the corresponding target component configuration information. The target component configuration information includes engineering parameters such as the code import path of the corresponding front-end component, the version of the underlying dependency package, the basic style class name, and default attribute configuration items. For example, after determining that an element in the medical system belongs to the input box type or an element in the financial system belongs to the button type, searching the mapping table using the component identifier can directly obtain the import path and configuration information of the corresponding specific input box code component or button code component in the standard component library, thus establishing it as the target front-end component for subsequent style fusion.

[0034] Through steps S301 to S302 described above, this embodiment of the application extracts multi-dimensional visual features from the design analysis data and matches them with the UI component feature library. This overcomes the limitations of traditional code generation tools that rely solely on layer naming or single file structures for identification, improving the accuracy of parsing the true semantic types of elements in complex and non-standard design drafts. Based on this, the component identifier is used to dynamically retrieve target component configuration information from the component mapping table to determine the target front-end component, thus establishing a mapping link between abstract design draft layer data and specific engineered front-end component library entity code. For scenarios with stringent requirements for high interface reliability, such as those in the financial or medical fields, this solution ensures that the generated code is accurately mapped to standard components, avoiding the problem of repeatedly generating redundant hard-coded basic styles. This provides a component node foundation for subsequent precise style conflict assessment and incremental fusion.

[0035] In step S203 of some embodiments, standard front-end basic components typically pre-encapsulate native interaction logic styles for responding to user operations, such as dynamic style feedback when the mouse hovers, clicks to activate, or gains focus. However, design parsing data often extracts static visual embellishments of the interface at specific moments. If all attributes of the design draft are applied indiscriminately in subsequent processing, it is easy for static code to forcibly suppress native dynamic styles. Therefore, this step uses the native interaction logic styles carried by the target front-end component itself as a benchmark to scan the design draft data for potential pollution risks. For example, in a button component, the basic component has built-in dynamic feedback that the background color darkens when clicked or hovered. If the design draft forcibly assigns a globally fixed static background color to the button layer, the system will identify and mark this fixed background color in the design draft as a static conflict attribute. Similarly, a form input box has a native state highlight border when it gains focus. If this border is obscured or interfered with by the static border setting in the design draft, the relevant design draft attributes will also be judged as static conflict attributes, thereby preventing style cascading pollution.

[0036] Please see Figure 4 In some embodiments, step S203 may include, but is not limited to, steps S401 to S403.

[0037] Step S401: Extract the dynamic interaction state style attribute class from the native interaction logic style.

[0038] Step S402: Compare the types of the dynamic interaction state style attribute class with the visual attributes in the design analysis data, and detect whether there are static style assignments in the design analysis data that belong to the same type of visual attribute as the dynamic interaction state style attribute class.

[0039] Step S403: The detected static style is marked as a static conflict attribute.

[0040] In step S401 of some embodiments, the target front-end component, as a standardized engineered code module, typically pre-encapsulates rich interactive feedback mechanisms to respond to user input. These interactive feedback mechanisms are primarily manifested at the code level as specific Cascading Style Sheets (CSS) selector style classes. By parsing the underlying style file of the target front-end component, a set of attribute classes responsible for changes in interactive states can be extracted. The hover pseudo-class selector style corresponds to the hover pseudo-class in CSS, used to define the visual feedback when the mouse pointer hovers over an element; the focus pseudo-class selector style corresponds to the focus pseudo-class, used to define the state when a form or input element gains input focus; and the active dynamic state selector style corresponds to the active pseudo-class or a state class dynamically bound by the framework, used to define the feedback behavior of the component when clicked by the mouse or pressed by a touch. In application scenarios such as financial transactions or medical data entry, these dynamic interactive state styles directly correspond to key functions such as operation confirmation and status prompts. Extracting them effectively establishes a list of styles that cannot be violated during subsequent style integration.

[0041] In step S402 of some embodiments, under the front-end engineering style cascading rules, style overriding conflicts typically occur in the definition of the same CSS property (such as background-color, border-color, or box-shadow). Therefore, this step does not compare specific values, but intercepts and detects at the dimension of property category. The specific visual attributes operated by the dynamic interaction state extracted in step S401 are mapped and compared with the basic visual attributes extracted from the static design parsing data. For example, in the medical electronic medical record scenario, the target front-end component "patient information input box" will change its border color to indicate that it is currently in the input state when it is in the focused state; if the design parsing data finds that the designer has forcibly assigned a globally fixed and state-indistinguished static border color to the input box layer, then the category matching detection shows that these two belong to the same type of visual attribute.

[0042] In step S403 of some embodiments, based on the above type comparison and conflict detection results, once it is confirmed that a certain visual attribute in the design parsing data will interfere with or cover the preset interactive response mechanism of the target front-end component, a specific conflict identifier is attached to the static style. This marking action plays a role in isolation and blocking, clearly defining it as a static conflict attribute, thereby distinguishing it from those harmless regular layout or visual decoration attributes. In financial scenarios, the interactive feedback of real-time buy / sell buttons cannot be compromised, and it is important to avoid directly writing such dangerous styles that would cause the button to "lose click interaction feedback" into the final page code.

[0043] Through steps S401 to S403, this embodiment of the application accurately extracts the dynamic interactive state style attribute classes of the target front-end component, such as hovering, focusing, and activation, and compares them with the visual attributes in the design analysis data in terms of type dimension. This allows for early prediction and interception of potential overriding risks during style cascading. Furthermore, static styles with interference risks are marked as static conflict attributes. This avoids the simple overriding of interactive logic by traditional code generation tools that only achieves visual reproduction in the pre-code fusion stage. For core business scenarios such as healthcare and finance, which involve high-frequency interactions and are sensitive to operational feedback, this effectively prevents the cascading pollution of native dynamic interactive states by highly weighted static design styles. This solves the technical problem of component interaction logic failure and lack of user operation feedback caused by forced overriding of static styles in the runtime state.

[0044] In step S204 of some embodiments, after identifying the attribute fields with potential interaction interference risks, a filtering and extraction mechanism is needed to determine the style code that balances design fidelity and interaction safety. First, the visual attributes in the design parsing data are compared item by item with the default basic style attributes of the target front-end component, eliminating redundant fields that completely overlap, and obtaining the original set of differing attributes. Then, based on the static conflict attributes determined in the previous step, this set of differing attributes is filtered, deleting all style fields marked with static conflict flags. Taking the aforementioned financial transaction button as an example, differing attributes that do not affect interaction, such as the rounded corner radius, specific button width, or inner and outer margins set in the design draft, are retained, but fixed background color assignments determined to be static conflict attributes are deleted. After this targeted trimming and purification process, the output is the target incremental style, which eliminates sources of contamination that may disrupt the component's interactive feedback.

[0045] Please see Figure 5 In some embodiments, step S204 may include, but is not limited to, steps S501 to S503.

[0046] Step S501: Calculate the difference between the visual attributes in the design parsing data and the default style attributes of the target front-end component to obtain the original set of difference attributes.

[0047] Step S502: Input the original set of difference attributes into the preset attribute list filter to filter out candidate style attributes that belong to layout-related attributes.

[0048] Step S503: Traverse the candidate style attributes, remove style fields that belong to static conflict attributes from the candidate style attributes, and output the target incremental style.

[0049] In step S501 of some embodiments, in actual front-end engineering development, the standardized target front-end component itself has a complete set of default style attributes, such as default padding, basic font size, and border thickness. To avoid generating a large number of redundant style declarations in the final generated code, an attribute difference comparison operation needs to be performed. Specifically, the visual attribute key-value pairs extracted from the design parsing data are compared item by item with the default style attribute key-value pairs of the target front-end component. When the values ​​of the two are exactly the same in a certain style field (such as font-size or border-radius), the attribute will be regarded as an inheritable redundant attribute and eliminated; when the key values ​​are inconsistent, or when new attributes not defined in the component's default style appear in the design draft, these differing attribute fields will be extracted to form the original set of differing attributes. For example, when building a financial data center, if the background color of a transaction data card component set in the design draft is the same as the default background color of the standard basic card component, it will not be extracted; however, if the design draft increases the outer margin of the card to adapt to a specific dashboard area, the difference value of the outer margin will be included in the original difference attribute set. This extraction method based on difference calculation greatly reduces the volume of invalid code.

[0050] In step S502 of some embodiments, not all the difference attributes extracted from the design draft are suitable for imposing on the front-end code component. Direct application of some deep structural attributes or specific layout attributes may disrupt the component's built-in responsive container logic. Therefore, this step introduces a preset attribute list filter for security interception. This attribute list filter is essentially a configurable set of validation and interception rules, internally maintaining a whitelist of style attributes that allow secure injection. The original set of difference attributes generated in the previous step is input into this filter, and the key names of each attribute field are checked one by one. The filter will allow safe layout-related attributes, such as margin, width, top / left positioning coordinates, and some safe visual embellishment attributes, while blocking attributes not in the whitelist. Taking the electronic medical record interface for clinical medical information as an example, when dealing with complex nested forms for vital sign entry, the system uses an attribute list filter to allow the extraction of only layout-related attributes related to the spacing of each input control in the design draft. It filters out attributes in the design draft that may be destructive due to designer misoperation, such as internal floating or forced overflow hiding. The attribute set output after this layer of filtering eliminates candidate style attributes with structural damage risks.

[0051] In step S503 of some embodiments, after difference comparison and whitelist filtering, redundant data and structurally destructive attributes have been separated from the candidate style attributes. However, static style assignments that may interfere with the dynamic feedback of components may still be hidden. Therefore, the candidate style attributes are iterated over in combination with the previously determined static conflict attribute markers. During the iteration, if a style field in the candidate style attributes is found to have a static conflict attribute marker, it will be unconditionally removed. For example, when processing the "high-risk operation blocking button" in a financial system, although the static red background of the button has passed the previous difference comparison and whitelist filtering, it is determined in the conflict assessment stage that it will cover the original click-to-blur interaction state. Therefore, the static background color field will be forcibly deleted in this step, and only harmless fields such as the button's width, height, and margins will be retained. After this stripping operation, the final output dataset is the target incremental style, which is essentially a safe style that is harmless to the original interaction logic and accurately restores the design differences.

[0052] Through steps S501 to S503, this embodiment of the application eliminates redundant code using difference calculations, ensures the robustness of the component layout structure using attribute list filters, and isolates the cascading pollution of the native dynamic behavior of standard front-end components by forcibly removing style fields with static conflict markers. When applied to page construction scenarios with complex logic and low fault tolerance, such as financial transactions and medical electronic medical records, this filtering and extraction process can effectively solve the technical problem of existing style processing solutions that result in lengthy page layouts and invalid component interaction logic due to blindly exporting all design draft styles. It ensures that the final extracted target incremental style can both restore the layout differences of the visual design and has extremely high engineering maintainability.

[0053] Please see Figure 6 In some embodiments, steps S601 to S602 may be included before step S205: Step S601: Read the reference canvas size of the design analysis data and obtain the viewport resolution parameters and screen density parameters of the target display terminal; Step S602: Using the reference canvas size, viewport resolution parameters, and screen density parameters, adaptive boundary calculation is performed on the fixed pixel values ​​in the target incremental style, and the adapted incremental style containing relative responsive units is output.

[0054] In step S601 of some embodiments, the reference canvas size refers to the basic pixel width and height values ​​of the global canvas preset by the UI designer in the design source file, which constitutes the initial spatial reference system for restoring the front-end page presentation; the viewport resolution parameter refers to the width and height pixel values ​​of the actual visible rendering area of ​​the target display terminal screen that ultimately runs and renders the page layout code; the screen density parameter is used to characterize the density of pixel distribution per unit physical area of ​​the display device screen, which is usually expressed as the device pixel ratio during the code compilation and rendering stages. In the multi-terminal distribution scenario of financial and medical information management systems, due to the significant differences in the display hardware specifications of various office outlets and clinical departments, such as the ultra-wide viewing angle multi-screen monitoring monitor used in high-frequency financial trading, the portable mobile ward round tablet used in nurse stations, and the professional medical diagnostic monitors with different resolutions used by doctors in clinics, their viewport resolutions and screen densities are all different. By reading the reference canvas size of the original design draft in advance and simultaneously obtaining the viewport resolution parameters and screen density parameters of the currently running terminal, the hardware discrete metric parameters between static visual design and runtime physical screen can be determined, thereby providing data support for subsequent differentiated adaptive unit conversion and boundary calculation.

[0055] In step S602 of some embodiments, after obtaining the relevant multidimensional canvas and display terminal hardware parameters, the originally fixed absolute pixel values ​​in the target incremental style are dynamically reconstructed through specific adaptive boundary calculations. In specific implementations, classification mapping conversion is performed based on the container layout characteristics of the incremental style attributes. For example, when it is identified that the current value belongs to the width and height attributes that need to change with container scaling, the corresponding fixed pixel value is combined with the baseline canvas size and viewport resolution parameters and proportionally converted into viewport width unit values ​​or viewport height unit values, so that the component size can adapt to the stretching of the viewport physical size. When it is identified that the current value belongs to the font size or border boundary attributes that need to maintain readability and avoid visual blurring or occlusion due to over-scaling, the fixed pixel value is converted into the root element relative unit value and combined with the screen density parameters for adaptive boundary range fine-tuning.

[0056] Please see Figure 7 In some embodiments, step S602 may include, but is not limited to, steps S701 to S703.

[0057] Step S701: Identify the container layout characteristics of the current attribute in the target incremental style. When the current attribute has the elastic scaling characteristic, convert the fixed pixel value into a viewport unit value.

[0058] Step S702: When the current attribute has an absolute size characteristic, convert the fixed pixel value to a relative unit value of the root element.

[0059] Step S703: Bind the converted viewport unit value and the root element relative unit value to the preset global Cascading Style Sheet custom variable template to generate the adaptive incremental style.

[0060] In step S701 of some embodiments, in front-end responsive development, different style attributes undertake different visual space allocation functions. To avoid proportional scaling destroying the page structure, semantic parsing is first performed on each attribute in the target incremental style to identify its container layout characteristics. Specifically, when it is determined that the currently processed style attribute is mainly used to build the macro page skeleton and fluid module placeholders, it is classified as belonging to the elastic scaling characteristic. For this type of attribute, in order to ensure that it can scale proportionally under different screen sizes, the original fixed pixel value (px) extracted from the design draft is dynamically converted into viewport unit values ​​such as viewport width unit (vw) or viewport height unit (vh) using the baseline canvas size and viewport resolution parameters obtained in the previous steps. For example, in the financial trading scenario, the width of the outer wrapping container of the real-time market chart needs to dynamically widen as the trader stretches the external large screen or widescreen. At this time, its original fixed pixel width is converted into a vw value, thereby ensuring the high flexibility and adaptive fluid performance of the page macro layout framework when rendering across terminals.

[0061] In step S702 of some embodiments, unlike the macroscopic flexible layout features of the container, the page contains some style attributes that are extremely sensitive to visual recognizability and physical size, such as font size, border line thickness, or specific icon fine-tuning spacing. If these attributes are also elastically stretched along with the viewport, it is very easy for the font to be too large on a large screen, occupying too much effective screen space, or for the text to be too small to read on a small screen. Therefore, when it is recognized that the current attribute plays a role in maintaining the readability of the content and the clarity of the physical boundaries, it is determined to be an absolute size characteristic. For such attributes, their fixed pixel values ​​are converted into the root element's relative unit value rem. The root element's relative unit value allows developers to dynamically control the font size of the root node, combined with screen density parameters, to achieve unified and controlled scaling. For example, in the electronic medical record entry interface of a medical system, the size of the warning text for high-risk medication prevention, and the size of the quotation numbers in a financial trading terminal, are both identified as absolute size characteristics and converted into rem units. This processing logic ensures that critical medical texts and financial data maintain an appropriate physical reading size across different devices, preventing important business information from losing readability due to excessive distortion.

[0062] In step S703 of some embodiments, after completing the dynamic conversion of all fixed pixels, the calculated viewport unit values ​​and root element relative unit values ​​are extracted and uniformly bound to the custom variable template of the global cascading style sheet according to the preset front-end engineering naming conventions. Subsequently, in the actual incremental style declaration section, these calculated values ​​are called by variable reference to generate the final adapted incremental style. In complex front-end engineering architectures of medical or financial multi-business lines, this variable encapsulation method that separates specific numerical parameters from style declarations not only improves the reusability and maintainability of style code, but also supports dynamic and seamless switching between the terminal's dark mode and eye protection mode.

[0063] In step S205 of some embodiments, after obtaining the safe target incremental style, the code engineering assembly stage begins, where the refined target incremental style is injected into the underlying code structure of the corresponding target front-end component. Since the injected incremental style has undergone strict conflict filtering in the preceding steps, its integration with the underlying code proceeds smoothly without causing style occlusion of native behaviors. For example, when generating a patient information entry form page for a medical system, the processed target incremental styles of each vital sign input box are seamlessly integrated with the native input form component code in the front-end engineering framework. The resulting page layout code not only presents the layout and specific visual typography required by the design draft but also fully preserves the native interactive response mechanisms of the basic components in scenarios such as error reporting, focusing, and hovering, ultimately delivering code files that can be directly compiled and rendered by the front-end engineering.

[0064] Please see Figure 8 In some embodiments, step S205 may include, but is not limited to, steps S801 to S803.

[0065] Step S801: Determine the framework type of the target front-end engineering environment and import the engineering component template file that matches the framework type.

[0066] Step S802: Remove the forced override marker field from the target incremental style code, and encapsulate the target incremental style code using a single-level class selector so that the selector stacking weight value of the target incremental style is lower than the selector stacking weight value of the native interaction logic style in the target front-end component.

[0067] Step S803: The encapsulated target incremental style code is appended to the end of the underlying code in the engineered component template file to generate the page layout code file.

[0068] In step S801 of some embodiments, actual front-end development involves heterogeneous underlying technology architectures such as React, Vue, or WeChat Mini Programs, and the component lifecycle and style scope mechanisms of each framework differ significantly. Before performing code fusion, the framework type on which the target front-end project environment depends is first detected, and the corresponding engineered component template file is retrieved and imported from the preset asset library. This template file contains built-in tag closure structures and mounting points that conform to the characteristics of a specific framework, building a basic code skeleton for subsequent incremental code injection.

[0069] In step S802 of some embodiments, to prevent static styles from disrupting the component's preset interactive functions, this step implements proactive code degradation processing. It scans the target incremental style code flow, forcibly strips and removes forced override marker fields (such as !important declarations), and eliminates their overriding attributes. Subsequently, high-weight identifier selectors or deeply nested multi-level class selectors are discarded, and basic single-level class selectors (such as .className) are uniformly used for outer encapsulation. Through this physical degradation operation, the selector cascading weight value of the target incremental style is strictly limited from the compilation and parsing level, ensuring it is lower than the weight of the target front-end component's native interactive logic style. This weight suppression ensures that while the basic layout and decorative styles are rendered normally, the component's native hover or click state feedback can take over the visual rendering rights with higher weight.

[0070] In step S803 of some embodiments, based on the cascading rule that browser parsing engines prioritize the application of post-declarations when processing sibling styles, the physical storage location of the code directly determines the final rendering priority. The downgraded and encapsulated target incremental style code is converted into a standard string data stream and injected into the template file via appending to the end of the file. During execution, the incremental code fragment is positioned at the end of the target front-end component's native underlying code declaration, forming a clear order of post-dependencies. Finally, the complete code stream, including the framework template, native declarations, and post-incremental styles, is compiled and encapsulated, outputting the page layout code file. This appending method ensures that incremental styles are safely attached to business components only as a visual supplementary layer, avoiding preemption of the loading channel for the native logic of the underlying components during compilation.

[0071] Through steps S201 to S205, this solution addresses page construction scenarios involving dense data and high-frequency interactions, such as financial data terminal display and medical information interface construction. First, it identifies the target front-end component corresponding to the target element by performing component semantic type identification on the design analysis data, thus mapping the flat layer data in the static design draft to front-end component nodes with standard behavioral characteristics. Second, this solution introduces conflict assessment based on native interaction logic styles to detect attribute fields in the design draft's visual attributes that conflict with the native interaction logic and mark them as static conflict attributes. In subsequent filtering and extraction steps, these conflicting fields are accurately removed to extract the target incremental style, separating the static decorative style from the component's own dynamic interaction logic from the data source, avoiding the risk of cascading pollution during style code fusion. Third, in the final code fusion stage, this solution performs targeted fusion of the target incremental style with the underlying code of the target front-end component, ensuring that the final generated page layout code retains the inherent interactive response mechanism of the basic component at both the physical and logical levels. Through the above processing from component semantic matching, interaction state conflict assessment, incremental field removal to code structure integration, this solution enables the final generated page layout code to have a flexible structure based on the actual logical semantics of the components. It can solve the technical problems of existing style processing solutions causing component interaction logic failure and interface layout misalignment and occlusion due to static design styles directly covering the native interaction state of front-end components.

[0072] Please see Figure 9 This application also provides a page style processing apparatus to implement the above-described page style processing method. The apparatus includes: The acquisition module is used to acquire the design parsing data of the target interface; The identification module is used to identify the component semantic type of the target element in the design parsing data, and determine the target front-end component corresponding to the target element based on the component semantic type. The determination module is used to perform conflict assessment on the design parsing data based on the native interaction logic style of the target front-end component and determine the static conflict attributes; The extraction module is used to filter and extract the visual attributes between the target element and the target front-end component based on static conflict attributes, so as to obtain the target incremental style; The generation module is used to merge the target incremental style with the underlying code of the target front-end component to generate page layout code.

[0073] In some embodiments, the identification module is specifically used for: Extract multidimensional visual features from the design analysis data, and match the multidimensional visual features with the standard style feature models of each UI component in the preset UI component feature library to determine the component semantic type of the target element; Extract the component identifier corresponding to the component semantic type, and retrieve the target component configuration information corresponding to the component identifier in the preset component mapping table to obtain the target front-end component.

[0074] In some embodiments, the determining module is specifically used for: Extract the dynamic interaction state style attribute class from the native interaction logic style; Compare the dynamic interaction state style attribute class with the visual attributes in the design analysis data to detect whether there are static style assignments in the design analysis data that belong to the same type of visual attribute as the dynamic interaction state style attribute class. Detected static styles are marked as static conflict attributes.

[0075] In some embodiments, the extraction module is specifically used for: Calculate the difference between the visual attributes in the design analysis data and the default style attributes of the target front-end component to obtain the original set of difference attributes; Input the original set of difference attributes into the preset attribute list filter to filter out candidate style attributes that belong to layout-related attributes; Iterate through the candidate style attributes, remove style fields that are static conflict attributes, and output the target incremental style.

[0076] In some embodiments, the generation module is further configured to: Read the baseline canvas size from the design analysis data and obtain the viewport resolution and screen density parameters of the target display terminal; Using the baseline canvas size, viewport resolution parameters, and screen density parameters, adaptive boundary calculations are performed on the fixed pixel values ​​in the target incremental style, and the output is an adapted incremental style containing relative responsive units. Accordingly, the target incremental style is integrated with the underlying code of the target front-end component, including: integrating the adapted incremental style with the underlying code of the target front-end component.

[0077] In some embodiments, the generation module is further configured to: Identify the container layout characteristics of the current attribute in the target incremental style. When the current attribute has a flex scaling characteristic, convert the fixed pixel value to a viewport unit value. When the current property has an absolute size property, convert the fixed pixel value to a value relative to the root element. The converted viewport unit value and the root element's relative unit value are bound to a preset global Cascading Style Sheet custom variable template to generate an adaptive incremental style.

[0078] In some embodiments, the generation module is specifically used for: Determine the framework type of the target front-end project environment and import the engineering component template file that matches the framework type; Remove the forced override marker field from the target incremental style code, and encapsulate the target incremental style code using a single-level class selector so that the selector stacking weight of the target incremental style is lower than the selector stacking weight of the native interactive logic style in the target front-end component. The encapsulated target incremental style code is appended to the end of the underlying code in the engineered component template file as a string, generating the page layout code file.

[0079] This invention provides a page style processing device. First, by performing component semantic type recognition on the design parsing data, the target front-end component corresponding to the target element is determined, thereby mapping the flat layer data in the static design draft to front-end component nodes with standard behavioral characteristics. Second, this solution introduces conflict assessment based on native interaction logic styles to detect attribute fields in the visual attributes of the design draft that have overlapping conflicts with the native interaction logic and mark them as static conflict attributes. In the subsequent filtering and extraction steps, these conflict fields are accurately removed to extract the target incremental style. This separates the static decorative style from the dynamic interaction logic of the component itself from the data source, avoiding the risk of cascading pollution during style code fusion. Furthermore, in the final code fusion stage, this solution performs targeted fusion of the target incremental style with the underlying code of the target front-end component, so that the final generated page layout code retains the inherent interactive response mechanism of the basic component at both the physical and logical levels. Through the above processing from component semantic matching, interaction state conflict assessment, incremental field removal to code structure integration, this solution enables the final generated page layout code to have a flexible structure based on the actual logical semantics of the components. It can solve the technical problems of existing style processing solutions causing component interaction logic failure and interface layout misalignment and occlusion due to static design styles directly covering the native interaction state of front-end components.

[0080] For specific limitations regarding the page style processing device, please refer to the limitations on the page style processing method above, which will not be repeated here. Each module in the aforementioned page style processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0081] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements a page style processing method on the server side, fulfilling its functions or steps.

[0082] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 11 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements a page style processing method's client-side functions or steps.

[0083] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain the design analysis data of the target interface; Identify the component semantic type of the target element in the design parsing data, and determine the target front-end component corresponding to the target element based on the component semantic type; Based on the native interaction logic style of the target front-end component, a conflict assessment is performed on the design parsing data to determine static conflict attributes; Based on static conflict attributes, the visual attributes between the target element and the target front-end component are filtered and extracted to obtain the target incremental style; The target incremental style is integrated with the underlying code of the target front-end component to generate page layout code.

[0084] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Obtain the design analysis data of the target interface; Identify the component semantic type of the target element in the design parsing data, and determine the target front-end component corresponding to the target element based on the component semantic type; Based on the native interaction logic style of the target front-end component, a conflict assessment is performed on the design parsing data to determine static conflict attributes; Based on static conflict attributes, the visual attributes between the target element and the target front-end component are filtered and extracted to obtain the target incremental style; The target incremental style is integrated with the underlying code of the target front-end component to generate page layout code.

[0085] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0086] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0087] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0088] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0089] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for processing page styles, characterized in that, include: Obtain the design analysis data of the target interface; Identify the component semantic type of the target element in the design parsing data, and determine the target front-end component corresponding to the target element based on the component semantic type; Based on the native interaction logic style of the target front-end component, the design parsing data is evaluated for conflict, and static conflict attributes are determined. Based on the static conflict attributes, the visual attributes between the target element and the target front-end component are filtered and extracted to obtain the target incremental style; The target incremental style is integrated with the underlying code of the target front-end component to generate page layout code.

2. The page style processing method according to claim 1, characterized in that, The step of identifying the component semantic type of the target element in the design parsing data, and determining the target front-end component corresponding to the target element based on the component semantic type, includes: Extract multidimensional visual features from the design analysis data, and match the multidimensional visual features with the standard style feature models of each UI component in the preset UI component feature library to determine the component semantic type of the target element; Extract the component identifier corresponding to the component semantic type, and retrieve the target component configuration information corresponding to the component identifier in the preset component mapping table to obtain the target front-end component.

3. The page style processing method according to claim 1, characterized in that, The process of evaluating the design parsing data for conflict based on the native interaction logic style of the target front-end component, and determining static conflict attributes, includes: Extract the dynamic interaction state style attribute class from the native interaction logic style; The dynamic interaction state style attribute class is compared with the visual attributes in the design analysis data to detect whether there is a static style assignment in the design analysis data that belongs to the same type of visual attribute as the dynamic interaction state style attribute class. The detected static style is marked as the static conflict attribute.

4. The page style processing method according to claim 1, characterized in that, The step of filtering and extracting the visual attributes between the target element and the target front-end component based on the static conflict attributes to obtain the target incremental style includes: Calculate the difference between the visual attributes in the design analysis data and the default style attributes of the target front-end component to obtain the original set of difference attributes; Input the original set of difference attributes into a preset attribute list filter to filter out candidate style attributes that belong to layout-related attributes; Iterate through the candidate style attributes, remove style fields that belong to the static conflict attributes, and output the target incremental style.

5. The page style processing method according to claim 1, characterized in that, Before fusing the target incremental style with the underlying code of the target front-end component to generate page layout code, the method further includes: Read the baseline canvas size of the design analysis data and obtain the viewport resolution parameters and screen density parameters of the target display terminal; Using the reference canvas size, the viewport resolution parameter, and the screen density parameter, adaptive boundary calculation is performed on the fixed pixel values ​​in the target incremental style, and the adapted incremental style containing relative responsive units is output. Accordingly, the step of merging the target incremental style with the underlying code of the target front-end component includes: merging the adapted incremental style with the underlying code of the target front-end component.

6. The page style processing method according to claim 5, characterized in that, The method of using the reference canvas size, the viewport resolution parameter, and the screen density parameter to perform cross-end adaptive boundary calculation on the fixed pixel values ​​in the target incremental style, and outputting an adapted incremental style containing relative responsive units, includes: Identify the container layout characteristics of the current attribute in the target incremental style; when the current attribute has a flexible scaling characteristic, convert the fixed pixel value into a viewport unit value. When the current attribute is an absolute size property, the fixed pixel value is converted to a relative unit value of the root element; The converted viewport unit value and the relative unit value of the root element are bound to a preset global cascading style sheet custom variable template to generate the adaptive incremental style.

7. The page style processing method according to claim 1, characterized in that, The step of integrating the target incremental style with the underlying code of the target front-end component to generate page layout code includes: Determine the framework type of the target front-end engineering environment and import the engineering component template file that matches the framework type; Remove the forced override marker field from the target incremental style code, and encapsulate the target incremental style code using a single-level class selector so that the selector stacking weight value of the target incremental style is lower than the selector stacking weight value of the native interactive logic style in the target front-end component. The encapsulated target incremental style code is appended to the end of the underlying code in the engineered component template file to generate the page layout code file.

8. A page style processing device, characterized in that, The device includes: The acquisition module is used to acquire the design parsing data of the target interface; The identification module is used to identify the component semantic type of the target element in the design parsing data, and determine the target front-end component corresponding to the target element based on the component semantic type. The determination module is used to perform conflict assessment on the design parsing data based on the native interaction logic style of the target front-end component, and determine the static conflict attributes; The extraction module is used to filter and extract the visual attributes between the target element and the target front-end component based on the static conflict attributes, so as to obtain the target incremental style; The generation module is used to integrate the target incremental style with the underlying code of the target front-end component to generate page layout code.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the page style processing method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the page style processing method according to any one of claims 1 to 7.

Images