Low-code page rendering method and device, electronic equipment and storage medium
By pre-rendering the HTML of low-code pages on the server side and combining rendering data, the time-consuming and white screen problems of low-code platform rendering is solved, and fast and smooth page loading is achieved.
Patent Information
- Application Number
- CN202510323729.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-18
- Publication Date
- 2025-07-29
AI Technical Summary
Low-code platforms take a long time to render low-code pages, and are prone to white screens.
The pre-rendering strategy is used to generate HTML of the target low-code page on the server side, and the page rendering is combined with the data required for rendering. After generating the initial rendering page, hydrate it to avoid the client from rendering from scratch.
Significantly shortens page loading time, avoids the white screen of the home page, improves rendering efficiency, and provides a smooth page access experience.
Smart Images
Figure CN120386945A_ABST
Abstract
Description
Technical Field
[0001] The present disclosure relates to the field of computer technologies, and in particular, to a method, an apparatus, an electronic device, and a storage medium for rendering a low-code page. Background Art
[0002] A low-code platform is a type of APaaS (Application Platform as a Service) platform centered around low-code technology. It utilizes a micro-frontend application architecture and can dynamically mount sub-applications at runtime. By means of the CSR (Client Side Rendering) rendering strategy and combined with low-code technical means, the purpose of quickly building an application is achieved.
[0003] Under the CSR rendering strategy, when a user accesses a web page, the server first returns an initial HTML file. This file generally only contains basic HTML (Hyper Text Markup Language) tags such as <html>, <body>, <head>, as well as several links to JavaScript files and possibly existing CSS style sheet links. After the browser loads this HTML file, it will start to download and execute the JavaScript code (such as the common app.js). Subsequently, the JavaScript code will obtain the required data from the server through a network request. Immediately afterwards, JavaScript will use the obtained data to dynamically generate HTML content on the browser side by operating the DOM (Document Object Model) and insert it into the specified DOM node in the HTML file, thereby realizing the rendering of the page.
[0004] However, due to the fact that the CSR rendering strategy needs to wait for JavaScript to obtain data and perform rendering, the first-screen loading time is relatively long, and the page is prone to the phenomenon of a white screen. Summary of the Invention
[0005] The present disclosure provides a method, an apparatus, an electronic device, and a storage medium for rendering a low-code page to at least solve the problem that the low-code platform has a long rendering time and is prone to the white-screen phenomenon when rendering a low-code page in the related art. The technical solution of the present disclosure is as follows:
[0006] According to a first aspect of an embodiment of the present disclosure, a method for rendering a low-code page is provided, including:
[0007] Sending a page loading request to a server, where the page loading request is used to load a low-code page of a target sub-application;
[0008] Receive the sub-application data fed back by the server in response to the page loading request. The sub-application data includes the target HyperText Markup Language (HTML) of the target low-code page and the data required for rendering the target low-code page. The target HTML is generated by the server through a pre-rendering strategy and the target low-code page;
[0009] Perform page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page;
[0010] Perform hydration processing on the preliminary rendered page to obtain the target rendered page corresponding to the target low-code page.
[0011] In one embodiment, the performing page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page includes:
[0012] Parse the sub-application data;
[0013] If a Document Object Model (DOM) node reuse identifier is parsed from the sub-application data, obtain the target HTML from the sub-application data and perform DOM node reuse processing based on the target HTML to obtain a target DOM structure;
[0014] Perform page rendering according to the target DOM structure and the data required for rendering the target low-code page to obtain a preliminary rendered page.
[0015] In one embodiment, the performing page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page further includes:
[0016] If a DOM node reuse identifier is not parsed from the sub-application data, create a target DOM structure for the target low-code page;
[0017] Perform page rendering according to the target DOM structure and the sub-application data to obtain a preliminary rendered page.
[0018] In one embodiment, the performing DOM node reuse processing based on the target HTML to obtain a target DOM structure includes:
[0019] Locate and determine the mounting container of the target sub-application from the target HTML;
[0020] Extract the first child element from the mounted container as the DOM node to be reused. After storing the attribute content of the target attribute in the DOM node to be reused, clear the target attribute in the DOM node to be reused;
[0021] Create a shadow DOM according to the sub-application data, and add the shadow DOM to the target attribute of the DOM node to be reused to obtain a target DOM structure.
[0022] According to the second aspect of the embodiments of the present disclosure, there is provided a method for rendering a low-code page, including:
[0023] Receive a page loading request sent by a client for a target sub-application;
[0024] In response to the page loading request, obtain the target hypertext markup language HTML of the target low-code page and the data required for rendering the target low-code page, where the target HTML is generated by the server through a prerendering strategy and the target low-code page;
[0025] Send the target HTML of the target low-code page and the data required for rendering the target low-code page as sub-application data to the client, so that the client performs page rendering based on the sub-application data.
[0026] In one embodiment, the obtaining the target HTML of the target low-code page includes:
[0027] Obtain the prerendered hydration fragment corresponding to the target sub-application from at least one storage source;
[0028] Perform a splicing operation on the obtained prerendered hydration fragment using a dehydrated template to obtain the target HTML of the target low-code page.
[0029] In one embodiment, the method further includes:
[0030] Simulate a browser environment, and perform page prerendering on the page of the target sub-application in the browser environment to obtain the prerendered hydration fragment of the target sub-application;
[0031] Store the prerendered hydration fragment of the target sub-application in at least one storage source.
[0032] According to the third aspect of the embodiments of the present disclosure, there is provided a low-code page rendering device, including:
[0033] A sending unit, configured to execute sending a page loading request to a server, where the page loading request is used to load a low-code page of a target sub-application;
[0034] A receiving unit, configured to receive the sub-application data fed back by the server in response to the page loading request, where the sub-application data includes the target HyperText Markup Language (HTML) of the target low-code page and the data required for rendering the target low-code page, and the target HTML is generated by the server through a pre-rendering strategy and the target low-code page;
[0035] A rendering unit, configured to perform page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page;
[0036] A hydration unit, configured to perform hydration processing on the preliminary rendered page to obtain the target rendered page corresponding to the target low-code page.
[0037] In one embodiment, the rendering unit is specifically configured to perform:
[0038] Parse the sub-application data;
[0039] If a Document Object Model (DOM) node reuse identifier is parsed from the sub-application data, obtain the target HTML from the sub-application data, and perform DOM node reuse processing based on the target HTML to obtain a target DOM structure;
[0040] Perform page rendering according to the target DOM structure and the data required for rendering the target low-code page to obtain a preliminary rendered page.
[0041] In one embodiment, the rendering unit is specifically further configured to perform:
[0042] If a DOM node reuse identifier is not parsed from the sub-application data, create a target DOM structure of the target low-code page;
[0043] Perform page rendering according to the target DOM structure and the sub-application data to obtain a preliminary rendered page.
[0044] In one embodiment, the rendering unit is specifically configured to perform:
[0045] Find and determine the mounting container of the target sub-application from the target HTML;
[0046] Extract the first sub-element from the mounting container as the DOM node to be reused, store the attribute content of the target attribute in the DOM node to be reused, and then clear the target attribute in the DOM node to be reused;
[0047] Create a shadow DOM according to the sub-application data, and add the shadow DOM to a target attribute of the DOM node to be reused, obtaining a target DOM structure.
[0048] According to a fourth aspect of the embodiments of the present disclosure, there is provided a rendering device for a low-code page, including:
[0049] A receiving unit, configured to receive a page loading request sent by a client for a target sub-application;
[0050] An obtaining unit, configured to, in response to the page loading request, obtain a target HyperText Markup Language (HTML) of the target low-code page and data required for rendering the target low-code page, where the target HTML is generated by the server through a prerendering strategy and the target low-code page;
[0051] A sending unit, configured to send the target HTML of the target low-code page and the data required for rendering the target low-code page as sub-application data to the client, so that the client performs page rendering based on the sub-application data.
[0052] In one embodiment, the obtaining unit is specifically configured to:
[0053] Obtain a prerendered hydration fragment corresponding to the target sub-application from at least one storage source;
[0054] Perform a splicing operation on the obtained prerendered hydration fragment using a dehydrated template to obtain the target HTML of the target low-code page.
[0055] In one embodiment, the device further includes:
[0056] A prerendering unit, configured to simulate a browser environment and perform page prerendering on a page of a target sub-application in the browser environment to obtain a prerendered hydration fragment of the target sub-application;
[0057] A storage unit, configured to store the prerendered hydration fragment of the target sub-application in at least one storage source.
[0058] According to a fifth aspect of the embodiments of the present disclosure, there is provided an electronic device, including: a processor; and a memory for storing executable instructions of the processor; wherein, the processor is configured to execute the instructions to implement any one of the low-code page rendering methods provided in the first aspect.
[0059] According to a sixth aspect of the embodiments of the present disclosure, there is provided a computer-readable storage medium. When instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute any one of the low-code page rendering methods provided in the first aspect.
[0060] According to a seventh aspect of the embodiments of the present disclosure, there is provided a computer program product. The computer program product includes instructions that, when executed by a processor of an electronic device, enable the electronic device to execute any one of the low-code page rendering methods provided in the first aspect.
[0061] The technical solutions provided by the embodiments of the present disclosure at least bring the following beneficial effects:
[0062] For the low-code page rendering method, apparatus, electronic device, and storage medium provided by the embodiments of the present disclosure, the low-code platform may send a page loading request for loading the low-code page of the target sub-application to the server, and receive the sub-application data fed back by the server in response to the page loading request. The sub-application data includes the target hypertext markup language (HTML) of the target low-code page and the data required for rendering the target low-code page, where the target HTML is generated by the server through a pre-rendering strategy and the target low-code page. The low-code platform may perform page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page, and perform hydration processing on the preliminary rendered page to obtain the target rendered page corresponding to the target low-code page. By adopting the low-code page rendering method, apparatus, electronic device, and storage medium provided by the embodiments of the present disclosure, part of the rendering work of the low-code page is pre-positioned to the server side. The pre-rendering completed in advance on the server side will generate the target HTML. When the user requests a page, the low-code platform no longer needs to perform page rendering from scratch, but can quickly use the existing pre-rendering results, thereby greatly shortening the page loading time and providing the user with a smoother and faster page access experience. Moreover, since part of the page content has been pre-rendered in advance, the user will not see a blank page when opening the page (i.e., the phenomenon of a blank first page is avoided), that is, the rendering efficiency of the low-code page can be significantly improved, and the problem of a possible blank first page can be effectively solved.
[0063] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS
[0064] The accompanying drawings herein are incorporated into the specification and constitute a part of the specification, showing embodiments consistent with the present disclosure, and are used together with the specification to explain the principles of the present disclosure and do not constitute an improper limitation of the present disclosure.
[0065] Figure 1 It is a flowchart of a method for rendering a low-code page shown according to an exemplary embodiment.
[0066] Figure 2 It is a refined flowchart of step 106 shown according to an exemplary embodiment.
[0067] Figure 3 It is a refined flowchart of step 204 shown according to an exemplary embodiment.
[0068] Figure 4 It is a refined flowchart of step 106 shown according to an exemplary embodiment.
[0069] Figure 5 It is a flowchart of a method for rendering a low-code page shown according to another exemplary embodiment.
[0070] Figure 6 It is a refined flowchart of step 504 shown according to an exemplary embodiment.
[0071] Figure 7 It is a flowchart of a method for rendering a low-code page shown according to an exemplary embodiment.
[0072] Figure 8 It is a schematic diagram of a method for rendering a low-code page shown according to another exemplary embodiment.
[0073] Figure 9 It is a schematic diagram of a method for rendering a low-code page shown according to another exemplary embodiment.
[0074] Figure 10 It is a schematic diagram of a method for rendering a low-code page shown according to another exemplary embodiment.
[0075] Figure 11 It is a block diagram of a device for rendering a low-code page shown according to an exemplary embodiment.
[0076] Figure 12 It is a block diagram of a device for rendering a low-code page shown according to another exemplary embodiment.
[0077] Figure 13 It is a block diagram of an electronic device shown according to an exemplary embodiment. Detailed implementation
[0078] It should be noted that the terms "first", "second", etc. in the description, claims and the above-mentioned drawings of the present disclosure are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present disclosure described here can be implemented in an order other than those illustrated or described here. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present disclosure. On the contrary, they are only examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.
[0079] It should also be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for display, data for analysis, etc.) involved in the present disclosure are all information and data authorized by the user or fully authorized by all parties.
[0080] Figure 1 It is a flowchart of a method for rendering a low-code page shown according to an exemplary embodiment. In this embodiment, the method is exemplified by being applied to a terminal. It can be understood that the method can also be applied to a server, or applied to a system including a terminal and a server, and is implemented through the interaction between the terminal and the server. In this embodiment, the method includes the following steps 102 to 108, where:
[0081] Step 102, send a page loading request to the server, where the page loading request is used to load the low-code page of the target sub-application.
[0082] In the embodiment of the present disclosure, the low-code platform using the micro-frontend application architecture is a runtime solution, which dynamically mounts sub-applications at runtime. Exemplarily, when a user wants to load a low-code page of a target sub-application on the low-code platform, a corresponding low-code page loading operation will be triggered. This operation can be triggered by the user's click, navigation or other interaction methods, and the present disclosure does not make specific limitations on this. The client can respond to the low-code page loading operation and send a page loading request to the server. The page loading request contains information about the target sub-application, so that the server knows which sub-application's page data needs to be provided.
[0083] Step 104, receive the sub-application data fed back by the server in response to the page loading request. The sub-application data includes the target hypertext markup language (HTML) of the target low-code page and the data required for rendering the target low-code page. The target HTML is generated by the server through a pre-rendering strategy and the target low-code page.
[0084] In the embodiments of the present application, after receiving a page loading request, the server determines a target sub-application according to the page loading request, obtains the target HTML of the target low-code page of the target sub-application and the data required for rendering, and feeds back corresponding sub-application data to the client based on the target HTML of the target low-code page and the data required for rendering.
[0085] Among them, the target low-code page is the first-screen page of the target sub-application. The target HTML is the dehydrated HTML obtained by pre-rendering the target low-code page using a pre-rendering strategy. The pre-rendering strategy is a strategy used to implement the pre-rendering operation of a page. This strategy is used to convert the page into HTML data. The dehydrated HTML is a static representation, similar to "dehydrating" the content of the page into a format that can be quickly transmitted and displayed. The pre-rendering process will be elaborated in detail in the embodiments on the server side, and will not be elaborated herein in the embodiments of the present disclosure.
[0086] The data required for rendering may include, but is not limited to, metadata, status data, and configuration data. Among them, metadata is data that describes data. In the context of low-code page rendering, it contains information about the page itself, such as the name, description, creation time, author, etc. of the page. At the same time, it may also contain basic information about the business data involved in the page, such as the source and data type of the business data. It can help the low-code platform understand the basic information and business information of the page for correct display and processing; status data reflects the current state of the page or components within the page. For example, in an online shopping page, the number of items in the shopping cart, the user's login status, the progress of ongoing operations on the page (such as file upload progress, form submission progress), etc. These data are dynamic and will change with the user's operations or the state of the system. The page will be updated accordingly based on the changes in the status data to ensure that the information seen by the user is the latest; configuration data is mainly used to control the layout, style, and functions of components of the page. It includes the layout information of the page (such as the size and position of each part), the configuration of components (such as the color of buttons, the field types and validation rules of forms), and the user's personalized settings (such as the theme selected by the user, the font size). These data ensure that the page and components are presented as expected by the user or developer and can work properly to provide the required functions.
[0087] Step 106: Perform page rendering based on the target HTML of the target low-code page and the data required for rendering of the target low-code page to obtain a preliminary rendered page.
[0088] In the embodiments of the present disclosure, after the server sends the target HTML of the target low-code page and the data required for rendering to the client, the client first performs page rendering to obtain and display a preliminary rendered page. The process of page rendering includes using the target HTML as the basic structural framework of the page, and at the same time combining the data required for rendering (such as the metadata, status data, configuration data, etc. mentioned above) to fill the page content, set the page layout and style, and implement the initial display of components.
[0089] Step 108: Perform hydration processing on the preliminary rendered page to obtain the target rendered page corresponding to the target low-code page.
[0090] Hydration processing is a process of converting a static preliminary rendered page into an interactive dynamic page, enabling it to have the functions of a complete target sub-application. In the embodiments of the present disclosure, no excessive description is made on hydration processing.
[0091] In the embodiments of the present disclosure, in the low-code platform, the preliminary rendered page only displays static content according to the data provided by the server, but lacks interactivity and some dynamic characteristics of the client. The hydration process injects JavaScript code into the preliminary rendered page to add event handlers, data bindings, and other interactive functions of the client to the page, transforming the page from a static page into a fully functional dynamic page, thereby obtaining the target rendered page corresponding to the target low-code page.
[0092] The rendering method of the low-code page provided by the embodiments of the present disclosure is such that the low-code platform can send a page loading request to the server in response to a low-code page loading operation for a target sub-application, and receive the sub-application data fed back by the server in response to the page loading request. The sub-application data includes the target HyperText Markup Language (HTML) of the target low-code page and the data required for rendering the target low-code page, where the target HTML is generated by the server through a pre-rendering strategy and the target low-code page. The low-code platform can perform page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page, and perform hydration processing on the preliminary rendered page to obtain the target rendered page corresponding to the target low-code page. By adopting the rendering method of the low-code page provided by the embodiments of the present disclosure, part of the rendering work of the low-code page is preposed to the server side. The pre-rendering completed in advance on the server side will generate the target HTML. When the user requests a page, the low-code platform no longer needs to perform page rendering from scratch, but can quickly use the existing pre-rendering results, thus greatly shortening the page loading time and providing a more smooth and fast page access experience for users. Moreover, since part of the page content has been pre-rendered in advance, the user will not see a blank page when opening the page (i.e., the phenomenon of a white screen on the home page is avoided), that is, the rendering efficiency of the low-code page can be significantly improved, and the problem of a possible white screen on the home page can be effectively solved.
[0093] In an exemplary embodiment, referring to Figure 2 as shown, in step 106, performing page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page may include steps 202 to 206, where:
[0094] Step 202, parsing the sub-application data;
[0095] Step 204, if a Document Object Model (DOM) node reuse identifier is parsed from the sub-application data, obtaining the target HTML from the sub-application data, and performing DOM node reuse processing based on the target HTML to obtain a target DOM structure;
[0096] Step 206, performing page rendering according to the target DOM structure and the data required for rendering the target low-code page to obtain a preliminary rendered page.
[0097] In the embodiments of the present disclosure, during the process of page pre-rendering on the server side, a special identifier, that is, a DOM node reuse identifier, can be added to the pre-rendered hydration fragment in advance. The DOM node reuse identifier is a special mark or information, and this identifier indicates that during the page rendering process, DOM nodes can be reused to improve performance and reduce resource waste.
[0098] After the client obtains the sub-application data, it can parse the sub-application data. If the DOM node reuse identifier is obtained through parsing, the target HTML is extracted from the sub-application data, and then DOM node reuse processing is performed based on this target HTML to obtain the target DOM structure. Further, the target DOM structure is further rendered in combination with the data required for rendering the target low-code page (such as metadata, status data, configuration data, etc. of the target sub-application), including setting the styles, content, and interactive functions of the elements, and finally the preliminary rendered page is obtained.
[0099] Such a process can optimize the rendering performance of the page. By reusing DOM nodes, some unnecessary creation and destruction operations are avoided. At the same time, combining the data required for rendering ensures that the page has the required appearance and functions, which can improve the rendering efficiency and resource utilization rate.
[0100] In an exemplary embodiment, referring to Figure 3 As shown, in step 204, performing DOM node reuse processing based on the target HTML to obtain the target DOM structure may include the following steps 302 to 306, where:
[0101] Step 302, find and determine the mounting container of the target sub-application from the target HTML;
[0102] Step 304, extract the first sub-element from the mounting container as the DOM node to be reused, store the attribute content of the target attribute in the DOM node to be reused, and then clear the target attribute in the DOM node to be reused;
[0103] Step 306, create a shadow DOM according to the sub-application data, and add the shadow DOM to the target attribute of the DOM node to be reused to obtain the target DOM structure.
[0104] In the embodiments of the present disclosure, in the target HTML, first, the mounting container of the target sub-application needs to be found. This mounting container is the container element of the target sub-application in the page, and it will carry the content of the sub-application. Among the found mounting containers, the first sub-element is used to indicate the DOM node to be reused. Therefore, the first sub-element in the mounting container can be extracted as the DOM node to be reused. This DOM node to be reused is a DOM node of the DOM structure, which may include reusable structures or information. In fact, other sub-elements in the mounting container can also be specified as the DOM node to be reused, and the embodiments of the present disclosure do not make too many limitations on this.
[0105] For the target attributes in the DOM nodes to be reused, their attribute contents (the contents shown previously) can be stored first. The target attributes here can be the innerHTML attribute, etc. After storing the attribute contents, the contents of the target attributes in the DOM nodes to be reused can be cleared. Then, a Shadow DOM can be created. The Shadow DOM is an encapsulated and isolated DOM structure that allows styles and markup to be separated from the rest of the main document, avoiding style and script conflicts. After adding content to the Shadow DOM according to the sub-application data, the Shadow DOM is added to the target attributes of the DOM nodes to be reused, finally obtaining the target DOM structure.
[0106] Exemplarily, in a low-code platform built with the micro-frontend architecture A, the process of obtaining the target DOM structure by performing DOM node reuse processing based on the target HTML can be implemented using the following code logic:
[0107]
[0108]
[0109] That is, the function receives five parameters: containerElement (an HTML element, the mounting container of the target sub-application), strictStyleIsolation (a boolean value indicating whether to use strict style isolation), scopedCSS (a boolean value, perhaps indicating whether to use scoped CSS), appName (a string, the name of the sub-application), and appContent (a string, the content of the sub-application). Further, the first child element of containerElement can be obtained and cast to the HTMLElement type as the DOM node to be reused (appElement).
[0110] Check whether ShadowDOM is supported. If not, print a warning message prompting the user that the strict style isolation configuration will be ignored. If supported, create a Shadow DOM, including: if appElement supports the attachShadow method, create an open-mode ShadowRoot instance using the attachShadow method. Otherwise, use the createShadowRoot method to create a ShadowRoot. After clearing the content in innerHTML, add content to the ShadowRoot based on the sub-application data and add the ShadowRoot to innerHTML, thus achieving the reuse of DOM nodes and obtaining the target DOM structure.
[0111] In this way, the reuse of DOM nodes is achieved. During the page rendering process on the client side, there is no need to repeatedly generate new DOM nodes. Based on the existing DOM structure and Shadow DOM, the page can be rendered, which can improve the page rendering efficiency.
[0112] In an exemplary embodiment, referring to Figure 4 as shown, in step 106, based on the target HTML of the target low-code page and the data required for rendering the target low-code page, page rendering is performed to obtain a preliminary rendered page, and the following steps 402 to 404 are further included, where:
[0113] Step 402, if the DOM node reuse identifier is not parsed from the sub-application data, create the target DOM structure of the target low-code page;
[0114] Step 404, perform page rendering according to the target DOM structure and the sub-application data to obtain a preliminary rendered page.
[0115] In the embodiments of the present disclosure, if the DOM node reuse identifier is not parsed from the sub-application data, the creation of DOM nodes can be performed to obtain the target DOM structure of the target low-code page. Exemplarily, a new DOM structure can be generated according to the template, configuration information of the page or the user's custom settings. For example: assuming that subAppData is the sub-application data obtained from the server, in the case where the DOM node reuse identifier is not included in subAppData, a new div element can be created using document.createElement('div') as the container of the target DOM structure. The HTML template in subAppData is added to this container through the innerHTML property to create a target DOM structure, and then according to the configuration information in subAppData, styles are set for the elements in the target DOM structure, such as setting the color and font size, etc. Finally, based on the target DOM structure, a preliminary rendered page can be rendered.
[0116] Exemplarily, still taking the foregoing example as an example, performing page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page can be implemented through the following code logic:
[0117]
[0118]
[0119] Among them, LoadApp is an asynchronous function that receives three parameters and is mainly used to load an application. During the implementation of LoadApp, if the sub-application data has the forceReusedPortalNode property (DOM node reuse identifier), the normalizeSsrWrapperElement function is used to process the sub-application data to achieve the reuse of DOM nodes; if the sub-application data does not have the forceReusedPortalNode property (DOM node reuse identifier), the createElement is used again to create the target DOM structure.
[0120] In the rendering stage of the micro-frontend architecture, new DOM nodes are generated each time. In this way, the pre-rendered HTML fragments in the target HTML sent by the server will be replaced, resulting in the inability to correctly hydrate the pre-rendered content, making the pre-rendered work pre-generated by the server in vain, and resulting in the problem of the first-screen white screen still existing. In the embodiments of the present disclosure, by improving the rendering stage and indicating DOM node reuse through the DOM node reuse identifier, new DOM nodes are no longer generated each time. Therefore, the pre-rendered hydration fragments sent by the server can be utilized, which can effectively improve the rendering efficiency of the low-code page and solve the problem of the first-screen white screen.
[0121] Figure 5 It is a flowchart of a rendering method for a low-code page shown according to an exemplary embodiment. In this embodiment, the method is exemplified by being applied to a server. In this embodiment, the method includes the following steps 502 to step 506, where:
[0122] Step 502, receiving a page loading request sent by the client for the target sub-application;
[0123] Step 504, in response to the page loading request, obtaining the target hypertext markup language HTML of the target low-code page and the data required for rendering the target low-code page, where the target HTML is generated by the server through a pre-rendering strategy and the target low-code page;
[0124] Step 506, sending the target HTML of the target low-code page and the data required for rendering the target low-code page as sub-application data to the client, so that the client renders the page based on the sub-application data.
[0125] In the embodiments of the present disclosure, the process of sending a page loading request may refer to the relevant descriptions in the foregoing embodiments, and will not be elaborated herein. After receiving the page loading request, the server will obtain the target HTML of the target low-code page according to the information in the request. The target HTML is obtained by pre-rendering the target low-code page using a pre-rendering strategy. The pre-rendering strategy usually renders the page content into HTML format in advance on the server side, which can improve the page loading speed, enhance the user experience, and contribute to Search Engine Optimization (SEO). For example, the server can use a pre-rendering engine to generate the low-code page into HTML format based on the page template, configuration information, and data stored in the database.
[0126] In addition to the target HTML, the server will also obtain the data required for rendering the target low-code page, including but not limited to: metadata (such as information like the title, description, author, etc. of the page, providing basic information for the page), status data (such as the current state of the page, like the initial values of forms, the user's login status, the initial states of components, etc.), configuration data (including the layout, style, and configuration information of components of the page, determining the appearance and functions of the page), etc. The description of the data required for rendering may refer to the relevant descriptions in the foregoing embodiments, and will not be elaborated herein.
[0127] The server combines the target HTML and the data required for rendering and sends them to the client as sub-application data. This process can use common network protocols such as HTTP or HTTPS. The server will encapsulate the sub-application data in the response message, and the client will receive and parse the message for page rendering. The rendering process may refer to the relevant descriptions in the foregoing embodiments, and will not be elaborated herein.
[0128] By adopting the rendering method of the low-code page provided in the embodiments of the present disclosure, part of the rendering work of the low-code page is preposed to the server side. The pre-rendering completed in advance on the server side will generate the target HTML. When the user requests a page, the low-code platform no longer needs to start page rendering from scratch, but can quickly use the existing pre-rendered results, thus greatly shortening the page loading time and providing a more smooth and fast page access experience for users. Moreover, since part of the page content has been pre-rendered in advance, the user will not see a blank page when opening the page (i.e., avoiding the phenomenon of a white screen on the home page), that is, it can significantly improve the rendering efficiency of the low-code page and effectively solve the possible problem of a white screen on the home page.
[0129] In an exemplary embodiment, refer to Figure 6As shown, obtaining the target HTML of the target low-code page in step 504 may include the following steps 602 to 604, where:
[0130] Step 602, obtain the pre-rendered hydration fragments corresponding to the target sub-application from at least one storage source;
[0131] Step 604, perform a splicing operation on the obtained pre-rendered hydration fragments using a dehydration template to obtain the target HTML of the target low-code page.
[0132] In the embodiments of the present disclosure, the pre-rendered hydration fragments are page fragments pre-rendered on the server side for the low-code pages of the target sub-application. These fragments contain part of the content and structure of the low-code page and are an important part of constructing the final page. The pre-rendered hydration fragments may be HTML code fragments or complex objects including HTML and other related data. A low-code platform may store the pre-rendered data of different sub-applications in different storage sources, or store the pre-rendered data of the same sub-application in different storage sources to achieve data separation and management. Therefore, the pre-rendered hydration fragments of the target sub-application can be obtained from at least one storage source (such as the database radis, the file system file, the Content Delivery Network (CDN)).
[0133] The dehydration template is a template that can combine multiple pre-rendered hydration fragments to form a complete HTML page, that is, the target HTML. It may contain placeholders or specific structures for determining how to splice different fragments together. For example, a dehydration template may have placeholders such as {{header}}, {{content}}, {{footer}} for inserting the corresponding pre-rendered hydration fragments. Using the dehydration template to splice the obtained pre-rendered hydration fragments together, the target HTML of the target low-code page is finally obtained. In this way, the page generation efficiency can be improved because pre-rendered fragments are used, reducing the rendering work on the server side during page requests, and through the use of templates, different fragments can be flexibly combined to meet the needs of different pages.
[0134] In an exemplary embodiment, referring to Figure 7 As shown, the above method may further include steps 702 to 704, where:
[0135] Step 702, simulate a browser environment, and perform page pre-rendering on the page of the target sub-application in the browser environment to obtain the pre-rendered hydration fragments of the target sub-application;
[0136] Step 704, store the pre-rendered hydration fragments of the target sub-application into at least one storage source.
[0137] Using the micro-frontend low-code runtime architecture, Amis is selected for the low-code underlying layer. The rendering process of the Amis page highly depends on browser Window, DOM (Document Object Model), and BOM (Browser Object Model) objects. However, in the node build environment, there are no browser Window, DOM (Document Object Model), and BOM (Browser Object Model) objects necessary for the Amis page rendering, resulting in the inability of the Amis rendering code to run properly, that is, the pre-rendering operation of the low-code page cannot be achieved.
[0138] In the embodiments of the present disclosure, some tools and libraries can be used, such as Puppeteer (a Node.js library) or JSDOM (a DOM and HTML parser for JavaScript), to simulate some or all functions of the browser, so as to be able to perform the rendering operation of the low-code page on the server side. Page pre-rendering is to render the page into the HTML format that the end user sees in advance on the server side before the low-code page is actually requested by the user.
[0139] Exemplarily, taking Puppeteer as an example. First, start a simulated browser instance and navigate to the page URL of the target sub-application. Wait for a certain element on the page to load completely to ensure that the page is fully rendered. Obtain the rendered page as the pre-rendered hydration fragment of the target sub-application. The pre-rendered hydration fragments can be stored in one or more storage sources for subsequent use. The storage source can be in various forms, commonly including databases, file systems, Content Delivery Networks (CDNs), object storage (such as AWS S3), or in-memory caches (such as Redis). The embodiments of the present disclosure do not make specific limitations on this. Storing the pre-rendered hydration fragments can bring multiple benefits, such as improving the performance and scalability of page loading. When the user requests a page, the pre-rendered page content can be directly obtained from the storage source instead of re-rendering each time, saving the server's computing resources and the user's waiting time.
[0140] In an exemplary embodiment, Puppeteer can be deployed in a container cloud environment. Puppeteer has many dependencies, including but not limited to the Chromium browser and its related libraries. When deploying Puppeteer in a container, it is necessary to ensure that these dependencies are correctly installed. This involves adding installation commands during the container image building process to ensure the normal operation of Puppeteer. For example, when using a Dockerfile, it may be necessary to use npm install puppeteer to install Puppeteer, and at the same time, some system-level dependencies may need to be installed to support the operation of Chromium.
[0141] Container cloud is a cloud computing service that uses container technologies (such as Docker) to deploy and manage applications. In this container cloud environment, the underlying CentOS operating system can be used. CentOS is a Linux-based operating system that provides a running environment for applications in containers. Puppeteer is a powerful Node.js library that depends on multiple system-level and Node.js-level libraries. If the container cloud environment uses the CentOS system, the library addresses that Puppeteer depends on can be found in CentOS, which can ensure that errors do not occur due to the lack of certain libraries when running Puppeteer. The search process can include: for system-level dependencies, the yum command (the package manager of CentOS) can usually be used to search. For example, using yum search <library_name> can search for the required system libraries. For Node.js-level dependencies, the npm package manager can be used to find the Node.js dependencies of Puppeteer. For example, using npm view puppeteer dependencies can view the direct Node.js dependencies of Puppeteer. For a specific version of Puppeteer, using npm view puppeteer@ <version>Dependencies. This can help confirm whether the Node.js dependencies of Puppeteer are correctly installed and their version information to ensure compatibility with Puppeteer.
[0142] The platform provides a Puppeteer base image based on node16, which already includes some key components. For example: Node 16: Provides a Node.js runtime environment to ensure that Puppeteer runs under the Node 16 version. Puppeteer dependency packages such as chrome-linux: Include the Linux version of Chrome or Chromium browsers required for Puppeteer to run, as well as other necessary dependency packages, enabling Puppeteer to operate the browser for automated tasks. A Dockerfile that meets the business scenario can be built. A Dockerfile is a text file containing a series of commands for automatically creating a Docker image. Building a Dockerfile that meets the business scenario means customizing the image creation process according to specific business requirements and the usage of Puppeteer. Once the Dockerfile is created, the docker build command can be used to build a Docker image based on this file, providing a convenient and consistent environment for the deployment and operation of the application.
[0143] When using Puppeteer, it may take a long time to install Puppeteer. This may be because Puppeteer needs to install the Chromium browser and its numerous dependencies, and the download and installation of these dependencies may be affected by factors such as network speed and server resources, resulting in a slowdown of the entire installation process and thus extending the execution time of the pipeline. At least one of the following methods 1 to 3 can be used to solve this problem:
[0144] Method 1: Use Puppeteer-Core instead. Puppeteer-Core is a variant of Puppeteer that allows the use of its own Chrome or Chromium instance instead of the version downloaded and installed by Puppeteer by default. This means that the browser already installed in the system can be used, avoiding the steps of downloading and installing the browser during Puppeteer installation, thus saving time.
[0145] Method 2: Use the pipeline node_modules cache. Utilize the cache function of the pipeline to cache the node_modules directory. In this way, during subsequent pipeline executions, if the dependencies have not changed, the cached node_modules can be directly used, avoiding repeated downloads and installations, thus saving time.
[0146] Method 3: Install using the built-in Puppeteer in the pipeline. Some pipeline platforms may provide built-in Puppeteer services or functions. These built-in Puppeteers may have been optimized or pre-configured and can be directly used, avoiding the trouble and time-consuming process of manual installation.
[0147] Puppeteer is a powerful tool that can precisely control browsers such as Chrome or Chromium through the DevTools protocol. It can efficiently simulate various operations of users in the browser, providing reliable solutions for tasks such as web automation testing, data scraping, and page screenshotting. It allows controlling Chromium or Chrome browsers using Node.js. By creating a browser instance with Puppeteer, various operations of users in the browser can be simulated, such as opening pages, executing scripts, taking page screenshots, generating PDFs, etc. In Puppeteer, puppeteer.launch() is a method used to launch a browser instance. In the puppeteer.launch() method, an object can be passed as a parameter. This object contains some configuration options, such as args, which is an array used to set the command-line arguments when launching the browser. These parameters can be adjusted according to specific requirements. Different parameters will affect the running state and performance of the browser, and it is necessary to decide whether to enable them according to the specific situation.
[0148] Pre-rendered hydration fragments are usually part or all of the content of a page, which are obtained after server-side rendering. Using Puppeteer, the HTML content of the target low-code page can be accessed to obtain the hydration fragment. Exemplarily, first use page.goto('http: / / example.com') to navigate to the low-code page, and then use the page.content() method to obtain the HTML content of the low-code page and store it in the hydrateFragment variable. This content is the pre-rendered hydration fragment.
[0149] In the embodiments of the present disclosure, during the process of generating pre-rendered hydration fragments, the task can be processed in parallel by multiple instances of the container cloud to improve the generation efficiency of the pre-rendered hydration fragments. In this process, a task queue can be used to orchestrate the tasks of generating pre-rendered hydration fragments, ensuring the orderliness and manageability of the pre-rendered hydration fragment tasks, while solving the competition problem of multiple instances and avoiding resource waste. A task queue is a data structure used to manage and schedule tasks. By putting the tasks of generating pre-rendered hydration fragments into the queue, the orderly execution of tasks can be achieved. For example, using a Redis queue, RabbitMQ, or other message queue systems, the tasks of generating pre-rendered hydration fragments can be stored in the queue and processed according to the First Input First Output (FIFO) or other rules, which can improve the parallel processing efficiency of tasks and the generation efficiency of pre-rendered hydration fragments.
[0150] When using multiple instances of the container cloud, multiple instances may simultaneously obtain the tasks of generating pre-rendered hydration fragments from the task queue, which may lead to competition and preemption. Multiple instances may attempt to process the same task of generating pre-rendered hydration fragments, resulting in resource waste and inconsistent results. A distributed lock (such as a Redis lock) can be used to ensure that only one instance can obtain and process the tasks of generating pre-rendered hydration fragments from the task queue at the same time, avoiding multiple instances processing the same task of generating pre-rendered hydration fragments simultaneously. Polling, weighted polling, or other task allocation algorithms can be adopted to reasonably allocate the tasks of generating pre-rendered hydration fragments to different container instances, ensuring the uniform distribution and efficient processing of the tasks of generating pre-rendered hydration fragments.
[0151] Furthermore, a task priority function can be added to ensure that important tasks of generating pre-rendered hydration fragments are processed first, improving the response ability of the system. Different tasks of generating pre-rendered hydration fragments can be set with different priorities. For example, the task of generating the home page may be more important or urgent than the tasks of other pages, enabling high-priority tasks to be processed first, improving the response speed of the system and the rationality of resource allocation. Exemplarily, in the task queue, a priority attribute can be added to each task. When scheduling tasks, tasks with higher priorities are processed first. For example, using the sorted set of Redis to store tasks and sorting and scheduling according to priorities.
[0152] The embodiments of the present disclosure can also set an error attempt and exception discard mechanism to ensure the stability of the system and the effective utilization of resources. During the process of generating pre-rendered hydration fragments, errors may occur, such as page rendering errors, data acquisition errors, etc. An error attempt mechanism can be set to allow the task to retry a certain number of times when it fails. When the task still fails after multiple attempts, it may need to be discarded to avoid continuously occupying resources. A maximum number of attempts can be set. After exceeding this number of times, the task is marked as failed or removed from the task queue.
[0153] In this way, in the embodiments of the present disclosure, pre-rendering the low-code page by simulating the browser environment through Puppeteer can effectively solve the problem that the Window / Dom / Bom objects required for rendering the low-code page in the node construction environment cannot be smoothed out.
[0154] To enable those skilled in the art to better understand the disclosed embodiments, the disclosed embodiments are described below through specific examples.
[0155] Referring to Figure 8 As shown, the low-code platform can use an independent Puppeteer service on the server side to asynchronously pre-generate pre-rendered hydration fragments. When the client requests the page data of the sub-application, the main rendering service can obtain the pre-rendered hydration fragments from the storage source, splice the pre-rendered hydration fragments based on the dehydrated template to obtain dehydrated HTML. After obtaining the data required for page rendering of the sub-application, the dehydrated HTML and the data required for page rendering ( Figure 8 shown as datajson in the figure) are fed back to the client. The client renders the page based on the dehydrated HTML and the data required for rendering to obtain a preliminary rendered page. After hydrating the preliminary rendered page, the target rendered page can be obtained.
[0156] Referring to Figure 9 and Figure 10 As shown, in the embodiments of the present disclosure, the static assets and Schema data required for page rendering can be sent in the first interface in the CSR stage, that is, in the first request, the data required for page rendering is returned. The rendering of the base and micro-applications does not require additional acquisition, and the acquisition process of single data rendering can be skipped; after the front end obtains the Schema and the dehydrated HTML sent by the Server, hydrating processing is performed to reduce secondary rendering. And data caching technology can be used to store the data that is frequently read (for example: data (application information, environment, configuration, etc.)) in a cache layer with fast access, and backfill it when the user accesses the server to assemble the template data, ensuring the fast assembly of data, thereby reducing the frequent read requests to the database and improving the data access speed and response time; an independent Puppeteer service can be adopted to batch generate the hydration fragments of the corresponding pages, ensuring the generation efficiency, and at the same time, simulating the real browser environment through puppteer to solve the runtime environment required for amis rendering.
[0157] At the same time, the mounting method of the sub-application is adjusted so that relevant DOM nodes can be reused each time the micro-application is rendered, effectively utilizing the dehydrated HTML pre-rendered by the server, which can greatly improve the rendering efficiency of the low-code page.
[0158] In one example, take the A framework adopting the micro-frontend architecture as an example. The server side can use the Puppeteer headless browser to simulate the browser environment, generate a pre-rendered page in the Puppeteer environment, store the pre-rendered fragments in Redis, and synchronize the data to the CDN and the file system at the same time.
[0159] The following operations are performed on the server side:
[0160] When the server receives the first access request from the client for a certain sub-application, it will obtain the pre-rendered hydration fragments corresponding to the sub-application from multiple storage sources (such as Redis, CDN, or the file system). These pre-rendered hydration fragments are static HTML content generated by tools such as Puppeteer and have the potential to be transformed into a dynamic and interactive page.
[0161] The server uses the dehydration template to splice the obtained pre-rendered hydration fragments. The dehydration template provides a suitable DOM structure framework for the HTML content of the sub-application and embeds the pre-rendered hydration fragments into it to form the dehydrated HTML of the target page.
[0162] The server prepares the data (dataJson) required for rendering the target page, which contains various data required by the sub-application. In the hydration fragments generated by pre-rendering, add the identifier app.forceReusedPortalNode to indicate whether the client should force the reuse of DOM nodes. The server sends the spliced dehydrated HTML and dataJson to the client as sub-application data.
[0163] The following operations are performed on the client side:
[0164] After the client receives the data sent by the server, it parses the information in it. If the identifier app.forceReusedPortalNode is found, DOM node reuse operations are performed; otherwise, DOM node creation operations are executed.
[0165] The process of DOM node reuse includes: finding and determining the mounting container (containerElement) of the sub-application, extracting its first child element as the DOM node to be reused (appElement). Store the existing innerHTML, and then clear the innerHTML of appElement to prepare for creating a new ShadowDOM. Create and add the ShadowDOM to the innerHTML of appElement to wrap the sub-application content, achieving style isolation while reusing the original DOM node structure.
[0166] The client renders the sub-application page based on the existing DOM structure and Shadow DOM content, displays it on the client, responds to user operations, and completes the conversion from static content to a dynamic interactive page. Finally, ReactDOM.hydrate is used to hydrate the rendered static content and components to complete the combination of static and dynamic content on the page.
[0167] It should be understood that although Figures 1 - 10 the steps in the flowchart are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise clearly stated in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, Figures 1 - 10 at least a part of the steps in
[0168] It should be understood that the same / similar parts among the various embodiments of the above methods in this specification can be referred to each other. Each embodiment focuses on the differences from other embodiments. For the related parts, refer to the descriptions of other method embodiments.
[0169] Figure 11 FIG. 1100 is a block diagram of a rendering device for a low-code page shown according to an exemplary embodiment. Referring to Figure 11 FIG. 1100, the device includes a sending unit 1102, a receiving unit 1104, a rendering unit 1106, and a hydration unit 1108, where:
[0170] The sending unit 1102 is configured to send a page loading request to the server, and the page loading request is used to load the low-code page of the target sub-application;
[0171] The receiving unit 1104 is configured to receive the sub-application data fed back by the server in response to the page loading request. The sub-application data includes the target hypertext markup language (HTML) of the target low-code page and the data required for rendering the target low-code page. The target HTML is generated by the server through a prerendering strategy and the target low-code page;
[0172] The rendering unit 1106 is configured to perform page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page;
[0173] The hydration unit 1108 is configured to perform hydration processing on the preliminary rendered page to obtain a target rendered page corresponding to the target low-code page.
[0174] By using the rendering device for low-code pages provided by the embodiments of the present disclosure, part of the rendering work of the low-code page is advanced to the server side. The pre-rendering completed in advance on the server side will generate the target HTML. When the user requests a page, the low-code platform no longer needs to start page rendering from scratch, but can quickly use the existing pre-rendering results, thereby greatly shortening the page loading time and providing a more smooth and fast page access experience for users. Moreover, since part of the page content has been pre-rendered in advance, when the user opens the page, they will not see a blank page (i.e., the phenomenon of the first page being white is avoided), that is, it can significantly improve the rendering efficiency of the low-code page and effectively solve the possible problem of the first page being white.
[0175] In one embodiment, the rendering unit 1106 is specifically configured to perform:
[0176] Parse the sub-application data;
[0177] If a Document Object Model (DOM) node reuse identifier is parsed from the sub-application data, obtain the target HTML from the sub-application data, and perform DOM node reuse processing based on the target HTML to obtain a target DOM structure;
[0178] Perform page rendering according to the target DOM structure and the data required for rendering the target low-code page to obtain a preliminary rendered page.
[0179] In one embodiment, the rendering unit 1106 is further specifically configured to perform:
[0180] If a DOM node reuse identifier is not parsed from the sub-application data, create a target DOM structure for the target low-code page;
[0181] Perform page rendering according to the target DOM structure and the sub-application data to obtain a preliminary rendered page.
[0182] In one embodiment, the rendering unit 1106 is specifically configured to perform:
[0183] Find and determine the mounting container of the target sub-application from the target HTML;
[0184] Extract the first sub-element from the mounting container as the DOM node to be reused, store the attribute content of the target attribute in the DOM node to be reused, and then clear the target attribute in the DOM node to be reused;
[0185] Create a shadow DOM according to the sub - application data, and add the shadow DOM to a target attribute of the DOM node to be reused, obtaining a target DOM structure.
[0186] Figure 12 FIG. 1200 is a block diagram of a rendering device for a low - code page shown according to an exemplary embodiment. Refer to Figure 12 The device includes a receiving unit 1202, an obtaining unit 1204, and a sending unit 1206, where:
[0187] The receiving unit 1202 is configured to receive a page loading request sent by a client for a target sub - application;
[0188] The obtaining unit 1204 is configured to, in response to the page loading request, obtain the target HyperText Markup Language (HTML) of the target low - code page and data required for rendering the target low - code page, where the target HTML is generated by the server through a prerendering strategy and the target low - code page;
[0189] The sending unit 1206 is configured to send the target HTML of the target low - code page and the data required for rendering the target low - code page as sub - application data to the client, so that the client performs page rendering based on the sub - application data.
[0190] By using the rendering device for a low - code page provided in the embodiments of the present disclosure, part of the rendering work of the low - code page is pre - placed on the server side. The prerendering pre - completed on the server side will generate the target HTML. When a user requests a page, the low - code platform no longer needs to perform page rendering from scratch, but can quickly use the existing prerendering results, thus greatly shortening the page loading time and providing a more fluent and fast page access experience for users. Moreover, since part of the page content has been pre - rendered in advance, when the user opens the page, they will not see a blank page (i.e., the phenomenon of a white screen on the home page is avoided), that is, the rendering efficiency of the low - code page can be significantly improved, and the problem of a white screen on the home page that may occur can be effectively solved.
[0191] In one embodiment, the obtaining unit 1204 is specifically configured to perform:
[0192] Obtain a prerendered hydration fragment corresponding to the target sub - application from at least one storage source;
[0193] Perform a splicing operation on the obtained prerendered hydration fragment using a dehydrated template to obtain the target HTML of the target low - code page.
[0194] In one embodiment, the device further includes:
[0195] A pre-rendering unit configured to execute a simulated browser environment, in which a page of a target sub-application is pre-rendered to obtain a pre-rendered hydration fragment of the target sub-application;
[0196] A storage unit configured to store the pre-rendered hydration fragment of the target sub-application into at least one storage source.
[0197] Figure 13 It is a block diagram of an electronic device 1300 for a rendering method of a low-code page shown according to an exemplary embodiment. For example, the electronic device 1300 can be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.
[0198] Refer to Figure 13 , the electronic device 1300 may include one or more of the following components: a processing component 1302, a memory 1304, a power supply component 1306, a multimedia component 1308, an audio component 1310, an input / output (I / O) interface 1312, a sensor component 1314, and a communication component 1316.
[0199] The processing component 1302 generally controls the overall operation of the electronic device 1300, such as operations associated with display, telephone calls, data communication, camera operations, and recording operations. The processing component 1302 may include one or more processors 1320 to execute instructions to complete all or part of the steps of the above method. In addition, the processing component 1302 may include one or more modules to facilitate the interaction between the processing component 1302 and other components. For example, the processing component 1302 may include a multimedia module to facilitate the interaction between the multimedia component 1308 and the processing component 1302.
[0200] The memory 1304 is configured to store various types of data to support the operation of the electronic device 1300. Examples of such data include instructions for any application or method operating on the electronic device 1300, contact data, phone book data, messages, pictures, videos, etc. The memory 1304 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disks, optical disks, or graphene memory.
[0201] The power supply component 1306 provides power for various components of the electronic device 1300. The power supply component 1306 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the electronic device 1300.
[0202] The multimedia component 1308 includes a screen that provides an output interface between the electronic device 1300 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors can not only sense the boundaries of touch or swipe actions, but also detect the duration and pressure associated with the touch or swipe operations. In some embodiments, the multimedia component 1308 includes a front camera and / or a rear camera. When the electronic device 1300 is in an operating mode, such as a shooting mode or a video mode, the front camera and / or the rear camera can receive external multimedia data. Each of the front camera and the rear camera can be a fixed optical lens system or have a focal length and optical zoom capabilities.
[0203] The audio component 1310 is configured to output and / or input audio signals. For example, the audio component 1310 includes a microphone (MIC) that is configured to receive external audio signals when the electronic device 1300 is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals can be further stored in the memory 1304 or transmitted via the communication component 1316. In some embodiments, the audio component 1310 further includes a speaker for outputting audio signals.
[0204] The I / O interface 1312 provides an interface between the processing component 1302 and a peripheral interface module, and the peripheral interface module can be a keyboard, a click wheel, buttons, etc. These buttons can include, but are not limited to: a home button, a volume button, a power-on button, and a lock button.
[0205] The sensor assembly 1314 includes one or more sensors for providing status assessment of various aspects for the electronic device 1300. For example, the sensor assembly 1314 can detect the on / off state of the electronic device 1300, the relative positioning of components, such as components for the display and keypad of the electronic device 1300. The sensor assembly 1314 can also detect changes in the position of the electronic device 1300 or components of the electronic device 1300, the presence or absence of user contact with the electronic device 1300, the orientation or acceleration / deceleration of the device 1300, and changes in the temperature of the electronic device 1300. The sensor assembly 1314 can include a proximity sensor configured to detect the presence of nearby objects without any physical contact. The sensor assembly 1314 can also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor assembly 1314 can further include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.
[0206] The communication component 1316 is configured to facilitate communication between the electronic device 1300 and other devices in a wired or wireless manner. The electronic device 1300 can access a wireless network based on communication standards, such as WiFi, carrier networks (such as 2G, 6G, 4G, or 5G), or a combination thereof. In an exemplary embodiment, the communication component 1316 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 1316 further includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.
[0207] In an exemplary embodiment, the electronic device 1300 can be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components for performing the above-described methods.
[0208] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1304 including instructions that can be executed by a processor 1320 of the electronic device 1300 to complete the above-described methods. For example, the computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device, etc.
[0209] In an exemplary embodiment, a computer program product is further provided. The computer program product includes instructions that can be executed by the processor 1320 of the electronic device 1300 to implement the above method.
[0210] It should be noted that the above-mentioned devices, electronic devices, computer-readable storage media, computer program products, etc. may also include other implementation manners according to the description of the method embodiments. The specific implementation manners may refer to the description of the relevant method embodiments and will not be elaborated here one by one.
[0211] Those skilled in the art will readily conceive of other embodiments of the present disclosure after considering the specification and practicing the invention disclosed herein. The present disclosure is intended to cover any variations, uses, or adaptations of the present disclosure that follow the general principles of the present disclosure and include common general knowledge or conventional technical means in the technical field not disclosed herein. The specification and embodiments are only to be considered as exemplary, and the true scope and spirit of the present disclosure are pointed out by the claims.
[0212] It should be understood that the present disclosure is not limited to the exact structures described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present disclosure is only limited by the appended claims.< / version>
Claims
1. A rendering method for a low-code page, characterized in that, Including: Sending a page loading request to the server, where the page loading request is used to load the low-code page of the target sub-application; Receiving the sub-application data fed back by the server in response to the page loading request, where the sub-application data includes the target HyperText Markup Language (HTML) of the target low-code page and the data required for rendering the target low-code page, and the target HTML is generated by the server through a pre-rendering strategy and the target low-code page; Performing page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page; Performing hydration processing on the preliminary rendered page to obtain the target rendered page corresponding to the target low-code page.
2. The method according to claim 1, characterized in that The performing page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page includes: Parsing the sub-application data; If a Document Object Model (DOM) node reuse identifier is parsed from the sub-application data, obtaining the target HTML from the sub-application data and performing DOM node reuse processing based on the target HTML to obtain a target DOM structure; Performing page rendering according to the target DOM structure and the data required for rendering the target low-code page to obtain a preliminary rendered page.
3. The method according to claim 1, wherein The performing page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page further includes: If a DOM node reuse identifier is not parsed from the sub-application data, creating a target DOM structure of the target low-code page; Performing page rendering according to the target DOM structure and the sub-application data to obtain a preliminary rendered page.
4. The method according to claim 2, wherein The performing DOM node reuse processing based on the target HTML to obtain a target DOM structure includes: Searching for and determining the mounting container of the target sub-application from the target HTML; Extracting the first sub-element from the mounting container as the DOM node to be reused, storing the attribute content of the target attribute in the DOM node to be reused, and then clearing the target attribute in the DOM node to be reused; Creating a shadow DOM according to the sub-application data and adding the shadow DOM to the target attribute of the DOM node to be reused to obtain a target DOM structure.
5. A rendering method for a low-code page, characterized in that, Including: Receiving a page loading request sent by the client for the target sub-application; In response to the page loading request, obtaining the target HyperText Markup Language (HTML) of the target low-code page and the data required for rendering the target low-code page, where the target HTML is generated by the server through a pre-rendering strategy and the target low-code page; Taking the target HTML of the target low-code page and the data required for rendering the target low-code page as sub-application data and sending it to the client so that the client performs page rendering based on the sub-application data.
6. The method according to claim 5, wherein The obtaining the target HTML of the target low-code page includes: Obtain the pre-rendered hydration fragment corresponding to the target sub-application from at least one storage source; Perform a splicing operation on the obtained pre-rendered hydration fragment using a dehydration template to obtain the target HTML of the target low-code page.
7. The method according to claim 6, characterized in that, The method further includes: Simulate a browser environment, and perform page pre-rendering on the page of the target sub-application in the browser environment to obtain the pre-rendered hydration fragment of the target sub-application; Store the pre-rendered hydration fragment of the target sub-application in at least one storage source.
8. A rendering device for a low-code page, characterized in that, Includes: A sending unit configured to execute sending a page loading request to a server, where the page loading request is used to load a low-code page of a target sub-application; A receiving unit configured to execute receiving sub-application data fed back by the server in response to the page loading request, where the sub-application data includes the target hypertext markup language HTML of the target low-code page and data required for rendering the target low-code page, and the target HTML is generated by the server through a pre-rendering strategy and the target low-code page; A rendering unit configured to execute page rendering based on the target HTML of the target low-code page and the data required for rendering the target low-code page to obtain a preliminary rendered page; A hydration unit configured to execute hydration processing on the preliminary rendered page to obtain a target rendered page corresponding to the target low-code page.
9. A rendering device for a low-code page, characterized in that, Includes: A receiving unit configured to execute receiving a page loading request sent by a client for a target sub-application; An obtaining unit configured to execute, in response to the page loading request, obtaining the target hypertext markup language HTML of the target low-code page and data required for rendering the target low-code page, where the target HTML is generated by the server through a pre-rendering strategy and the target low-code page; A sending unit configured to execute sending the target HTML of the target low-code page and the data required for rendering the target low-code page as sub-application data to the client, so that the client performs page rendering based on the sub-application data.
10. An electronic device, characterized in that, Includes: A processor; A memory for storing executable instructions of the processor; Wherein, the processor is configured to execute the instructions to implement the rendering method of the low-code page according to any one of claims 1 to 4 or 5 to 7.
11. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the rendering method of the low-code page according to any one of claims 1 to 4 or 5 to 7.