Page dependency resolving method and apparatus

Abstract

This specification provides one or more embodiments of a page dependency resolution method and apparatus, applied to a service platform. Through this method, after receiving a page dependency resolution request containing the route of the page to be resolved and its corresponding code management platform, the service platform can obtain metadata of the route configuration file directory and the page code file directory from the code management platform. Based on the metadata of the route configuration file directory, it obtains the mapping relationship between the page route and the page code file. Based on the mapping relationship and the metadata of the page code file directory, it obtains the target page code file corresponding to the page route to be resolved. Then, it can recursively parse the target page code file to obtain the dependency information of the page to be resolved.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of computer network technology, and in particular to a page dependency parsing method and apparatus. Background Technology

[0002] With the rapid development of front-end technologies, front-end framework migration has become a crucial requirement for enterprises to adapt to technology upgrades and achieve multi-platform compatibility. Page dependency resolution, as a prerequisite for front-end framework migration, analyzes code structure and dependencies to provide a foundation for subsequent code conversion and functional adaptation, ensuring the integrity of the migrated system's functionality.

[0003] Currently, front-end application code resources are generally managed and stored in remote code repositories, and the technical implementations are diverse. This places higher demands on the efficiency and accuracy of page dependency resolution. To achieve page dependency identification in remote scenarios and reduce the resource consumption of front-end framework migration, a more efficient page dependency resolution solution is needed. Summary of the Invention

[0004] To efficiently identify page dependencies in remote scenarios and reduce the resource consumption of front-end framework migration, this specification provides a page dependency parsing method and apparatus through one or more embodiments.

[0005] Firstly, one or more embodiments of this specification provide a page dependency resolution method applied to a service platform, the method comprising: The system receives a page dependency resolution request, which includes the page route to be resolved and its corresponding code management platform; wherein the page route to be resolved represents the user access path of the page to be resolved, and the code management platform stores route configuration files and page code files; Obtain metadata of the route configuration file directory and metadata of the page code file directory from the code management platform; Based on the metadata of the routing configuration file directory, obtain the mapping relationship between page routes and page code files; Based on the mapping relationship and the metadata of the page code file directory, obtain the target page code file corresponding to the page route to be parsed; The target page code file is recursively parsed to obtain the dependency information of the page to be parsed.

[0006] In one possible implementation, the metadata of the routing configuration file directory includes file identifiers and file paths within the directory; obtaining the mapping relationship between page routes and page code files based on the metadata of the routing configuration file directory includes: Based on the file identifier of the configuration routing file, the file path of the configuration routing file is determined from the metadata of the routing configuration file directory, and the configuration routing file is obtained based on the file path; The configuration routing file is parsed to obtain the configuration routing rules for all pages; Based on the configuration-based routing rules, the mapping relationship between the page routes and the page code files is obtained.

[0007] In one possible implementation, obtaining the mapping relationship between the page routes and the page code files based on the configuration routing rules includes: Obtain the conventional routing rules of the platform where the route of the page to be parsed is located; Based on the configuration-based routing rules and the convention-based routing rules, the mapping relationship between the page routes and the page code files is obtained.

[0008] In one possible implementation, the service platform includes an interactive interface; the step of obtaining the target page code file corresponding to the page route to be parsed based on the mapping relationship and the metadata of the page code file directory includes: Among all page routes, obtain the page routes related to the page route to be parsed, and use them as candidate page routes; The candidate page routes are displayed on the interactive interface so that the user can determine the target page route based on the candidate page routes. Based on the mapping relationship and the metadata of the page code file directory, obtain the target page code file corresponding to the target page route.

[0009] In one possible implementation, the metadata of the page code file directory includes file identifiers and file paths within the page code file directory; obtaining the target page code file corresponding to the target page route based on the mapping relationship and the metadata of the page code file directory includes: Based on the mapping relationship, the target page code file corresponding to the target page route is determined; Based on the file identifier of the target page code file, the file path of the target page code file is determined from the metadata of the page code file directory; The target page code file is obtained based on the file path.

[0010] In one possible implementation, the recursive parsing of the target page code file to obtain the dependency information of the page to be parsed includes: The target page code file is parsed into an abstract syntax tree; the abstract syntax tree includes import nodes of the target page, and the import nodes include at least one of static import nodes, dynamic import nodes, and conventional import nodes; The import nodes in the abstract syntax tree are recursively scanned to obtain the dependent files and dependencies of the target page code file. Based on the dependency files and the dependency relationships, the dependency information of the page to be parsed is obtained.

[0011] In one possible implementation, the recursive scanning of the import nodes in the abstract syntax tree to obtain the dependency files and dependency relationships of the target page code file includes: The import nodes in the abstract syntax tree are recursively scanned to obtain the direct dependency files of the target page code file, and the direct dependency relationship between the target page code file and the direct dependency files is obtained. Based on the file identifier of the directly dependent file, query whether the dependency information of the directly dependent file is stored in the cache file; If so, the dependency information of the directly dependent files is obtained from the cache file, and the dependent files and dependency relationships of the target page code file are obtained based on the dependency information of the directly dependent files.

[0012] In one possible implementation, the method further includes: If the cache file does not store the dependency information of the direct dependent file, then based on the file identifier of the direct dependent file, the file path of the direct dependent file is obtained from the metadata of the page code file directory, and the direct dependent file is obtained based on the file path; The direct dependency files are recursively parsed to obtain the parsing results, and the parsing results are stored in the cache file; wherein, the parsing results include the indirect dependency files of the target page code file, and the indirect dependency relationships between the direct dependency files and the indirect dependency files; If no new dependent files are found in the parsing results, the dependent files are obtained based on the direct and indirect dependent files, and the dependency relationships are obtained based on the direct and indirect dependency relationships.

[0013] In one possible implementation, after obtaining the dependency information of the page to be parsed, the method further includes: The dependency information of the page to be parsed is encapsulated into standardized data; The standardized data is displayed on the interactive interface, and / or the standardized data is input into the data processing model so that the data processing model processes the standardized data based on preset rules.

[0014] Secondly, one or more embodiments of this specification also provide a page-dependent parsing apparatus applied to a service platform, the apparatus comprising: The receiving module is used to receive page dependency resolution requests, which include the page route to be resolved and its corresponding code management platform; wherein, the page route to be resolved represents the user access path of the page to be resolved, and the code management platform stores route configuration files and page code files; The first acquisition module is used to acquire metadata of the route configuration file directory and metadata of the page code file directory from the code management platform. The second acquisition module is used to acquire the mapping relationship between page routes and page code files based on the metadata of the route configuration file directory; The third acquisition module is used to acquire the target page code file corresponding to the page route to be parsed based on the mapping relationship and the metadata of the page code file directory; The parsing module is used to recursively parse the target page code file to obtain the dependency information of the page to be parsed.

[0015] In one possible implementation, the metadata of the routing configuration file directory includes the file identifier and file path in the routing configuration file directory; The second acquisition module is used to acquire the mapping relationship between page routes and page code files based on the metadata of the route configuration file directory, including: The second acquisition module is used to: determine the file path of the configuration routing file from the metadata of the routing configuration file directory based on the file identifier of the configuration routing file, and acquire the configuration routing file based on the file path; parse the configuration routing file to obtain the configuration routing rules for all pages; and obtain the mapping relationship between the page routes and the page code files based on the configuration routing rules.

[0016] In one possible implementation, the second acquisition module is used to obtain the mapping relationship between the page routes and the page code files based on the configuration routing rules, including: The second acquisition module is used to acquire the conventional routing rules of the platform where the page route to be parsed is located; and based on the configuration routing rules and the conventional routing rules, to obtain the mapping relationship between the page route and the page code file.

[0017] In one possible implementation, the service platform includes an interactive interface; The third acquisition module is used to acquire the target page code file corresponding to the page route to be parsed based on the mapping relationship and the metadata of the page code file directory, including: The third acquisition module is used to: acquire, from all page routes, page routes related to the page route to be parsed, as candidate page routes; display the candidate page routes on the interactive interface so that the user can determine the target page route based on the candidate page routes; and acquire the target page code file corresponding to the target page route based on the mapping relationship and the metadata of the page code file directory.

[0018] In one possible implementation, the metadata of the page code file directory includes file identifiers and file paths within the page code file directory; The third acquisition module is used to acquire the target page code file corresponding to the target page route based on the mapping relationship and the metadata of the page code file directory, including: The third acquisition module is used to: determine the target page code file corresponding to the target page route based on the mapping relationship; determine the file path of the target page code file from the metadata of the page code file directory based on the file identifier of the target page code file; and obtain the target page code file based on the file path.

[0019] In one possible implementation, the parsing module is used to recursively parse the target page code file to obtain the dependency information of the page to be parsed, including: The parsing module is used to parse the target page code file into an abstract syntax tree, the abstract syntax tree including import nodes of the target page, the import nodes including at least one of static import nodes, dynamic import nodes and conventional import nodes; recursively scan the import nodes in the abstract syntax tree to obtain the dependent files and dependency relationships of the target page code file; and obtain the dependency information of the page to be parsed based on the dependent files and dependency relationships.

[0020] In one possible implementation, the parsing module is used to recursively scan the import nodes in the abstract syntax tree to obtain the dependency files and dependency relationships of the target page code file, including: The parsing module is used to recursively scan the import nodes in the abstract syntax tree to obtain the direct dependent files of the target page code file and the direct dependency relationship between the target page code file and the direct dependent files; based on the file identifier of the direct dependent file, query whether the dependency information of the direct dependent file is stored in the cache file; if so, obtain the dependency information of the direct dependent file from the cache file, and obtain the dependent files and dependency relationships of the target page code file based on the dependency information of the direct dependent file.

[0021] In one possible implementation, the parsing module is further configured to, if the cache file does not store the dependency information of the direct dependent file, obtain the file path of the direct dependent file from the metadata of the page code file directory based on the file identifier of the direct dependent file, and obtain the direct dependent file based on the file path; The direct dependency files are recursively parsed to obtain the parsing results, and the parsing results are stored in the cache file; wherein, the parsing results include the indirect dependency files of the target page code file, and the indirect dependency relationships between the direct dependency files and the indirect dependency files; If no new dependent files are found in the parsing results, the dependent files are obtained based on the direct and indirect dependent files, and the dependency relationships are obtained based on the direct and indirect dependency relationships.

[0022] In one possible implementation, the device further includes an encapsulation module, a display module, and / or a processing module; The encapsulation module is used to encapsulate the dependency information of the page to be parsed into standardized data; The display module is used to display the standardized data on the interactive interface; The processing module is used to input the standardized data into the data processing model, so that the data processing model processes the standardized data based on preset rules.

[0023] Thirdly, one or more embodiments of this specification also provide an electronic device, which includes a memory and a processor; the memory is used to store a computer program product; the processor is used to execute the computer program product stored in the memory, and when the computer program product is executed, it implements the page dependency resolution method of the first aspect described above.

[0024] Fourthly, one or more embodiments of this specification also provide a computer-readable storage medium storing computer program instructions that, when executed, implement the page dependency resolution method of the first aspect described above.

[0025] In summary, to accurately locate the code file of the page to be parsed and efficiently obtain its dependency information, one or more embodiments of this specification provide a method and apparatus for parsing page dependencies. In this method, after the service platform receives a page dependency parsing request containing the route of the page to be parsed and its corresponding code management platform, it can obtain the metadata of the route configuration file directory and the metadata of the page code file directory from the code management platform. Based on the metadata of the route configuration file directory, it obtains the mapping relationship between the page route and the page code file. Based on the mapping relationship and the metadata of the page code file directory, it obtains the target page code file corresponding to the page route to be parsed. Then, it recursively parses the target page code file to obtain the dependency information of the page to be parsed.

[0026] In this way, the service platform can establish a mapping relationship between page routes and page code files by obtaining the metadata of the routing configuration file directory and the page code file directory. By combining the mapping relationship with the metadata of the page code file directory, the platform can locate the target page code file and perform recursive parsing. This allows the platform to obtain the dependency information of the target page without setting up a local environment, achieving page dependency parsing with zero local cloning. At the same time, it can quickly output the complete dependency information of the target page based on the precise mapping logic and recursive parsing actions, ensuring that no dependency information is missed. The entire process locates and pulls files on demand, without downloading the complete code repository, effectively reducing network transmission traffic and significantly improving the efficiency of page dependency parsing in remote scenarios. Attached Figure Description

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

[0028] Figure 1 A schematic diagram of the interactive interface of a smart assistant provided for one or more embodiments of this specification; Figure 2a A flowchart illustrating a page dependency resolution method provided in one or more embodiments of this specification; Figure 2b This is a flowchart illustrating the process of obtaining the mapping relationship between page routes and page code files based on the metadata of the route configuration file directory, as provided in one or more embodiments of this specification. Figure 2cThis is a flowchart illustrating the process of obtaining the target page code file corresponding to the page route to be parsed, based on the mapping relationship and the metadata of the page code file directory, as provided in one or more embodiments of this specification. Figure 2d This is a flowchart illustrating the process of recursively parsing a target page code file to obtain the dependency information of the page to be parsed, provided for one or more embodiments of this specification. Figure 3 A schematic diagram of the interactive interface of another intelligent assistant provided in one or more embodiments of this specification; Figure 4 A flowchart illustrating another page dependency resolution method provided in one or more embodiments of this specification; Figure 5 A structural block diagram of a page-dependent parsing apparatus provided for one or more embodiments of this specification; Figure 6 This is a structural block diagram of an electronic device provided for one or more embodiments of this specification. Detailed Implementation

[0029] The present specification describes one or more embodiments in further detail below with reference to the accompanying drawings and examples. Through these descriptions, the features and advantages of one or more embodiments of the present specification will become clearer and more apparent.

[0030] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments. Although various aspects of embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated otherwise.

[0031] Furthermore, the technical features described below in one or more embodiments of this specification may be combined with each other as long as they do not conflict with each other.

[0032] To facilitate understanding, the application scenarios of the technical solutions provided in one or more embodiments of this specification will be described below.

[0033] With the rapid development of front-end technologies and the continuous iteration and updates of various front-end frameworks, cross-version or cross-system migration of front-end frameworks has become an important requirement for enterprises to adapt to technology upgrades and achieve multi-platform compatibility. Page dependency resolution, as a prerequisite for front-end framework migration, analyzes code structure and dependency relationships to provide a foundation for subsequent code conversion and functional adaptation, ensuring the integrity of the system's functionality after migration. Page dependencies refer to the related files used to support the normal rendering and operation of the page.

[0034] Currently, the code resources of front-end applications (i.e., specific applications developed based on front-end frameworks, such as management systems, e-commerce back-ends, etc.) are generally managed and stored in remote code repositories. Remote code repositories have large data volumes, and the routing configurations of various front-end frameworks are scattered and their technical implementations are diverse. This places higher demands on the efficiency and accuracy of page dependency parsing.

[0035] In some application scenarios, performing dependency resolution by fully cloning the codebase consumes significant network bandwidth and computing resources. It is also time-consuming and inefficient, and some resolution methods can only identify dependencies in the build artifacts, failing to cover dependencies at the source file level, leading to dependency omissions. Manually reviewing page dependencies is not only inefficient overall but also prone to errors and omissions due to human factors.

[0036] To efficiently identify page dependencies in remote scenarios and reduce network traffic and resource consumption, this specification provides one or more embodiments of a page dependency parsing method and apparatus applied to a service platform. In this method, after receiving a page dependency parsing request containing the route of the page to be parsed and its corresponding code management platform, the service platform can obtain metadata of the route configuration file directory and the page code file directory from the code management platform. Based on the metadata of the route configuration file directory, it obtains the mapping relationship between the page route and the page code file. Based on the mapping relationship and the metadata of the page code file directory, it obtains the target page code file corresponding to the page route to be parsed. Then, it recursively parses the target page code file to obtain the dependency information of the page to be parsed.

[0037] In this way, the service platform can establish a mapping relationship between page routes and page code files by obtaining the metadata of the routing configuration file directory and the page code file directory. By combining the mapping relationship with the metadata of the page code file directory, the platform can locate the target page code file and perform recursive parsing. This allows the platform to obtain the dependency information of the target page without setting up a local environment, achieving page dependency parsing with zero local cloning. At the same time, it can quickly output the complete dependency information of the target page based on the precise mapping logic and recursive parsing actions, ensuring that no dependency information is missed. The entire process locates and pulls files on demand, without downloading the complete code repository, effectively reducing network transmission traffic and resource consumption, and significantly improving the efficiency of page dependency parsing in remote scenarios.

[0038] In one possible implementation, the aforementioned service platform can be the Chair cloud function platform built on a function-as-a-service (FaaS) architecture. This platform serves as a function-level backend service hosting and runtime environment platform, providing computing resources, runtime environment, and service hosting capabilities, and acts as the runtime carrier for various function tools. In the page dependency resolution methods provided in one or more embodiments of this specification, all functional modules used to implement page dependency resolution can be deployed on the service platform in the form of function tools. These function tools can include general-purpose function tools provided by the service platform and custom function tools defined by developers.

[0039] Furthermore, the aforementioned service platform integrates LangGraph, a directed graph orchestration framework launched by the LangChain community. It defines complex workflows through directed graphs composed of "nodes" and "edges." Nodes can call large models, function tools, etc., to execute corresponding tasks, while edges define the flow rules between nodes. Through LangGraph, the entire process of page dependency resolution can be orchestrated into multiple pluggable functional nodes, forming a pipeline.

[0040] At the user-facing interaction level, the service platform is equipped with a front-end intelligent assistant (Agent) interface. This interface provides users with a visual operating environment.

[0041] For example, see Figure 1 , Figure 1 This is a schematic diagram of the interactive interface of a smart assistant provided for one or more embodiments of this specification. Figure 1 As shown, the left side of the interface is the Agent's interactive area, allowing users to directly input their parsing requirements, such as the page route to be parsed and the code repository address. After the user completes the input and clicks the "OK" button, the Agent can forward the user's request to the corresponding function tool module of the service platform, triggering the dependency parsing process. Simultaneously, the Agent can receive the parsing results returned by the service platform and visualize them in the "Code / Preview Interface" on the right. It can also output the parsing results to the downstream data processing model, achieving a full-link interaction between user request transmission, parsing result feedback, and downstream process integration.

[0042] In addition, users can also proactively initiate parsing requests to the Agent via chat messages, such as sending "Please help me parse the dependency information of the target page". After receiving the request, the Agent will guide the user to input key parameters such as the route of the page to be parsed and the code management platform, thereby starting the parsing process.

[0043] The following description, in conjunction with the accompanying drawings and application scenarios, illustrates the page dependency resolution method provided in one or more embodiments of this specification.

[0044] See Figure 2a , Figure 2a This is a flowchart illustrating a page dependency resolution method provided in one or more embodiments of this specification. Figure 2a As shown, the method may include steps S202 to S2010.

[0045] Step S202: Receive page dependency resolution request.

[0046] The page dependency resolution request includes the page route to be resolved and its corresponding code management platform.

[0047] For example, users can... Figure 1 The Agent interface shown initiates a page dependency resolution request. After entering information such as the route of the page to be resolved and the repository access address of the code management platform and confirming, the Agent can send the request to the service platform.

[0048] The route of the page to be parsed represents the user access path of the page to be parsed (i.e., the navigation path within the front-end application), and can also be called the uniform resource locator (URL) of the page to be parsed. The route is the unique identifier for locating the page to be parsed, and different routes correspond to different page code files in the code repository.

[0049] For example, users can enter a page route to be parsed in the form of a combination of characters such as / dashboard / index, where " / dashboard" represents the dashboard directory and " / index" represents the index page, which together correspond to the specific page "dashboard homepage" in the front-end application.

[0050] A code management platform is a remote code hosting platform that stores the code related to the page to be parsed, such as Ant Code, GitHub, and GitLab. For example, a user can enter the repository access address of the code management platform, such as https: / / code.....git, where the platform stores routing configuration files and page code files.

[0051] The routing configuration file records the correspondence between "page routes" and "page code file paths"; the page code file includes the source code file of the page to be parsed (such as .vue / .js files), which is the core object of dependency parsing.

[0052] Through step S202, the service platform can obtain the route of the page to be parsed and the repository access address of the corresponding code management platform, accurately determine the parsing target and code storage location, provide an accurate data foundation for subsequent on-demand retrieval of relevant files and execution of page dependency parsing, avoid network traffic and computing resource consumption caused by full cloning of the code library, and improve the efficiency and accuracy of page dependency parsing.

[0053] Step S204: Obtain the metadata of the route configuration file directory and the metadata of the page code file directory from the code management platform.

[0054] For example, step S204 can be executed by a function tool deployed on the Chair cloud function platform, specifically a function tool customized by the developer.

[0055] Function tools can call the standardized open interface of the code management platform (such as the tree interface of Ant Code OpenAPI) based on the received repository access address of the code management platform, send a request to the code management platform to "get the latest code version of the repository", and the code management platform will return the corresponding code identifier, such as the unique identifier of the latest version of the code management platform (HEAD commit sha). Each code version has a unique sha value, and a certain version of the code can be accurately located based on the code identifier.

[0056] Furthermore, the function tool can, based on the repository access address and code identifier of the code management platform, call the standardized open interface of the code management platform again. By setting the interface parameter depth=1 (only looking at the directory level, not traversing subfolders within the directory), it limits the retrieval to only the first-level directory structure, avoiding the fetching of the full directory data. Then, the function tool can filter and retrieve only the metadata of two types of core directories related to page dependency resolution: the metadata of the route configuration file (config) directory and the metadata of the page code file (pages) directory.

[0057] The metadata in the config directory and the pages directory can contain only basic information such as file identifiers (e.g., filename, SHA value), file path, file size, and file type. This keeps the network transmission size of the metadata small, enabling lightweight data retrieval.

[0058] Step S204 enables precise directory metadata retrieval operations using the function tools of the Chair cloud function platform. It retrieves only the basic information of the config and pages directories necessary for page dependency resolution, avoiding the large amount of network traffic and computing resource consumption caused by full codebase cloning. This significantly improves the efficiency of page dependency resolution and lays a lightweight data foundation for accurately locating the target page code file in the future.

[0059] Step S206: Based on the metadata of the route configuration file directory, obtain the mapping relationship between page routes and page code files.

[0060] In one possible implementation, see [reference] Figure 2b , Figure 2b This is a schematic diagram illustrating the process of obtaining the mapping relationship between page routes and page code files based on metadata of the route configuration file directory, as provided in one or more embodiments of this specification. Figure 2b As shown, step S206 may include the following steps S2062 to S2066.

[0061] Step S2062: Based on the file identifier of the configuration routing file, determine the file path of the configuration routing file from the metadata of the routing configuration file directory, and obtain the configuration routing file based on the file path.

[0062] Configuration routing files are files used in front-end frameworks (such as Bigfish, Umi, Ice, Rspress, etc.) to explicitly define routing rules. Examples include config / config.ts and config / routes.ts files in the config directory. Developers write the mapping relationship between page routes and corresponding code files in these files.

[0063] For example, based on the metadata of the config directory, the path of the configuration route file can be matched in the metadata according to the file identifier of the configuration route file.

[0064] Furthermore, the complete source code of the configuration routing file can be retrieved by calling the standardized open interface of the code management platform based on the file path. In this way, only the routing configuration files required for page dependency resolution are retrieved on demand, without any unnecessary file data transfer, which significantly reduces network resource consumption.

[0065] Step S2064: Parse the configuration routing file to obtain the configuration routing rules for all pages.

[0066] For example, the parsing capabilities of artificial intelligence can be used to perform syntax parsing and rule extraction on configuration routing files. For instance, all configuration routing rules written by the developer can be parsed from the configuration routing file, that is, the mapping relationship between page routes explicitly specified by the developer and their corresponding code files (e.g., / dashboard / index corresponds to src / pages / dashboard / index.tsx), and the parsed configuration routing rules can be organized into structured data.

[0067] Step S2066: Based on the configuration-based routing rules, obtain the mapping relationship between page routes and page code files.

[0068] In one possible implementation, the conventional routing rules of the platform where the page route to be parsed resides can be obtained, and the mapping relationship between the page route and the page code file can be obtained based on the configuration routing rules and the conventional routing rules.

[0069] Among them, the convention-based routing rules of the platform where the page route to be parsed is located refer to the routing matching rules predefined by the front-end framework on which the current front-end application depends. These rules do not have dedicated configuration files and need to be generated based on the front-end framework specifications.

[0070] Conventional routing rules can be based on the storage directory structure and file identifiers of page code files. For example, a front-end framework may pre-define that "the file dashboard / index.tsx in the pages folder corresponds to the / dashboard / index page route," eliminating the need for developers to manually write the association between routes and files. The framework can directly obtain the mapping relationship between page routes and code files based on this rule.

[0071] For example, a custom parsing plugin for the current front-end framework can be used to identify the conventional routing rules specific to that front-end framework. For instance, for the Bigfish front-end framework, the custom parsing plugin BigfishRouteVisitor can accurately identify the conventional routing rules based on directory structure and file identifiers, ensuring the accuracy of the mapping between page routes and page code files.

[0072] Furthermore, based on configuration-based routing rules and convention-based routing rules, the mapping relationship between page routes and page code files can be obtained.

[0073] For example, configuration-based routing rules and convention-based routing rules can be used as the basis for matching the page route to be parsed. For a single page route to be parsed, if there is a rule in the configuration-based routing rules that completely matches it, the page code file path specified by the developer in that rule is extracted; if there is a rule in the convention-based routing rules that matches it, the page code file path under the corresponding pages directory is deduced based on that rule.

[0074] In this system, configuration-based routing rules and convention-based routing rules are matched independently and do not interfere with each other. A successful match for either rule retrieves the corresponding page code file path. Finally, by integrating the matching results of all page routes to be parsed, a mapping relationship between page routes and page code files can be obtained. Specifically, this can be a structured mapping table of "page route → page code file path in the pages directory," with the format {" / dashboard / index": "src / pages / dashboard / index.tsx"}.

[0075] Step S206 parses the configuration-based and convention-based routing rules of the front-end framework, obtains the mapping relationship between page routes and page code files, improves the accuracy and efficiency of identifying the mapping relationship between page routes and code files in remote scenarios, and provides a unified and reliable file path basis for subsequent page dependency resolution.

[0076] Step S208: Based on the mapping relationship and the metadata of the page code file directory, obtain the target page code file corresponding to the page route to be parsed.

[0077] In one possible implementation, see [reference] Figure 2c , Figure 2c This is a flowchart illustrating the process of obtaining the target page code file corresponding to the page route to be parsed, based on mapping relationships and metadata of the page code file directory, as provided in one or more embodiments of this specification. Figure 2c As shown, step S208 may include the following steps S2082 to S2086.

[0078] Step S2082: Among all page routes, obtain the page routes related to the page route to be resolved, and use them as candidate page routes.

[0079] All page routes originate from the aforementioned mapping relationship between page routes and page code files. The page route to be parsed is the target page route (e.g., / dashboard / index) input by the user that requires dependency parsing. By performing association matching on all page routes in the mapping relationship, all page routes with path or semantic association with the page route to be parsed can be filtered out and used as candidate page routes. This ensures that the target route required by the user and its associated route range are covered, providing a complete basis for route selection for subsequent user confirmation.

[0080] Step S2084: Display candidate page routes on the interactive interface so that the user can determine the target page route based on the candidate page routes.

[0081] For example, step S2084 can be executed by an interaction node in the LangGraph workflow (such as the ConfirmNode node, which is a functional node in LangGraph used to handle human-computer interaction confirmation, and can realize functions such as data push, user operation reception, and standardized management of instruction flow). This interaction node can push the filtered candidate page route list to the Agent interaction interface, and support users to perform confirmation operations such as checking or deselecting candidate page routes. The interaction result is received by this node and synchronized to subsequent process nodes.

[0082] Users can select the page route to be parsed from the candidate page routes based on their actual page dependency resolution needs, and then designate it as the target page route. This interactive confirmation process effectively avoids misjudgments in route matching, ensuring the accuracy of subsequent file retrieval.

[0083] Step S2086: Based on the mapping relationship and the metadata of the page code file directory, obtain the target page code file corresponding to the target page route.

[0084] In one possible implementation, the target page code file corresponding to the target page route can be determined based on the mapping relationship. Based on the file identifier of the target page code file, the file path of the target page code file can be determined from the metadata of the page code file directory. Then, the target page code file can be obtained based on the file path.

[0085] For example, based on the mapping relationship between page routes and page code files, the basic information of the target page code file corresponding to the target page route can be directly matched, including file identifier, file path, etc. The file identifier is the unique identification information of the target page code file in the code repository (such as file ID, SHA value, hash value, etc.). Searching based on the file identifier allows for precise matching of the file path of the target page code file (e.g., src / pages / dashboard / index.tsx) from the metadata of the pages directory. Then, based on this file path, the standardized open interface of the code management platform (such as the raw file interface of Ant Code OpenAPI) can be called to retrieve the complete source code of the target page code file as needed.

[0086] Among them, the raw file interface request supports Range request. Range request is a segmented file retrieval mechanism based on the HyperText Transfer Protocol (HTTP). By specifying the Range field in the request header (such as Range: bytes=0-1024), the range of file content to be retrieved can be precisely limited, instead of retrieving the entire file content by default.

[0087] Step S208 enables precise filtering of target page routes, user interaction confirmation, and targeted acquisition of target code files based on the mapping relationship between page routes and page code files, as well as the metadata of the page code file directory. The accuracy of route matching is ensured through candidate route filtering and manual confirmation driven by LangGraph interaction nodes. The Range request mechanism allows only the complete source code of the target page code file to be retrieved, reducing the amount of file data retrieved in a single transaction. Compared to cloning the entire codebase or retrieving the complete file, this significantly reduces network traffic consumption and the computational resource usage of the service platform, while ensuring the accuracy and completeness of the target page code file acquisition.

[0088] Step S2010: Recursively parse the target page code file to obtain the dependency information of the page to be parsed.

[0089] In one possible implementation, see [reference] Figure 2d , Figure 2d This is a flowchart illustrating the process of recursively parsing a target page code file to obtain the dependency information of the page to be parsed, as provided in one or more embodiments of this specification. Figure 2d As shown, step S2010 may include the following steps S20102 to S20106.

[0090] Step S20102: Parse the target page code file into an abstract syntax tree (AST).

[0091] AST is a structured representation of the code logic in the target page code file. Parsing the target page code file into an AST means converting the text content of the code into a tree-like node structure that can be recognized by machines.

[0092] For example, a code parser, such as the syntax parsing library @babel / parser, can be used to convert target page code files in formats such as JavaScript, TypeScript, JSX, and TSX into a machine-readable and traversable Abstract Syntax Tree (AST). The AST includes the import nodes of the target page, which can include at least one of static import nodes, dynamic import nodes, and conventional import nodes.

[0093] Among them, static import nodes correspond to the static import statements written by the developer, dynamic import nodes correspond to the dynamic import statements written by the developer, and conventional import nodes correspond to the import logic related to conventional routing in the front-end framework. For example, conventional routing front-end frameworks pre-define specially named page files such as $layout.tsx and $index.tsx. The front-end framework will automatically generate the association between routes and pages based on the naming rules of these files (i.e., the default import rules), without requiring developers to manually write import or route configuration code.

[0094] Step S20104: Recursively scan the import nodes in the abstract syntax tree to obtain the dependent files and dependency relationships of the target page code file.

[0095] In one possible implementation, the import nodes in the abstract syntax tree can be recursively scanned to obtain the direct dependent files of the target page code file, and the direct dependency relationship between the target page code file and the direct dependent files can be obtained.

[0096] Recursive scanning refers to traversing the tree structure of all import nodes layer by layer, starting from the root node of the AST, to identify the dependent files corresponding to all import statements. Direct dependent files are code files directly referenced by the target page code files through statements such as `import` and `import()` (e.g., `src / components / Header.tsx`, the antd component library, etc.), and do not include other files referenced by the dependent files. A direct dependency relationship represents the "direct reference" association between the target page code file and the direct dependent file. For example, it can be expressed as: the file `src / pages / dashboard / index.tsx` references the file `src / components / Header.tsx`, clearly demonstrating the direct reference logic between the two.

[0097] Furthermore, after obtaining the direct dependency files of the target page code file, it is possible to query whether the cache file stores the dependency information of the direct dependency files based on the file identifier of the direct dependency files.

[0098] Among them, the cache file is a global file dependency cache built on Redis. Redis is an open-source, high-performance key-value database with memory-level data read and write speeds (millisecond-level response), supports multiple data structures, and allows setting data expiration policies. It can be used as a high-frequency access cache storage medium. By building a global cache based on Redis, it is possible to achieve fast access and distributed sharing of dependency information.

[0099] For example, the SHA256 value of a directly dependent file can be used as the cache key in Redis, i.e., RedisKey = sha256(fileContent). Here, SHA256 is a cryptographic hash algorithm that can convert file content of any length into a unique 256-bit hash value. `fileContent` represents the complete original text content of the code file. Using the SHA256 value as the Redis key ensures that files with the same content correspond to a unique cache key, avoiding cache invalidation due to file name changes or path adjustments. Simultaneously, setting the cache value associated with the SHA256 value to the already parsed dependency information of the file enables efficient retrieval of dependency information, avoiding repeated AST recursive parsing operations on the same file.

[0100] Furthermore, if the cache file stores the dependency information of the direct dependent files, then the dependency information of the direct dependent files is obtained from the cache file, and the dependent files and dependency relationships of the target page code file are obtained based on the dependency information of the direct dependent files.

[0101] The cached file stores dependency information for direct dependency files, including all already parsed dependency files and their corresponding dependencies. Therefore, there's no need to repeatedly perform AST parsing on the direct dependency file; the cached dependency information can be reused to quickly obtain the complete dependency files and relationships of the target page, improving the efficiency of page dependency parsing.

[0102] If the cached file does not store the dependency information of the direct dependent files, the file path of the direct dependent files is obtained from the metadata of the page code file directory based on the file identifier of the direct dependent files, and the direct dependent files are obtained based on the file path.

[0103] The metadata of the page code file directory, namely the structured information of the pages directory (including file identifiers, file paths, file sizes, file types, etc. of all files), can accurately match the file paths of directly dependent files by using the file identifiers of directly dependent files as search criteria. Then, the raw file interface of Ant Code OpenAPI can be called to retrieve the complete source code of the directly dependent file on demand through the Range request, precisely limiting the range of file content to be retrieved.

[0104] Furthermore, the direct dependency files can be recursively parsed as described above to obtain the parsing results, which are then stored in a cache file. These parsing results include the indirect dependency files of the target page code file, as well as the indirect dependency relationships between the direct and indirect dependency files.

[0105] Indirect dependencies are files that are indirectly referenced by the target page's code files through direct dependencies (e.g., if the target page depends on the Header.tsx file, and the Header.tsx file depends on the Button.tsx file, then the Button.tsx file is an indirect dependency of the target page). An indirect dependency relationship is a reference relationship between direct and indirect dependent files.

[0106] The above recursive parsing is performed on the directly dependent files, that is, the process of "parsing the file into an AST → scanning the import node → obtaining the dependent files and dependency relationships" is repeated until there are no new dependent files in the parsing results. The parsing results can then be obtained and stored in the cache file.

[0107] For example, when storing parsing results in a cache file, an expiration time (TTL), such as 7 days, can be set to balance cache reusability and data timeliness. Furthermore, since Redis has limited memory, when cached data fills up memory, data can be cleaned up according to the least recently used (LRU) rule, prioritizing the retention of most frequently used cached data.

[0108] Furthermore, dependency files can be obtained based on direct and indirect dependency files, and dependency relationships can be obtained based on direct and indirect dependency relationships.

[0109] If no new dependency files are found in the parsing results, the dependency graph has reached a convergence state. At this point, all dependency links of the target page have been traversed, and direct and indirect dependency files can be integrated to form a complete set of dependency files for the target page. Furthermore, direct and indirect dependencies can be integrated to form a complete dependency link for the target page.

[0110] Step S20106: Based on the dependency files and dependency relationships, obtain the dependency information of the page to be parsed.

[0111] The dependency information of the page to be parsed is standardized data that organizes the set of dependency files and the dependency relationship chain. It can include the file paths, file association levels, and referencing methods of all static dependencies, dynamic dependencies, and front-end framework-defined dependencies of the page to be parsed.

[0112] Step S2010 enables the full and complete identification of the target page's code file dependencies. Simultaneously, it combines a global file caching mechanism to achieve second-level reuse of parsed dependency information, avoiding repeated file fetching and parsing operations, and significantly saving computing and network transmission resources. Furthermore, the parsing process covers static imports, dynamic imports, and front-end framework convention imports, ensuring the completeness and accuracy of dependency information.

[0113] Furthermore, in one possible implementation, after obtaining the dependency information of the page to be parsed, the dependency information of the page to be parsed can be encapsulated into standardized data.

[0114] For example, standardized data can be encapsulated in a uniform JSON structured format.

[0115] For example, standardized data containing dependency information can be output in the following JSON format: { "path": "src / pages / home / index.tsx", "content": "import ... ", "dependencies": [ "antd", ], } Here, "path" is the storage path of the page code file corresponding to the page to be parsed in the code repository; "content" is the original text of the page code file ("import ..." is the abbreviation of the code content), which includes all import statements, logic code, etc. of the page; "dependencies" is the full list of dependent files of the target page obtained after recursive parsing, which can distinguish between direct and indirect dependent files; "antd" is the third-party UI component library that the target page directly depends on. In actual applications, it may also include the file path inside the front-end application, such as "src / components / Header.tsx".

[0116] Furthermore, in one possible implementation, the aforementioned standardized data can be displayed on the interactive interface.

[0117] See Figure 3 , Figure 3 This is a schematic diagram of the interactive interface of another intelligent assistant provided in one or more embodiments of this specification. Figure 3 As shown, the service platform receives the user's input of the page route to be parsed ( / dashboard / index) and the repository access address of the code management platform (https: / / code.....git) through the Agent interaction interface. After completing the dependency parsing, it can encapsulate the dependency information of the target page into standardized JSON data and display it on the interaction interface, so that users can intuitively verify the completeness and accuracy of the dependency parsing results.

[0118] In practical applications, service platforms can display the dependency information of the page to be parsed in various visual formats, such as tree lists and tables, according to the user's viewing needs. For example, for the dependencies field in JSON data, the hierarchical relationship between direct and indirect dependencies can be presented through a tree list, or the dependency name, dependency type, reference path, and other information can be clearly listed in a table.

[0119] In one possible implementation, standardized data can be input into a data processing model so that the model processes the standardized data based on preset rules.

[0120] The data processing model can adopt a large language model (LLM). After standardized data is input into the data processing model, the standardized data can be directly used as the context of prompt words, so that the data processing model can rewrite the code of the standardized data based on preset rules.

[0121] For example, preset rules can be formulated according to the front-end framework migration scenario. For instance, preset rules could be: based on the full dependency list in the dependencies field of standardized data, identify and remove proprietary dependency references in the original code that are adapted to the initial front-end framework (such as the initial front-end framework's convention-based routing file, proprietary component libraries, and customized APIs), and complete the adaptation and rewriting according to the target front-end framework's syntax specifications. For example, replace the initial front-end framework's proprietary route definition method with the target front-end framework's route registration rules, rewrite the request methods encapsulated by the initial front-end framework into general request logic compatible with the target front-end framework, and adjust the initial front-end framework's proprietary component import method to the target front-end framework's component reference specifications, etc.

[0122] The data processing model combines page paths, original code content, and full dependency information from standardized data to accurately locate code snippets related to the initial front-end framework. It then completes a full rewrite according to preset framework migration rules, ultimately outputting code files adapted to the target front-end framework. This eliminates the need for manual sorting of dependencies and adjustment of syntax logic, significantly improving the efficiency and accuracy of migrating front-end code from the initial front-end framework to the target front-end framework.

[0123] In one possible implementation, see [reference] Figure 4 , Figure 4 This is a flowchart illustrating another page dependency resolution method provided in one or more embodiments of this specification. Figure 4 As shown, the method mainly includes the following steps S401 to S4019.

[0124] Step S401: Obtain the page dependency resolution request input by the user through the interactive interface; Step S402: The interactive interface sends the page dependency resolution request to the service platform; Step S403: The service platform obtains the metadata of the route configuration file directory and the metadata of the page code file directory from the code management platform; Step S404: The service platform obtains the mapping relationship between page routes and page code files based on the metadata of the route configuration file directory; Step S405: The service platform obtains the page routes related to the page routes to be parsed as candidate page routes; Step S406: The service platform sends the candidate page route to the interactive interface; Step S407: The interactive interface displays candidate page routes, and the target page route is determined based on the user's selection; Step S408: The interactive interface sends the target page route to the service platform; Step S409: The service platform obtains the target page code file corresponding to the target page route based on the mapping relationship and the metadata of the page code file directory; Step S4010: The service platform recursively parses the target page code file, that is, it parses the target page code file into an abstract syntax tree, and recursively scans the import nodes in the abstract syntax tree to obtain the direct dependency files of the target page code file, and obtains the direct dependency relationship between the target page code file and the direct dependency files. Step S4011: The service platform queries the cache file to see if the dependency information of the direct dependent file is stored based on the file identifier of the direct dependent file; Further, if the cache file stores dependency information of directly dependent files, then step S4012 is executed; if the cache file does not store dependency information of directly dependent files, then step S4013 is executed.

[0125] Step S4012: The service platform obtains the dependency information of the direct dependency files from the cache files, and obtains the dependency files and dependency relationships of the target page code file based on the dependency information of the direct dependency files; further, step S4016 is executed.

[0126] Step S4013: The service platform obtains the direct dependency files and recursively parses them to obtain the parsing results; Step S4014: The service platform stores the parsing results in a cache file; Step S4015: The service platform determines whether there are any new dependency files in the parsing results; Furthermore, if a new dependency file exists in the parsing result, return to step S4010 to recursively parse the new dependency file; if no new dependency file exists in the parsing result, proceed to step S4016.

[0127] Step S4016: The service platform encapsulates the dependency information of the page to be parsed into standardized data; Step S4017: The service platform sends standardized data to the interactive interface; Step S4018: The interactive interface displays the standardized data; Step S4019: The service platform inputs standardized data into the data processing model so that the data processing model processes the standardized data based on preset rules.

[0128] The page dependency resolution method provided in one or more embodiments of this specification achieves on-demand, cached, and second-level static dependency resolution for target pages in remote code repositories by deeply integrating Chair cloud functions with LangGraph. This method relies on the isolated sandbox environment of Chair cloud functions (i.e., an independent and restricted execution environment for code execution, where the service platform only grants necessary network access and computing permissions, preventing code leakage or unauthorized operations), ensuring that the relevant code flows securely within this sandbox throughout the entire process. It forms a lightweight dependency resolution process for remote code repositories with zero local cloning, on-demand I / O, file-level caching, and AST recursion. Through the standardized open interfaces and Range requests of the code management platform, it achieves accurate retrieval of target page code files, significantly reducing network traffic (e.g., from GB to KB). The Redis file-level caching mechanism avoids repeated AST recursive resolution, greatly saving computing resources. Through comprehensive analysis of configuration-based and convention-based routing rules, it ensures the accuracy of the mapping between page routes and page code files.

[0129] Meanwhile, the overall parsing process is broken down into multiple independent functional nodes, such as obtaining metadata of the config directory and pages directory, parsing the mapping relationship between page routes and page code files, user confirmation of target page routes, reading of target page code files, and AST recursive scanning. These nodes are uniformly orchestrated and scheduled by LangGraph in a pipeline manner, enabling nodes to pass file identifiers and dependency graph data through status information. Furthermore, each node adopts a modular design, supports plug-and-play, and can be updated, replaced, or extended individually without affecting the overall parsing process.

[0130] In practical applications, users only need to enter the repository access address of the code management platform and specify the route of the page to be parsed. The service platform can output the dependency information of the page within seconds. The entire process does not depend on the local environment. It can flexibly adapt to various front-end framework migration scenarios and has high versatility and scalability.

[0131] The above describes the page dependency resolution method provided in one or more embodiments of this specification.

[0132] It is understood that the above embodiments are merely examples, and modifications can be made to the above embodiments in actual implementation. Those skilled in the art will understand that any modifications to the above embodiments that do not require creative effort fall within the protection scope of one or more embodiments of this specification, and will not be described again in the embodiments.

[0133] Based on the same inventive concept, one or more embodiments of this specification also provide a page-dependent parsing device. Since the principle of the page-dependent parsing device in solving the problem is similar to that of the aforementioned page-dependent parsing method, the implementation of the page-dependent parsing device can refer to the implementation of the aforementioned page-dependent parsing method, and the repeated parts will not be described again.

[0134] See Figure 5 , Figure 5 This is a structural block diagram of a page-dependent parsing apparatus provided for one or more embodiments of this specification. Figure 5 As shown, the page dependency parsing device 500 applied to the service platform may include: a receiving module 501, a first acquisition module 502, a second acquisition module 503, a third acquisition module 504, and a parsing module 505.

[0135] The receiving module 501 is used to receive page dependency resolution requests, which include the page route to be resolved and its corresponding code management platform; the page route to be resolved represents the user access path of the page to be resolved, and the code management platform stores the route configuration file and the page code file.

[0136] The first acquisition module 502 is used to acquire metadata of the route configuration file directory and the page code file directory from the code management platform.

[0137] The second acquisition module 503 is used to obtain the mapping relationship between page routes and page code files based on the metadata of the route configuration file directory.

[0138] The third acquisition module 504 is used to obtain the target page code file corresponding to the page route to be parsed based on the mapping relationship and the metadata of the page code file directory.

[0139] Parsing module 505 is used to recursively parse the target page code file to obtain the dependency information of the page to be parsed.

[0140] In one possible implementation, the metadata of the routing configuration file directory includes the file identifier and file path within the routing configuration file directory; The second acquisition module 503 is used to: determine the file path of the configuration route file from the metadata of the route configuration file directory based on the file identifier of the configuration route file, and obtain the configuration route file based on the file path; parse the configuration route file to obtain the configuration route rules for all pages; and obtain the mapping relationship between page routes and page code files based on the configuration route rules.

[0141] In one possible implementation, the second acquisition module 503 is used to acquire the conventional routing rules of the platform where the page route to be parsed is located; and based on the configuration routing rules and the conventional routing rules, to obtain the mapping relationship between the page route and the page code file.

[0142] In one possible implementation, the service platform includes an interactive interface; The third acquisition module 504 is used to: acquire page routes related to the page route to be parsed from all page routes, as candidate page routes; display the candidate page routes on the interactive interface so that the user can determine the target page route based on the candidate page routes; and acquire the target page code file corresponding to the target page route based on the mapping relationship and the metadata of the page code file directory.

[0143] In one possible implementation, the metadata of the page code file directory includes the file identifier and file path within the page code file directory; The third acquisition module 504 is used to: determine the target page code file corresponding to the target page route based on the mapping relationship; determine the file path of the target page code file from the metadata of the page code file directory based on the file identifier of the target page code file; and obtain the target page code file based on the file path.

[0144] In one possible implementation, the parsing module 505 is used to parse the target page code file into an abstract syntax tree, the abstract syntax tree including import nodes of the target page, the import nodes including at least one of static import nodes, dynamic import nodes and conventional import nodes; recursively scan the import nodes in the abstract syntax tree to obtain the dependent files and dependency relationships of the target page code file; and obtain the dependency information of the page to be parsed based on the dependent files and dependency relationships.

[0145] In one possible implementation, the parsing module 505 is used to recursively scan the import nodes in the abstract syntax tree to obtain the direct dependent files of the target page code file and the direct dependency relationship between the target page code file and the direct dependent files; based on the file identifier of the direct dependent files, query whether the dependency information of the direct dependent files is stored in the cache file; if so, retrieve the dependency information of the direct dependent files from the cache file, and obtain the dependent files and dependency relationships of the target page code file based on the dependency information of the direct dependent files.

[0146] In one possible implementation, the parsing module 505 is further configured to, if the cache file does not store the dependency information of the direct dependent file, obtain the file path of the direct dependent file from the metadata of the page code file directory based on the file identifier of the direct dependent file, and obtain the direct dependent file based on the file path; The direct dependency files are recursively parsed to obtain the parsing results, which are then stored in a cache file. The parsing results include the indirect dependency files of the target page code file, as well as the indirect dependency relationships between the direct dependency files and the indirect dependency files. If no new dependent files are found in the parsing results, the dependent files are obtained based on the direct and indirect dependent files, and the dependency relationships are obtained based on the direct and indirect dependency relationships.

[0147] One possible implementation is, such as Figure 5 As shown, the page-dependent parsing unit 500 also includes an encapsulation module 506, a display module 507, and / or a processing module 508; among which, The encapsulation module 506 is used to encapsulate the dependency information of the page to be parsed into standardized data.

[0148] The display module 507 is used to display standardized data on the interactive interface.

[0149] The processing module 508 is used to input standardized data into the data processing model so that the data processing model processes the standardized data based on preset rules.

[0150] Based on the same inventive concept, one or more embodiments of this specification also provide an electronic device.

[0151] See Figure 6 , Figure 6 This is a structural block diagram of an electronic device provided for one or more embodiments of this specification. Figure 6 As shown, the electronic device 600 may include a processor 601 and a memory 602; the memory 602 may be coupled to the processor 601. It is worth noting that... Figure 6This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0152] In one possible implementation, the page dependency resolution functionality can be integrated into the processor 601. The processor 601 can be configured to perform the following operations: The system receives page dependency resolution requests, which include the page route to be resolved and its corresponding code management platform. The page route to be resolved represents the user access path of the page to be resolved, and the code management platform stores the route configuration file and the page code file. Obtain metadata from the route configuration file directory and the page code file directory from the code management platform; Based on the metadata of the route configuration file directory, obtain the mapping relationship between page routes and page code files; Based on the mapping relationship and the metadata of the page code file directory, obtain the target page code file corresponding to the page route to be parsed; The target page code file is recursively parsed to obtain the dependency information of the page to be parsed.

[0153] In another possible implementation, the page dependency parser 500 can be configured separately from the processor 601. For example, the page dependency parser 500 can be configured as a chip connected to the processor 601, and the page dependency parsing method can be implemented through the control of the processor 601.

[0154] In one possible implementation, the plurality of processors 601 may be processors deployed on the same device. For example, the electronic device may be a high-performance device composed of multiple processors, and the plurality of processors 601 may be processors configured on the high-performance device.

[0155] In another possible implementation, the aforementioned multiple processors 601 may also be processors deployed on different devices. For example, the aforementioned electronic device may be a server cluster, and the aforementioned multiple processors 601 may be processors on different servers in the server cluster.

[0156] Furthermore, in some alternative implementations, the electronic device 600 may also include: a communication module, an input unit, an audio processor, a display, a power supply, etc. It is worth noting that the electronic device 600 is not necessarily required to include these components. Figure 6 All components shown; in addition, the electronic device 600 may also include Figure 6 For components not shown, please refer to existing technologies.

[0157] In some alternative implementations, the processor 601, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives input and controls the operation of various components of the electronic device 600.

[0158] The memory 602 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned information related to the file manipulation device 400 used in modern browsers, and may also store programs for executing that information. The processor 601 may execute the program stored in the memory 602 to perform information storage or processing, etc.

[0159] An input unit can provide input to the processor 601. This input unit may be, for example, a button or touch input device. A power supply can be used to provide power to the electronic device 600. A display can be used to display images and text, etc. This display may be, for example, an LCD display, but is not limited to this.

[0160] Memory 602 can be a solid-state memory, such as read-only memory (ROM), random access memory (RAM), SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROM, etc. Memory 602 can also be some other type of device. Memory 602 includes buffer memory (sometimes referred to as a buffer). Memory 602 may include an application / function storage unit for storing application programs and function programs or processes for executing the operation of electronic device 600 via processor 601.

[0161] The memory 602 may also include a data storage unit for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit of the memory 602 may include various drivers for the computer device for communication functions and / or for performing other functions of the computer device (such as messaging applications, address book applications, etc.).

[0162] The communication module is a transmitter / receiver that sends and receives signals via an antenna. The communication module (transmitter / receiver) is coupled to the processor 601 to provide input signals and receive output signals, which can be the same as in a conventional mobile communication terminal.

[0163] Based on different communication technologies, multiple communication modules can be configured in the same computer device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication modules (transmitters / receivers) are also coupled to speakers and microphones via an audio processor to provide audio output through the speakers and receive audio input from the microphones, thereby enabling typical telecommunications functions. The audio processor may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor is coupled to processor 601, enabling on-device recording via the microphone and on-device playback of stored sound via the speakers.

[0164] One or more embodiments of this specification also provide a computer-readable storage medium capable of implementing all steps of the page dependency resolution method in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the page dependency resolution method in the above embodiments. For example, when the processor executes the computer program, it implements the following steps: The system receives page dependency resolution requests, which include the page route to be resolved and its corresponding code management platform. The page route to be resolved represents the user access path of the page to be resolved, and the code management platform stores the route configuration file and the page code file. Obtain metadata from the route configuration file directory and the page code file directory from the code management platform; Based on the metadata of the route configuration file directory, obtain the mapping relationship between page routes and page code files; Based on the mapping relationship and the metadata of the page code file directory, obtain the target page code file corresponding to the page route to be parsed; The target page code file is recursively parsed to obtain the dependency information of the page to be parsed.

[0165] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive labor. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual device or client product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0166] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, apparatus (systems), or computer program products. Therefore, the embodiments of this specification can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, one or more embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0167] This specification describes one or more embodiments of a method, apparatus (system), and computer program product according to one or more embodiments of this specification with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0168] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0169] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0170] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and system embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0171] In this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, without necessarily requiring or implying any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Those skilled in the art will understand the specific meaning of the above terms in one or more embodiments of this specification, depending on the specific circumstances.

[0172] It should be noted that, unless otherwise specified, one or more embodiments and features thereof in this specification can be combined with each other. This specification is not limited to any single aspect, nor to any single embodiment, nor to any combination and / or substitution of such aspects and / or embodiments. Furthermore, each aspect and / or embodiment of one or more embodiments of this specification can be used alone or in combination with one or more other aspects and / or embodiments thereof.

[0173] The above embodiments are only used to illustrate the technical solutions of one or more embodiments of this specification, and are not intended to limit them. Although one or more embodiments of this specification have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of one or more embodiments of this specification, and they should all be covered within the scope of the claims and the specification of one or more embodiments of this specification.

[0174] The foregoing description of one or more embodiments of this specification has been provided in conjunction with optional implementation methods. However, these embodiments are merely exemplary and serve only an illustrative purpose. Based on this, various substitutions and modifications can be made to one or more embodiments of this specification, all of which fall within the protection scope of one or more embodiments of this specification.

[0175] Finally, it should be noted that the relevant user personal information that may be involved in one or more embodiments of this specification is processed in strict accordance with the requirements of laws and regulations, following the principles of legality, legitimacy, and necessity, based on the reasonable purpose of the service scenario, and is personal information that users actively provide or that is generated due to the use of the product / service, as well as personal information obtained with user authorization.

Claims

1. A method for resolving page dependencies, characterized in that, Applied to a service platform, the method includes: The system receives a page dependency resolution request, which includes the page route to be resolved and its corresponding code management platform; wherein the page route to be resolved represents the user access path of the page to be resolved, and the code management platform stores route configuration files and page code files; Obtain metadata of the route configuration file directory and metadata of the page code file directory from the code management platform; Based on the metadata of the routing configuration file directory, obtain the mapping relationship between page routes and page code files; Based on the mapping relationship and the metadata of the page code file directory, obtain the target page code file corresponding to the page route to be parsed; The target page code file is recursively parsed to obtain the dependency information of the page to be parsed.

2. The page dependency resolution method according to claim 1, characterized in that, The metadata of the routing configuration file directory includes the file identifier and file path in the routing configuration file directory; The step of obtaining the mapping relationship between page routes and page code files based on the metadata of the route configuration file directory includes: Based on the file identifier of the configuration routing file, the file path of the configuration routing file is determined from the metadata of the routing configuration file directory, and the configuration routing file is obtained based on the file path; The configuration routing file is parsed to obtain the configuration routing rules for all pages; Based on the configuration-based routing rules, the mapping relationship between the page routes and the page code files is obtained.

3. The page dependency resolution method according to claim 2, characterized in that, The process of obtaining the mapping relationship between the page routes and the page code files based on the configuration routing rules includes: Obtain the conventional routing rules of the platform where the route of the page to be parsed is located; Based on the configuration-based routing rules and the convention-based routing rules, the mapping relationship between the page routes and the page code files is obtained.

4. The page dependency resolution method according to claim 1, characterized in that, The service platform includes an interactive interface; the step of obtaining the target page code file corresponding to the page route to be parsed based on the mapping relationship and the metadata of the page code file directory includes: Among all page routes, obtain the page routes related to the page route to be parsed, and use them as candidate page routes; The candidate page routes are displayed on the interactive interface so that the user can determine the target page route based on the candidate page routes. Based on the mapping relationship and the metadata of the page code file directory, obtain the target page code file corresponding to the target page route.

5. The page dependency resolution method according to claim 4, characterized in that, The metadata of the page code file directory includes the file identifier and file path in the page code file directory; The step of obtaining the target page code file corresponding to the target page route based on the mapping relationship and the metadata of the page code file directory includes: Based on the mapping relationship, the target page code file corresponding to the target page route is determined; Based on the file identifier of the target page code file, the file path of the target page code file is determined from the metadata of the page code file directory; The target page code file is obtained based on the file path.

6. The page dependency resolution method according to claim 5, characterized in that, The recursive parsing of the target page code file to obtain the dependency information of the page to be parsed includes: The target page code file is parsed into an abstract syntax tree; the abstract syntax tree includes import nodes of the target page, and the import nodes include at least one of static import nodes, dynamic import nodes, and conventional import nodes; The import nodes in the abstract syntax tree are recursively scanned to obtain the dependent files and dependencies of the target page code file. Based on the dependency files and the dependency relationships, the dependency information of the page to be parsed is obtained.

7. The page dependency resolution method according to claim 6, characterized in that, The recursive scanning of the import nodes in the abstract syntax tree to obtain the dependency files and dependency relationships of the target page code file includes: The import nodes in the abstract syntax tree are recursively scanned to obtain the direct dependency files of the target page code file, and the direct dependency relationship between the target page code file and the direct dependency files is obtained. Based on the file identifier of the directly dependent file, query whether the dependency information of the directly dependent file is stored in the cache file; If so, the dependency information of the directly dependent files is obtained from the cache file, and the dependent files and dependency relationships of the target page code file are obtained based on the dependency information of the directly dependent files.

8. The page dependency resolution method according to claim 7, characterized in that, The method further includes: If the cache file does not store the dependency information of the direct dependent file, then based on the file identifier of the direct dependent file, the file path of the direct dependent file is obtained from the metadata of the page code file directory, and the direct dependent file is obtained based on the file path; The direct dependency files are recursively parsed to obtain the parsing results, and the parsing results are stored in the cache file; wherein, the parsing results include the indirect dependency files of the target page code file, and the indirect dependency relationships between the direct dependency files and the indirect dependency files; If no new dependent files are found in the parsing results, the dependent files are obtained based on the direct and indirect dependent files, and the dependency relationships are obtained based on the direct and indirect dependency relationships.

9. The page dependency resolution method according to claim 4, characterized in that, After obtaining the dependency information of the page to be parsed, the method further includes: The dependency information of the page to be parsed is encapsulated into standardized data; The standardized data is displayed on the interactive interface, and / or the standardized data is input into the data processing model so that the data processing model processes the standardized data based on preset rules.

10. A page-dependent parsing apparatus, characterized in that, The device, applied to a service platform, includes: The receiving module is used to receive page dependency resolution requests, which include the page route to be resolved and its corresponding code management platform; wherein, the page route to be resolved represents the user access path of the page to be resolved, and the code management platform stores route configuration files and page code files; The first acquisition module is used to acquire metadata of the route configuration file directory and metadata of the page code file directory from the code management platform. The second acquisition module is used to acquire the mapping relationship between page routes and page code files based on the metadata of the route configuration file directory; The third acquisition module is used to acquire the target page code file corresponding to the page route to be parsed based on the mapping relationship and the metadata of the page code file directory; The parsing module is used to recursively parse the target page code file to obtain the dependency information of the page to be parsed.

11. The page-dependent parsing apparatus according to claim 10, characterized in that, The metadata of the routing configuration file directory includes the file identifier and file path in the routing configuration file directory; The second acquisition module is used to acquire the mapping relationship between page routes and page code files based on the metadata of the route configuration file directory, including: The second acquisition module is used to determine the file path of the configuration routing file from the metadata of the routing configuration file directory based on the file identifier of the configuration routing file, and acquire the configuration routing file based on the file path; The configuration routing file is parsed to obtain the configuration routing rules for all pages; based on the configuration routing rules, the mapping relationship between the page routes and the page code files is obtained.

12. The page-dependent parsing apparatus according to claim 11, characterized in that, The second acquisition module is used to obtain the mapping relationship between the page route and the page code file based on the configuration routing rules, including: The second acquisition module is used to acquire the conventional routing rules of the platform where the page route to be parsed is located; and based on the configuration routing rules and the conventional routing rules, to obtain the mapping relationship between the page route and the page code file.

13. The page-dependent parsing apparatus according to claim 10, characterized in that, The service platform includes an interactive interface; The third acquisition module is used to acquire the target page code file corresponding to the page route to be parsed based on the mapping relationship and the metadata of the page code file directory, including: The third acquisition module is used to: acquire, from all page routes, page routes related to the page route to be parsed, as candidate page routes; display the candidate page routes on the interactive interface so that the user can determine the target page route based on the candidate page routes; and acquire the target page code file corresponding to the target page route based on the mapping relationship and the metadata of the page code file directory.

14. The page-dependent parsing apparatus according to claim 13, characterized in that, The metadata of the page code file directory includes the file identifier and file path in the page code file directory; The third acquisition module is used to acquire the target page code file corresponding to the target page route based on the mapping relationship and the metadata of the page code file directory, including: The third acquisition module is used to: determine the target page code file corresponding to the target page route based on the mapping relationship; determine the file path of the target page code file from the metadata of the page code file directory based on the file identifier of the target page code file; and obtain the target page code file based on the file path.

15. The page-dependent parsing apparatus according to claim 14, characterized in that, The parsing module is used to recursively parse the target page code file to obtain the dependency information of the page to be parsed, including: The parsing module is used to parse the target page code file into an abstract syntax tree, the abstract syntax tree including import nodes of the target page, the import nodes including at least one of static import nodes, dynamic import nodes and conventional import nodes; recursively scan the import nodes in the abstract syntax tree to obtain the dependent files and dependency relationships of the target page code file; and obtain the dependency information of the page to be parsed based on the dependent files and dependency relationships.

16. The page-dependent parsing apparatus according to claim 15, characterized in that, The parsing module is used to recursively scan the import nodes in the abstract syntax tree to obtain the dependency files and dependency relationships of the target page code file, including: The parsing module is used to recursively scan the import nodes in the abstract syntax tree to obtain the direct dependent files of the target page code file and the direct dependency relationship between the target page code file and the direct dependent files; based on the file identifier of the direct dependent file, query whether the dependency information of the direct dependent file is stored in the cache file; if so, obtain the dependency information of the direct dependent file from the cache file, and obtain the dependent files and dependency relationships of the target page code file based on the dependency information of the direct dependent file.

17. The page-dependent parsing apparatus according to claim 16, characterized in that, The parsing module is further configured to, if the cache file does not store the dependency information of the direct dependent file, obtain the file path of the direct dependent file from the metadata of the page code file directory based on the file identifier of the direct dependent file, and obtain the direct dependent file based on the file path; The direct dependency files are recursively parsed to obtain the parsing results, and the parsing results are stored in the cache file; wherein, the parsing results include the indirect dependency files of the target page code file, and the indirect dependency relationships between the direct dependency files and the indirect dependency files; If no new dependent files are found in the parsing results, the dependent files are obtained based on the direct and indirect dependent files, and the dependency relationships are obtained based on the direct and indirect dependency relationships.

18. The page-dependent parsing apparatus according to claim 13, characterized in that, The device also includes a packaging module, a display module, and / or a processing module; The encapsulation module is used to encapsulate the dependency information of the page to be parsed into standardized data; The display module is used to display the standardized data on the interactive interface; The processing module is used to input the standardized data into the data processing model, so that the data processing model processes the standardized data based on preset rules.

19. An electronic device, characterized in that, The electronic device includes: Memory, used to store computer program products; A processor for executing a computer program product stored in the memory, wherein when the computer program product is executed, it implements the page dependency resolution method described in any one of claims 1 to 9.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed, implement the page dependency resolution method according to any one of claims 1 to 9.

Images