Debugging verification method and device of component, computer device and storage medium

Abstract

Embodiments of the present application disclose a debugging verification method and device of a component, a computer device and a storage medium. The method comprises: in response to a debugging operation of a developer, obtaining a target component identifier, configuration parameters and a target device screen width of a target component to be verified; obtaining component source code of the target component according to the component identifier, and generating a target web page file based on the configuration parameters, the target device screen width and the component source code; generating a target build identifier based on the component identifier, the configuration parameters and the target device screen width, and storing the target web page file and the target build identifier in association in a cache; encoding an access address of the target web page file in the cache into an optically readable code and displaying the optically readable code; when a user terminal scans the optically readable code, sending the target web page file to the user terminal, so that the user terminal displays the target component based on the target web page file. The debugging verification efficiency of the component can be improved by the present application.

Description

Technical Field

[0001] This application relates to the field of development and debugging technology, and in particular to methods, apparatus, computer equipment and storage media for debugging and verifying components. Background Technology

[0002] In the front-end development of instant messaging (IM) applications, mobile applications, and complex web applications, the development and debugging of UI components, especially card-based dynamic components, is a typical and crucial step. These components (e.g., order cards, flight status cards, or recommended reading cards in instant messaging applications) are typically dynamically deployed by the server based on business logic.

[0003] During development and debugging, mobile device screens are usually simulated in desktop browsers using iframes or viewport scaling. However, the device simulation function of desktop browsers cannot reproduce the differences in font rendering engines of real mobile devices; cannot simulate the touch event response and scrolling behavior of real devices; and cannot reflect the rendering performance under the CPU / memory performance constraints of real devices.

[0004] It is evident that the rendering effect of the component can only be accurately verified in the browser of a real mobile device. The device simulation function of the desktop browser cannot reproduce the font rendering, touch interaction and performance of the real device.

[0005] However, if component debugging and verification are required on a real device, the entire application build process must be executed. Specifically, the entire application must be built, and the build artifacts must be deployed to a test server. Then, the components can be accessed via a browser on the mobile phone for debugging and verification. As can be seen, in the existing technology, component-level modifications require a full build and deployment of the application for real device verification, resulting in low efficiency for component debugging and verification. Summary of the Invention

[0006] This application provides a method, apparatus, computer device, and storage medium for debugging and verifying components, which can improve the efficiency of component debugging and verification.

[0007] In a first aspect, embodiments of this application provide a method for debugging and verifying a component, the method being applied to a developer platform, including: In response to the developer's debugging operation, obtain the target component identifier, configuration parameters, and target device screen width of the target component to be verified. The configuration parameters include the business data required for rendering the target component. The source code of the target component is obtained based on the target component identifier, and a target webpage file is generated based on the configuration parameters, the target device screen width, and the component source code. The target webpage file is associated with the target build identifier and stored in the cache. The target build identifier is generated based on the target component identifier, the configuration parameters, and the target device screen width. The access address of the target webpage file in the cache is encoded into an optically readable graphic code and displayed. When a user terminal scans the optically readable graphic code, the target webpage file is sent to the user terminal so that the user terminal can display the target component based on the target webpage file, and the user terminal can render and display the target component based on the target webpage file and according to the screen width of the target device.

[0008] Secondly, embodiments of this application also provide a component debugging and verification device, which is deployed on a developer platform and includes: The acquisition unit is used to respond to the developer's debugging operation and acquire the target component identifier, configuration parameters, and target device screen width of the target component to be verified. The configuration parameters include the business data required for rendering the target component. A webpage file generation unit is used to obtain the component source code of the target component according to the target component identifier, and generate a target webpage file based on the configuration parameters, the target device screen width, and the component source code; An identifier generation unit is used to associate the target webpage file with the target construction identifier and store it in a cache. The target construction identifier is generated based on the target component identifier, the configuration parameters, and the target device screen width. An encoding unit is used to encode the access address of the target webpage file in the cache into an optically readable graphic code and display it. The sending unit is configured to send the target webpage file to the user terminal when the user terminal scans the optically readable graphic code, so that the user terminal displays the target component based on the target webpage file, and renders and displays the target component based on the target webpage file and according to the screen width of the target device.

[0009] Thirdly, embodiments of this application also provide a computer device, which includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0010] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor, can implement the above-described method.

[0011] This application provides a method, apparatus, computer device, and storage medium for debugging and verifying components. The method is applied to a developer platform. This application automatically obtains component identifiers, configuration parameters, and device screen width in response to developer debugging operations, dynamically generates and caches independent web page files, and then achieves zero-input device connection via optical codes. This solves the efficiency bottleneck in existing technologies where component-level modifications require a full build and deployment for real-device verification, thus improving the efficiency of component debugging and verification. Attached Figure Description

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

[0013] Figure 1 A flowchart illustrating the debugging and verification method for the components provided in the embodiments of this application; Figure 2 A schematic diagram of a sub-process of the debugging and verification method for the components provided in the embodiments of this application; Figure 3 A schematic block diagram of a debugging and verification apparatus for components provided in the embodiments of this application; Figure 4 A schematic block diagram of a computer device provided in an embodiment of this application. Detailed Implementation

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

[0015] 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 obtained by authorized entities (who have known and consented) or fully authorized by all parties 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.

[0016] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0017] It should also be understood that the terminology used in this application specification is for the purpose of describing particular embodiments only and is not intended to limit the application. As used in this application specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0018] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0019] This application provides a method, apparatus, computer device, and storage medium for debugging and verifying components.

[0020] The execution subject of the debugging and verification method of the component can be the debugging and verification device of the component provided in the embodiments of this application, or a computer device that integrates the debugging and verification device of the component. The debugging and verification device of the component can be implemented in hardware or software, and the computer device can be a terminal or a server.

[0021] Specifically, the computer device is a developer platform, which includes a developer terminal (for providing a debugging workbench interface) and a development server (Vite DevServer).

[0022] Figure 1 This is a flowchart illustrating the debugging and verification method for the components provided in this application embodiment. For example... Figure 1 As shown, the method includes the following steps S110-S150.

[0023] S110. In response to the developer's debugging operation, obtain the target component identifier, configuration parameters, and target device screen width of the target component to be verified. The configuration parameters include the business data required for rendering the target component.

[0024] In one specific embodiment, the developer platform provides a debugging workbench interface, which includes a component selection area, a configuration parameter input area, and a device width selection area.

[0025] When developers perform debugging operations through the debugging workbench interface, such as selecting a component name (e.g., "Order Card Component") in the component selection area dropdown menu, entering or pasting business data (e.g., JSON-formatted Props data) in the configuration parameter input area, and selecting the target device screen width (e.g., 375px, representing the screen width of model A phone) in the device width selection area, the developer platform responds to the above debugging operations by obtaining the following three pieces of information: (1) Target component identifier: A string used to uniquely identify the target component, such as "im-ec-order-card". This identifier is predefined by the developer during component development and has a mapping relationship with the storage location of the component source code in the file system.

[0026] (2) Configuration parameters: A structured data object containing the business data required for rendering the target component. For example, for the "order card component", the configuration parameters can contain a JSON object with fields such as order number, product name, product image URL, order amount, and order status. This configuration parameter is the real business data (Props), which is obtained directly by the developer from the business interface documentation or test data. There is no need to manually write sample data files, which solves the problem that the correctness of component rendering under real messages cannot be verified when using non-real business Props data in existing technologies.

[0027] (3) Target device screen width: This represents the pixel value of the target mobile device screen width, in CSS pixels (px), such as 360px, 375px, 390px, 414px or 430px. This parameter determines the target base width for subsequent style conversions.

[0028] In this embodiment, the target component can specifically be a card-based dynamic component, which refers to a type of UI element used in instant messaging scenarios and driven by real-time data delivery from the server. The rendering logic of a card-based dynamic component is decoupled from the data; the server only delivers the component type identifier and the corresponding business attribute values ​​(Props), and the client retrieves the corresponding component source code for rendering based on the identifier. This mechanism means that the component must be used in a real mobile device's browser / WebView, along with real-time business data, to fully verify its parsing logic, layout adaptability, and interactive response performance. Desktop simulation environments cannot simulate the dynamic data environment delivered by the server.

[0029] S120. Obtain the component source code of the target component according to the target component identifier, and generate a target web page file based on the configuration parameters, the target device screen width, and the component source code.

[0030] In one specific embodiment, the developer platform locates and reads the corresponding component source code file from the file system based on the target component identifier. For example, the developer platform pre-maintains a mapping table between component identifiers and the absolute paths of component modules, and the component import path of the target component can be obtained by querying this mapping table.

[0031] After obtaining the component's source code, the developer platform performs a build operation, packaging the component's source code along with configuration parameters and the target device's screen width into a single webpage file (HTML file). This webpage file contains a complete HTML skeleton structure, inline CSS styles, and JavaScript scripts. This webpage file is the executable artifact that can run and render the target component independently in a browser.

[0032] Furthermore, in some embodiments, specifically, please refer to Figure 2 Specifically, the target webpage file can be generated through the following steps: S1201. Determine the target component import path corresponding to the target component identifier based on the preset correspondence between component identifier and component import path.

[0033] In one specific embodiment, the developer platform scans component files in the project directory upon startup and establishes a mapping table between component identifiers and absolute paths of component modules in the file system. This mapping table can be maintained in memory as a JavaScript object (Map).

[0034] For example, when the developer selects the target component identifier as "im-ec-order-card", the developer platform queries the above mapping table to determine the target component import path as " / home / project / src / components / OrderCard / index.js".

[0035] S1202. Import the source code of the component based on the target component import path.

[0036] In one specific embodiment, the developer platform reads and imports the source code of the target component using Node.js's module loading mechanism (such as require() or dynamic import()) based on the target component's import path. The import operation obtains the component module's exported object, which contains the component's mount function or component class definition. The developer platform obtains a reference to the mount function through the import operation, which is used to subsequently mount the component into the DOM container of the web page file.

[0037] S1203. Obtain a preset style conversion script and a mounting guide script. The style conversion script is used to convert the style attribute values ​​in the target webpage file from pixel units to viewport width units according to the screen width of the target device when the target webpage file is loaded on the user terminal. The mounting guide script is used to mount the target component to the document object model container of the target webpage file.

[0038] In one specific embodiment, the developer platform reads and imports the source code of the target component using Node.js's module loading mechanism (such as require() or dynamic import()) based on the obtained target component import path. The import operation obtains the component module's exported object, which contains the component's mount function or component class definition.

[0039] In one specific embodiment, the developer platform pre-stores two script files: (1) Style conversion script (px-to-vw.js): This script contains conversion functions that convert style attribute values ​​in the target web page file from pixel units (px) to viewport width units (vw) according to the screen width of the target device when the target web page file is loaded on the user terminal.

[0040] (2) Mounting the bootstrap script (h5-bootstrap.js): This script contains bootstrap functions for mounting the target component into the Document Object Model (DOM) container of the target web page file. The main functions of the bootstrap functions include: mounting the component into the DOM container, calling the style transformation function in the document loading completion event, and registering a document change observer (MutationObserver) to listen for subsequent dynamically injected style nodes.

[0041] The developer platform reads the complete source code of the two script files mentioned above from the file system and obtains their contents as strings.

[0042] S1204. Generate the target webpage file based on the component source code, the configuration parameters, the target device screen width, the style conversion script, and the mounting guide script.

[0043] In one specific embodiment, the developer platform first generates a temporary entry file, which is composed of the following three code snippets concatenated in sequence: (1) Component import code snippet: For example, import { mount} from ' / home / project / src / components / OrderCard / index.js'; (2) Style conversion script fragment: Write the complete source code of px-to-vw.js into the entry file as an inline string; (3) Mount the bootstrap script fragment: Write the complete source code of h5-bootstrap.js into the entry file as an inline string, and call the bootstrap function at the end: initH5Bundle(mount, {"orderId":"20260727001",...}, 375); Then, the developer platform calls the Vite build tool's API to build the entry file. The build configuration specifies: output format as IIFE (Immediately Invoked Function Expression), disable CSS code splitting (making CSS inline into JavaScript), target JavaScript language version as ES2015, and no write to disk (the build result is returned in memory). After the build is complete, the JavaScript code output is embedded in a preset HTML template.

[0044] The final generated HTML document is the target webpage file. This file is an independent, self-contained webpage file, with all CSS styles and JavaScript scripts inlined and not dependent on any external resources (except for external content such as image URLs in the business data).

[0045] As can be seen, this embodiment achieves automated generation of target webpage files by reusing the preset component identifier-import path mapping relationship, style conversion script, and mounting guide script. Developers do not need to manually write preview code or sample data files for each component, reducing additional development costs. At the same time, the separate design of the style conversion script and the mounting guide script allows the style adaptation logic and mounting logic to be maintained and reused independently.

[0046] In some embodiments, a cache check is further included before performing step S120, specifically including the following steps: Step A: Generate the target build identifier based on the target component identifier, the configuration parameters, and the target device screen width.

[0047] In one specific embodiment, the developer platform combines the component identifier, the serialized string of configuration parameters, and the target device screen width, and then uses a hash algorithm to generate a target build identifier.

[0048] Step B: Determine whether a target webpage file corresponding to the target build identifier exists in the cache; In one specific embodiment, the developer platform maintains an in-memory cache object (such as a JavaScript Map object) that stores the constructed web page files. The cache is stored in key-value pairs, where the key is the build identifier (string) and the value is the web page file content (HTML document string).

[0049] The developer platform uses the generated target build identifier as the key to query whether a corresponding entry exists in the cache object. For example, it calls the `cache.has(buildId)` method to check if the entry exists.

[0050] If the corresponding target webpage file exists in the cache (i.e., a cache hit), the developer platform skips the subsequent build and generation steps and reuses the cached webpage file. If the corresponding target webpage file does not exist in the cache (i.e., a cache miss), step S120 is executed. After generation, the newly generated target webpage file is associated with the target build identifier and stored in the cache for reuse in subsequent identical requests.

[0051] If a target webpage file corresponding to the target construction identifier exists in the cache, the access address of the target webpage file in the cache is encoded into an optically readable graphic code and displayed.

[0052] For example, suppose a developer is debugging the "Order Card Component" for the first time, configuring the order data with order number "20260727001". At this time, there is no corresponding entry in the cache. The complete build process is executed, which takes about 2-3 seconds, generating the target webpage file and caching it.

[0053] Subsequently, the developer debugged the "Order Card Component" again in the same session with the same configuration parameters (the same order data with order number "20260727001"). At this time, the cache was hit, and the cached web page file was reused directly without rebuilding, reducing the response time to milliseconds.

[0054] If the developer modifies the configuration parameters (for example, by changing them to order data with order number "20260727002"), the generated target build identifier will change, the cache will be missed, and a new web page file will be generated by rebuilding.

[0055] As can be seen, this embodiment introduces a process of "checking the cache first, and only building if the cache is missed," which avoids repeated building of the same components and configuration parameters, greatly improving debugging efficiency. Especially when developers repeatedly adjust styles or view different data scenarios, the caching mechanism makes subsequent verification almost instantaneous.

[0056] S130. The target webpage file is associated with the target build identifier and stored in the cache. The target build identifier is generated based on the target component identifier, the configuration parameters and the target device screen width.

[0057] In one embodiment, the target build identifier is generated by hashing the target component identifier, the serialized string of the configuration parameters, and the target device screen width. Specifically, the developer platform combines the target component identifier, the serialized string of the configuration parameters (such as the string after JSON.stringify), and the target device screen width, calculates its hash value (e.g., using the MD5 message digest algorithm), and generates a unique target build identifier (buildId).

[0058] Then, the developer platform associates the complete HTML document string of the target webpage file generated in step S120 with the aforementioned target build identifier, storing it in a memory cache as a key-value pair (the key is the target build identifier, and the value is the content of the target webpage file). The cached data can be directly reused for subsequent identical build requests.

[0059] In this embodiment, the rendering result of a component is determined by the target component identifier, the serialized string of configuration parameters, and the target device screen width. A change in any one of these factors will result in a different combined string, leading to different hash values ​​and thus different build identifiers. Therefore, different combinations of components, different configuration parameters, or different target device screen widths all correspond to a unique build identifier, ensuring the uniqueness and accuracy of the cache key.

[0060] S140. Encode the access address of the target webpage file in the cache into an optically readable graphic code and display it.

[0061] In one specific embodiment, the developer platform constructs the access address (URL) of the target webpage file, and the format of the access address is: "http: / / {developer's LAN IP address}:{port number} / {routing path} / {target build identifier}", for example, "http: / / 192.168.1.100:5173 / h5-bundle / im-ec-order-card-a1b2c3d4".

[0062] The developer platform encodes the access address into an optically readable graphic code. In one implementation, this optically readable graphic code is a QR code (Quick Response Matrix code). The developer platform calls a QR code encoding library (such as qrcode.js) to generate the corresponding QR code image data, and then displays the QR code image in a pop-up window or panel of the debugging workbench interface.

[0063] S150. When the user terminal scans the optically readable graphic code, the target webpage file is sent to the user terminal so that the user terminal displays the target component based on the target webpage file, and the user terminal renders and displays the target component based on the target webpage file and according to the screen width of the target device.

[0064] Specifically, in one embodiment, the user terminal and the developer platform communicate based on the Hypertext Transfer Protocol within the same local area network; wherein, the developer platform acts as the server, undertaking the functions of construction calculation, cache management, and access address generation, and the user terminal acts as the client, obtaining the access address by scanning an optically readable graphic code, requesting and loading the target web page file using the Hypertext Transfer Protocol, and undertaking the functions of component rendering and visual verification.

[0065] In one specific embodiment, the user (i.e., the developer) uses the camera application of a mobile terminal (such as a mobile phone) to scan the QR code displayed on the debugging workbench interface. After the mobile terminal's operating system or browser application recognizes the URL address encoded in the QR code, it automatically opens the browser and requests the URL.

[0066] When the screen width of the user terminal performing the scanning is the same as the screen width of the target device, component verification can be performed on a real device of the same size.

[0067] Upon receiving the request, the HTTP routing module on the development server parses the target build identifier from the URL path and then searches the cache for the target webpage file content corresponding to that identifier. If found, the target webpage file (HTML document) is returned as an HTTP response to the browser on the mobile terminal (user terminal). The mobile terminal's browser receives the response, parses and renders the HTML document, thereby displaying the target component on the mobile terminal screen.

[0068] Now, developers no longer need to manually enter IP addresses and port numbers, nor do they need to build a full application. They can simply scan a QR code to preview the actual rendering effect of the component on a real mobile device.

[0069] In some embodiments, the method further includes: When a code change event is detected in the source code of the component, all web page files associated with the source code of the component are deleted from the cache.

[0070] Specifically, the developer platform subscribes to file system change events (such as the 'change' event). When a developer modifies and saves a component's source code file in the code editor, the file monitor triggers the 'change' event, and the event callback function carries the path information of the changed file.

[0071] For example, if a developer modifies the source code file / home / project / src / components / OrderCard / index.js or the style file / home / project / src / components / OrderCard / OrderCard.css of the "Order Card Component", the file monitor will trigger a change event, and the callback function will receive the changed file path.

[0072] The developer platform extracts the component directory name from the changed file path, for example, by using regular expression matching or path parsing to extract "OrderCard", and then queries the component identifier corresponding to the component directory name (such as "im-ec-order-card").

[0073] Next, the developer platform iterates through all entries in the memory cache and deletes all cache entries associated with the "im-ec-order-card" component identifier. The deletion operation includes: (1) Delete the corresponding key-value pair from the cache object; (2) Clean up the corresponding indexes in the mapping relationship between component identifiers and build identifiers.

[0074] When a component's source code changes, all web page files built based on the old source code (regardless of configuration parameters or target device screen width) will no longer reflect the latest component logic and should therefore be cleared. This implementation uses a "batch deletion by component identifier" strategy. When the source code of any component changes, all cached entries corresponding to that component are deleted, ensuring consistency between cached content and the source code.

[0075] For example, suppose a developer discovers an error in the price display format of the "Order Card Component" while debugging it. They then modify the price formatting logic in the OrderCard / index.js file and save the changes. At this point, the file monitor detects the change event, and the developer platform automatically deletes all cached entries whose build identifiers begin with "im-ec-order-card". Subsequently, when the developer scans the code again for debugging, the cache miss occurs, triggering a rebuild. The generated webpage file contains the latest price formatting logic, ensuring that the latest code is being verified.

[0076] In some embodiments, after storing the target webpage file associated with the target build identifier in a cache, the method further includes: Determine whether the number of web page files stored in the cache is greater than a preset file number threshold; If the number of web page files stored in the cache exceeds the preset file number threshold, then the web page file with the earliest creation time in the cache is deleted.

[0077] In one specific embodiment, the developer platform sets a preset file count threshold for the cache, such as 50 (i.e., a maximum of 50 web page files can be cached). Each time a new web page file is stored in the cache, the developer platform checks whether the total number of web page files currently stored in the cache exceeds the preset file count threshold.

[0078] For example, if there are 50 web page files in the current cache, and a new build request triggers the generation of a new web page file and stores it in the cache, the total number of cached files becomes 51, which is greater than the preset threshold of 50, triggering an eviction operation.

[0079] For example, if it is determined that the number of web page files stored in the cache is greater than a preset file number threshold, the developer platform will use an LRU (Least Recently Used) strategy or a FIFO (First In First Out) strategy based on creation time to evict cache entries.

[0080] In one embodiment, the developer platform records a creation timestamp for each cached entry. When a cache needs to be evicted, all cached entries are traversed, and the entry with the earliest creation timestamp is selected for deletion. For example, when the 51st entry is stored, all entries are traversed, and the entry with the earliest creation time is found to be "im-ec-order-card-a1b2c3d4" (created at 14:30:25). This entry is then deleted, and the corresponding index in the mapping relationship between component identifiers and build identifiers is cleared. After deletion, the total number of caches is restored to 50, ensuring that it does not exceed a preset threshold.

[0081] In another embodiment, the cache eviction policy adopts the LRU (Least Recently Used) strategy, that is, the last access time (lastAccessTime) is recorded for each cache entry, and the entry with the earliest last access time is deleted each time eviction occurs. Those skilled in the art can choose a suitable eviction policy according to actual needs.

[0082] The development server in this embodiment supports multiple mobile terminals simultaneously scanning the same or different QR codes to access the corresponding web page files. Since the cache is stored in the server's memory, when multiple terminals request web page files with the same build identifier, the server directly returns the HTML document from the cache, without needing to rebuild it repeatedly.

[0083] In summary, the method provided in this application is applied to a developer platform. This embodiment automatically obtains component identifiers, configuration parameters, and device screen width in response to the developer's debugging operations, dynamically generates independent web page files and caches them, and then achieves zero-input device connection through optical codes. This solves the efficiency bottleneck in the prior art where component-level modifications require a full build and deployment for real device verification, and improves the debugging and verification efficiency of components.

[0084] Figure 3 This is a schematic block diagram of a component debugging and verification device 300 provided in an embodiment of this application. Figure 3 As shown, corresponding to the debugging and verification methods for the above components, this application also provides a debugging and verification apparatus 300 for a component. This debugging and verification apparatus 300 includes a unit for executing the aforementioned debugging and verification methods for the component, and can be configured in a developer platform. Specifically, please refer to... Figure 3 The debugging and verification device 300 for this component includes an acquisition unit 301, a webpage file generation unit 302, an identifier generation unit 303, an encoding unit 304, and a sending unit 305, wherein: The acquisition unit 301 is used to respond to the developer's debugging operation and acquire the target component identifier, configuration parameters and target device screen width of the target component to be verified. The configuration parameters include the business data required for rendering the target component. The webpage file generation unit 302 is used to obtain the component source code of the target component according to the target component identifier, and generate a target webpage file based on the configuration parameters, the target device screen width, and the component source code; The identifier generation unit 303 is used to associate the target web page file with the target construction identifier and store it in a cache. The target construction identifier is generated based on the target component identifier, the configuration parameters, and the target device screen width. Encoding unit 304 is used to encode the access address of the target webpage file in the cache into an optically readable graphic code and display it; The sending unit 305 is configured to send the target webpage file to the user terminal when the user terminal scans the optically readable graphic code, so that the user terminal displays the target component based on the target webpage file, and renders and displays the target component based on the target webpage file and according to the screen width of the target device.

[0085] In some embodiments, the webpage file generation unit 302 is specifically used for: Based on the preset correspondence between component identifiers and component import paths, determine the target component import path corresponding to the target component identifier; Import the source code of the component based on the target component import path; Obtain a preset style conversion script and a mounting guide script. The style conversion script is used to convert the style attribute values ​​in the target web page file from pixel units to viewport width units according to the screen width of the target device when the target web page file is loaded on the user terminal. The mounting guide script is used to mount the target component to the document object model container of the target web page file. The target webpage file is generated based on the component source code, the configuration parameters, the target device screen width, the style conversion script, and the mounting guide script.

[0086] In some embodiments, the component debugging and verification apparatus 300 further includes: The identifier generation unit 303 is used to generate the target build identifier based on the target component identifier, the configuration parameters, and the target device screen width; A cache file determination unit is used to determine whether a target webpage file corresponding to the target construction identifier exists in the cache. At this time, the web page file generation unit 302 is specifically used to: if there is no target web page file corresponding to the target construction identifier in the cache, obtain the component source code of the target component according to the target component identifier, and generate the target web page file based on the configuration parameters, the target device screen width and the component source code.

[0087] In some embodiments, the encoding unit 304 is further configured to encode the access address of the target webpage file in the cache into an optically readable graphic code and display it if a target webpage file corresponding to the target construction identifier exists in the cache.

[0088] In some embodiments, when the identifier generation unit 303 performs the step of generating a target build identifier based on the target component identifier, the configuration parameters, and the target device screen width, it is specifically used for: The target component identifier, the serialized string of the configuration parameters, and the target device screen width are hashed to generate the target build identifier.

[0089] In some embodiments, the component debugging and verification apparatus 300 further includes: The first deletion unit is used to delete all web page files associated with the source code of the component in the cache when a code change event of the source code of the component is detected.

[0090] In some embodiments, the component debugging and verification apparatus 300 further includes: A quantity determination unit is used to determine whether the number of web page files stored in the cache is greater than a preset file quantity threshold; The second deletion unit is used to delete the earliest created web page file in the cache if the number of web page files stored in the cache is greater than the preset file number threshold.

[0091] In summary, the component debugging and verification device 300 provided in this application embodiment is deployed on the developer platform. This embodiment automatically obtains the component identifier, configuration parameters and device screen width in response to the developer's debugging operation, dynamically generates independent web page files and caches them, and then achieves zero-input device connection through optical code. This solves the efficiency bottleneck in the prior art where component-level modifications require a full build and deployment for real device verification, and improves the efficiency of component debugging and verification.

[0092] It should be noted that those skilled in the art can clearly understand that the debugging and verification device and the specific implementation process of each unit of the above components can be referred to the corresponding descriptions in the foregoing method embodiments. For the sake of convenience and brevity, they will not be repeated here.

[0093] The debugging and verification device for the aforementioned components can be implemented as a computer program, which can be used in, for example... Figure 4 It runs on the computer device shown.

[0094] Please see Figure 4 , Figure 4 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 400 is a developer platform, which includes a developer terminal (for providing a debugging workbench interface) and a development server.

[0095] See Figure 4 The computer device 400 includes a processor 402, a memory, and a network interface 405 connected via a system bus 401. The memory may include a non-volatile storage medium 403 and internal memory 404.

[0096] The non-volatile storage medium 403 may store an operating system 4031 and a computer program 4032. The computer program 4032 includes program instructions that, when executed, cause the processor 402 to perform a debugging and verification method for a component.

[0097] The processor 402 provides computing and control capabilities to support the operation of the entire computer device 400.

[0098] The internal memory 404 provides an environment for the execution of the computer program 4032 in the non-volatile storage medium 403. When the computer program 4032 is executed by the processor 402, the processor 402 can execute a component debugging and verification method.

[0099] This network interface 405 is used for network communication with other devices. Those skilled in the art will understand that... Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 400 to which the present application is applied. The specific computer device 400 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0100] The processor 402 is used to run a computer program 4032 stored in the memory to perform the following steps: In response to the developer's debugging operation, obtain the target component identifier, configuration parameters, and target device screen width of the target component to be verified. The configuration parameters include the business data required for rendering the target component. The source code of the target component is obtained based on the target component identifier, and a target webpage file is generated based on the configuration parameters, the target device screen width, and the component source code. The target webpage file is associated with the target build identifier and stored in the cache. The target build identifier is generated based on the target component identifier, the configuration parameters, and the target device screen width. The access address of the target webpage file in the cache is encoded into an optically readable graphic code and displayed. When a user terminal scans the optically readable graphic code, the target webpage file is sent to the user terminal so that the user terminal can display the target component based on the target webpage file, and the user terminal can render and display the target component based on the target webpage file and according to the screen width of the target device.

[0101] It should be understood that in the embodiments of this application, the processor 402 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0102] It will be understood by those skilled in the art 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 includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0103] Therefore, this application also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. When executed by a processor, the program instructions cause the processor to perform the following steps: In response to the developer's debugging operation, obtain the target component identifier, configuration parameters, and target device screen width of the target component to be verified. The configuration parameters include the business data required for rendering the target component. The source code of the target component is obtained based on the target component identifier, and a target webpage file is generated based on the configuration parameters, the target device screen width, and the component source code. The target webpage file is associated with the target build identifier and stored in the cache. The target build identifier is generated based on the target component identifier, the configuration parameters, and the target device screen width. The access address of the target webpage file in the cache is encoded into an optically readable graphic code and displayed. When a user terminal scans the optically readable graphic code, the target webpage file is sent to the user terminal so that the user terminal can display the target component based on the target webpage file, and the user terminal can render and display the target component based on the target webpage file and according to the screen width of the target device.

[0104] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0105] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0106] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0107] The steps in the methods of this application embodiment can be adjusted, merged, or deleted according to actual needs. The units in the apparatus of this application embodiment can be merged, divided, or deleted according to actual needs. Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0108] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a terminal, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0109] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for debugging and verifying a component, characterized in that, The method is applied to a developer platform and includes: In response to the developer's debugging operation, obtain the target component identifier, configuration parameters, and target device screen width of the target component to be verified. The configuration parameters include the business data required for rendering the target component. The source code of the target component is obtained based on the target component identifier, and a target webpage file is generated based on the configuration parameters, the target device screen width, and the component source code. The target webpage file is associated with a target build identifier and stored in the cache. The target build identifier is generated based on the target component identifier, the configuration parameters, and the target device screen width. The access address of the target webpage file in the cache is encoded into an optically readable graphic code and displayed. When a user terminal scans the optically readable graphic code, the target webpage file is sent to the user terminal so that the user terminal can display the target component based on the target webpage file, and the user terminal can render and display the target component based on the target webpage file and according to the screen width of the target device.

2. The method according to claim 1, characterized in that, The step of obtaining the component source code of the target component based on the target component identifier, and generating the target webpage file based on the configuration parameters, the target device screen width, and the component source code includes: Based on the preset correspondence between component identifiers and component import paths, determine the target component import path corresponding to the target component identifier; Import the source code of the component based on the target component import path; Obtain a preset style conversion script and a mounting guide script. The style conversion script is used to convert the style attribute values ​​in the target web page file from pixel units to viewport width units according to the screen width of the target device when the target web page file is loaded on the user terminal. The mounting guide script is used to mount the target component to the document object model container of the target web page file. The target webpage file is generated based on the component source code, the configuration parameters, the target device screen width, the style conversion script, and the mounting guide script.

3. The method according to claim 1, characterized in that, Before obtaining the component source code of the target component based on the target component identifier, and generating the target webpage file based on the configuration parameters, the target device screen width, and the component source code, the method further includes: The target build identifier is generated based on the component identifier, the configuration parameters, and the target device screen width; Determine whether a target webpage file corresponding to the target build identifier exists in the cache; The step of obtaining the component source code of the target component based on the target component identifier, and generating the target webpage file based on the configuration parameters, the target device screen width, and the component source code includes: If the cache does not contain a target webpage file corresponding to the target build identifier, then the component source code of the target component is obtained according to the target component identifier, and a target webpage file is generated based on the configuration parameters, the target device screen width, and the component source code.

4. The method according to claim 3, characterized in that, After determining whether a target webpage file corresponding to the target build identifier exists in the cache, the method further includes: If a target webpage file corresponding to the target construction identifier exists in the cache, the access address of the target webpage file in the cache is encoded into an optically readable graphic code and displayed.

5. The method according to claim 3, characterized in that, The process of generating a target build identifier based on the target component identifier, the configuration parameters, and the target device screen width includes: The target component identifier, the serialized string of the configuration parameters, and the target device screen width are hashed to generate the target build identifier.

6. The method according to claim 1, characterized in that, The method further includes: When a code change event is detected in the source code of the component, all web page files associated with the source code of the component are deleted from the cache.

7. The method according to claim 1, characterized in that, After associating the target webpage file with the target build identifier and storing it in the cache, the method further includes: Determine whether the number of web page files stored in the cache is greater than a preset file number threshold; If the number of web page files stored in the cache exceeds the preset file number threshold, then the web page file with the earliest creation time in the cache is deleted.

8. A debugging and verification device for a component, wherein the debugging and verification device for the component is deployed on a developer platform, characterized in that, include: The acquisition unit is used to respond to the developer's debugging operation and acquire the target component identifier, configuration parameters, and target device screen width of the target component to be verified. The configuration parameters include the business data required for rendering the target component. A webpage file generation unit is used to obtain the component source code of the target component according to the target component identifier, and generate a target webpage file based on the configuration parameters, the target device screen width, and the component source code; An identifier generation unit is used to associate the target webpage file with the target construction identifier and store it in a cache. The target construction identifier is generated based on the target component identifier, the configuration parameters, and the target device screen width. An encoding unit is used to encode the access address of the target webpage file in the cache into an optically readable graphic code and display it. The sending unit is configured to send the target webpage file to the user terminal when the user terminal scans the optically readable graphic code, so that the user terminal displays the target component based on the target webpage file, and renders and displays the target component based on the target webpage file and according to the screen width of the target device.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the debugging and verification method of the component as described in any one of claims 1-7.

10. A storage medium, characterized in that, The storage medium stores a computer program, which includes program instructions that, when executed by a processor, cause the processor to perform the debugging and verification method of the component as described in any one of claims 1-7.

Images