Cross-framework code migration method and system, electronic equipment and storage medium

Abstract

The invention provides a cross-frame code migration method and system, electronic equipment and a storage medium, and the code migration method comprises the steps: carrying out the frame-level conversion of a first frame code, and generating a target engineering skeleton adaptive to a second frame protocol; analyzing the construction configuration and the entry file, determining an entry point and a compiling rule of code migration, analyzing the first frame code through an abstract syntax tree, and generating a target code range list needing to be migrated; and according to the target code range list and the dependency item list, applying a preset conversion rule to the first framework code, and generating a second framework code adaptive to a second framework protocol. Through automatic framework-level conversion and dynamic rule adaptation, rapid migration from the first framework code to the second framework code is realized, a multi-terminal code library is unified, the manpower development cost is reduced, synchronous operation of business iteration and migration is supported, and the development efficiency is improved.

Description

Technical Field

[0001] The present disclosure relates to the field of software development, and in particular to a cross-framework code migration method, system, electronic device, and storage medium. Background Art

[0002] In the field of cross-platform development, companies often use internally packaged cross-platform frameworks (such as secondary development frameworks based on React Native) to achieve code reuse on both terminals (iOS / Android). However, due to business differences, other terminals (such as H5 and mini-programs) need to independently maintain multiple sets of code, resulting in low development efficiency. In recent years, the industry has attempted to support unified development on multiple terminals through secondary packaging of open source multi-terminal frameworks (such as extension frameworks based on Taro), but existing technologies have significant drawbacks:

[0003] Framework-level barriers: Different encapsulation frameworks have fundamental differences in component specifications, API interfaces, and construction mechanisms. Directly porting code will result in runtime logic breaks.

[0004] Business continuity limitations: Traditional migrations require downtime and reconstruction, which cannot meet the needs of rapid business iteration;

[0005] Lack of ecological compatibility: Existing tools only support basic syntax conversion and cannot handle the secondary abstraction of native capabilities by the framework encapsulation layer.

[0006] The above problems require enterprises to maintain multiple code bases for a long time, which is costly and easily leads to the risk of version inconsistency. Summary of the Invention

[0007] The technical problem to be solved by the present disclosure is to overcome the defect in the prior art that the existing cross-framework migration solution cannot efficiently migrate multi-terminal codes without stopping business iteration, resulting in high maintenance costs, and to provide a cross-framework code migration method, system, electronic device and storage medium.

[0008] The present disclosure solves the above technical problems through the following technical solutions:

[0009] The present disclosure provides a cross-framework code migration method, the code migration method comprising:

[0010] Performing framework-level conversion on the first framework code to generate a target project skeleton adapted to the second framework protocol; the target project skeleton includes: build configuration, entry file, and dependency list;

[0011] Parsing the build configuration and the entry file to determine the entry point and compilation rules for code migration, and analyzing the first framework code through an abstract syntax tree to generate a target code range list to be migrated; the target code range list includes: code elements to be migrated in the first framework code and code element identifiers of corresponding functions in the second framework protocol;

[0012] According to the target code range list and the dependency list, preset conversion rules are applied to the first framework code to generate a second framework code adapted to the second framework protocol; wherein the preset conversion rules are dynamically adjusted based on the version compatibility of the dependency list.

[0013] Optionally, performing framework-level conversion on the first framework code to generate a target engineering skeleton adapted to the second framework protocol includes:

[0014] Replacing the construction tool chain of the first framework code with the construction tool chain corresponding to the second framework protocol, so that the first framework code adapts to the compilation rules of the second framework protocol;

[0015] Injecting the global configuration of the second framework protocol into the target project skeleton to generate the entry file adapted to multiple terminals;

[0016] Based on the dependency compatibility mapping table of the second framework protocol, the original dependency list of the first framework code is adapted to the corresponding version of the second framework protocol, and the dependency list is updated.

[0017] Optionally, the parsing of the build configuration and the entry file to determine the entry point and compilation rules for code migration, and the analysis of the first framework code through an abstract syntax tree to generate a list of target code ranges to be migrated include:

[0018] Traversing the routing configuration nodes of the first framework code through an abstract syntax tree to extract routing rules; the routing rules include: paths, parameters, and nested relationships;

[0019] In combination with a routing syntax specification of the second framework protocol, mapping the routing rule to a routing syntax adapted to the second framework protocol;

[0020] A routing configuration file is generated according to the construction configuration of the second framework protocol, and the routing configuration file is incorporated into the target code range list.

[0021] Optionally, the preset conversion rule includes at least one of the following:

[0022] Nested structure flattening rules, including converting style declarations based on compound attribute syntax or hierarchical nesting syntax in the first framework code into a flat object structure supported by the second framework protocol;

[0023] Style separation rules, including decoupling inline style declarations from component logic in the first framework code, extracting them into independent external style files, and establishing reference associations through a modular import mechanism;

[0024] The composite attribute standardization rule includes splitting the composite style attributes unique to the first framework code into independent dimension attributes common to the second framework protocol.

[0025] Optionally, applying a preset conversion rule to the first framework code according to the target code range list and the dependency list to generate a second framework code adapted to the second framework protocol includes:

[0026] Determining a mapping relationship between the first framework component identifier and the second framework protocol component identifier based on the first framework component identifier marked in the target code range list;

[0027] According to the component dependencies declared in the dependency list, replacing the first framework component reference with the adaptation layer component identifier of the second framework protocol during the compilation phase;

[0028] By dynamically calling the platform's underlying API of the second framework protocol, the adaptation layer components are ensured to be consistent with the rendering logic and device capability calls of the underlying framework.

[0029] Optionally, the preset conversion rule is dynamically adjusted based on the version compatibility of the dependency list, including:

[0030] Based on the dependency list, detecting compatibility between the version numbers of the dependencies in the first framework code and the version of the second framework protocol; and / or detecting availability of the API interfaces of the dependencies in the first framework code in the second framework protocol;

[0031] In response to detecting the incompatible and / or unavailable dependencies, an alarm is triggered and a downgrade strategy is generated, the downgrade strategy being based on compatibility rules of the second framework protocol.

[0032] The present disclosure provides a cross-framework code migration system, the code migration system comprising:

[0033] The framework module is used to perform framework-level conversion on the first framework code to generate a target project skeleton adapted to the second framework protocol; the target project skeleton includes: build configuration, entry files, and dependency list;

[0034] a parsing module, configured to parse the build configuration and the entry file, determine the entry point and compilation rules for code migration, and analyze the first framework code through an abstract syntax tree to generate a target code range list to be migrated; the target code range list includes: code elements to be migrated in the first framework code and code element identifiers of corresponding functions in the second framework protocol;

[0035] A migration module is used to apply preset conversion rules to the first framework code according to the target code range list and the dependency list to generate a second framework code adapted to the second framework protocol; wherein the preset conversion rules are dynamically adjusted based on the version compatibility of the dependency list.

[0036] Optionally, the framework module is specifically used to:

[0037] Replacing the construction tool chain of the first framework code with the construction tool chain corresponding to the second framework protocol, so that the first framework code adapts to the compilation rules of the second framework protocol;

[0038] Injecting the global configuration of the second framework protocol into the target project skeleton to generate the entry file adapted to multiple terminals;

[0039] Based on the dependency compatibility mapping table of the second framework protocol, the original dependency list of the first framework code is adapted to the corresponding version of the second framework protocol, and the dependency list is updated.

[0040] Optionally, the parsing module is specifically configured to:

[0041] Traversing the routing configuration nodes of the first framework code through an abstract syntax tree to extract routing rules; the routing rules include: paths, parameters, and nested relationships;

[0042] In combination with a routing syntax specification of the second framework protocol, mapping the routing rule to a routing syntax adapted to the second framework protocol;

[0043] A routing configuration file is generated according to the construction configuration of the second framework protocol, and the routing configuration file is incorporated into the target code range list.

[0044] Optionally, the preset conversion rule includes at least one of the following:

[0045] Nested structure flattening rules, including converting style declarations based on compound attribute syntax or hierarchical nesting syntax in the first framework code into a flat object structure supported by the second framework protocol;

[0046] Style separation rules, including decoupling inline style declarations from component logic in the first framework code, extracting them into independent external style files, and establishing reference associations through a modular import mechanism;

[0047] The composite attribute standardization rule includes splitting the composite style attributes unique to the first framework code into independent dimension attributes common to the second framework protocol.

[0048] Optionally, the migration module is specifically configured to:

[0049] Determining a mapping relationship between the first framework component identifier and the second framework protocol component identifier based on the first framework component identifier marked in the target code range list;

[0050] According to the component dependencies declared in the dependency list, replacing the first framework component reference with the adaptation layer component identifier of the second framework protocol during the compilation phase;

[0051] By dynamically calling the platform's underlying API of the second framework protocol, the adaptation layer components are ensured to be consistent with the rendering logic and device capability calls of the underlying framework.

[0052] Optionally, the migration module is specifically configured to:

[0053] Based on the dependency list, detecting compatibility between the version numbers of the dependencies in the first framework code and the version of the second framework protocol; and / or detecting availability of the API interfaces of the dependencies in the first framework code in the second framework protocol;

[0054] In response to detecting the incompatible and / or unavailable dependencies, an alarm is triggered and a downgrade strategy is generated, the downgrade strategy being based on compatibility rules of the second framework protocol.

[0055] The present disclosure provides an electronic device, including a memory, a processor, and a computer program stored in the memory and used to run on the processor, wherein the processor implements any one of the above-mentioned cross-framework code migration methods when executing the computer program.

[0056] The present disclosure provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the computer program implements any one of the above-mentioned cross-framework code migration methods.

[0057] The present disclosure provides a computer program product, including a computer program, which implements any one of the above-mentioned cross-framework code migration methods when executed by a processor.

[0058] On the basis of conforming to the common sense in this field, the above-mentioned preferred conditions can be arbitrarily combined to obtain the preferred embodiments of the present disclosure.

[0059] The positive progress of the present disclosure is that through automated framework-level conversion and dynamic rule adaptation, rapid migration of the first framework code to the second framework code is achieved, multi-terminal code bases are unified, human development costs are reduced, business iteration and migration are supported simultaneously, and development efficiency is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] Figure 1 A flowchart of a cross-framework code migration method provided by an exemplary embodiment of the present disclosure;

[0061] Figure 2 A flowchart of step 101 is provided for an exemplary embodiment of the present disclosure;

[0062] Figure 3 A flowchart of step 102 is provided for an exemplary embodiment of the present disclosure;

[0063] Figure 4 A flowchart of step 103 is provided for an exemplary embodiment of the present disclosure;

[0064] Figure 5 A schematic diagram of a module of a code migration system provided by an exemplary embodiment of the present disclosure;

[0065] Figure 6 The present invention provides a structural diagram of an electronic device according to an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0066] The present disclosure is further illustrated below by way of examples, but the present disclosure is not limited to the scope of the examples.

[0067] In the embodiments of the present disclosure, prefixes such as "first" and "second" are used only to distinguish different description objects and have no limiting effect on the position, order, priority, quantity or content of the described objects. In the embodiments of the present disclosure, the use of prefixes such as ordinal numbers to distinguish description objects does not constitute a restriction on the described objects. For the statement of the described objects, please refer to the description in the context of the embodiments, and the use of such prefixes should not constitute an unnecessary restriction. In addition, in the description of this embodiment, unless otherwise specified, the meaning of "plurality" is two or more.

[0068] In the embodiments of the present disclosure, the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0069] This disclosure is dedicated to migrating the first framework code to code adapted to the second framework protocol. In the embodiments, the conversion of CRN code to xTaro code is used as an example for illustration, but this does not mean that the embodiments of this disclosure are limited to migration between CRN and xTaro. In addition, some of the English expressions involved in the embodiments are as follows:

[0070] 1.CRN (Cross-React-Native), the full name of which is Cross-React Native Framework, is a cross-end development framework that enables code reuse across multiple terminals (applets, apps, and web) based on React syntax.

[0071] 2. xTaro, the full name of the cross-terminal unified development framework, is a framework that supports the compilation of React / Vue syntax into multi-terminal codes such as mini-programs, H5, React Native, etc.

[0072] 3.JSX (JavaScript XML), full name JavaScript XML, is React's JS extended syntax, allowing HTML-like UI structures to be written in JavaScript.

[0073] 4. SCSS (Sassy CSS), the full name of Sass syntax extension, acts as a CSS preprocessor that supports advanced features such as variables, nested rules, and mixins.

[0074] Example 1

[0075] Figure 1 This is a flowchart of a cross-framework code migration method provided by an exemplary embodiment of the present disclosure. As can be seen from the figure, the code migration method includes:

[0076] Step 101: Perform framework-level conversion on the first framework code to generate a target project skeleton adapted to the second framework protocol. The target project skeleton includes: build configuration, entry files, and dependency list.

[0077] The core goal of step 101 is to convert the code structure of the first framework (such as CRN) into the compilation environment of the second framework (such as xTaro) through engineering-level adaptation. Essentially, this involves standardized transformation of build rules, entry logic, and dependency ecosystems to ensure that subsequent code migration can be executed within a compatible framework.

[0078] The key role is:

[0079] 1. Eliminate framework differences: By replacing the build toolchain (e.g. Metro → Taro CLI), the CRN code can be recognized by the xTaro compiler;

[0080] 2. Unified entry specifications: inject multi-terminal entry files (such as `app.tsx`) to adapt the startup logic of different platforms;

[0081] 3. Dependency version alignment: Resolve dependency conflicts (such as React version differences) between CRN and the xTaro ecosystem through a compatibility mapping table.

[0082] Alternatively, see Figure 2 Step 101 specifically includes:

[0083] Step 1011: Replace the build tool chain of the first framework code with the build tool chain corresponding to the second framework protocol, so that the first framework code adapts to the compilation rules of the second framework protocol.

[0084] The core goal of step 1011 is to adapt the code of the first framework (such as CRN) to the compilation rules of the second framework protocol (such as xTaro) by replacing the build toolchain. The build toolchain is the core infrastructure for code compilation, packaging, and execution. The build tools of different frameworks (such as React Native's Metro and Taro's CLI) have fundamental differences in compilation logic, dependency resolution, and resource handling. By replacing the toolchain, the following goals need to be achieved:

[0085] 1. Compilation rule adaptation: ensure that the code syntax is compatible with the compiler of the new framework;

[0086] 2. Dependency parsing refactoring: adjust the loading order and packaging strategy of dependencies;

[0087] 3. Standardize resource processing procedures: unify the processing methods of static resources such as images and fonts.

[0088] Step 1011 resolves the differences in compilation rules between the first and second frameworks by building a deep replacement of the tool chain. This step provides a basic compilation environment for subsequent code migration and is a key prerequisite for automated migration.

[0089] Step 1012: Inject the global configuration of the second framework protocol into the target project skeleton to generate an entry file that is adaptable to multiple terminals.

[0090] The core goal of step 1012 is to establish a unified runtime environment for adapting to the second framework (such as xTaro) through global configuration injection and multi-terminal entry generation. Its essence is:

[0091] 1. Multi-terminal compatibility configuration: Define differentiated parameters (such as navigation bar style and device adaptation rules) for different platforms (such as mini-programs, H5, and apps);

[0092] 2. Standardize entry logic: Create cross-end entry files and coordinate multi-end initialization processes (such as framework instance creation and route mounting).

[0093] 3. Runtime bridging: Injecting a framework-level API adaptation layer to ensure unified calling of underlying capabilities (such as network requests and device information acquisition).

[0094] Step 1012 resolves the initialization discrepancies between multiple frameworks by injecting configuration and refactoring the entry point. This step is a key step in engineering implementation for cross-framework migration, directly impacting the consistency and maintainability of multi-terminal code.

[0095] Step 1013: Based on the dependency compatibility mapping table of the second framework protocol, adapt the original dependency list of the first framework code to the corresponding version of the second framework protocol, and update the dependency list.

[0096] The core goal of step 1013 is to use the dependency compatibility mapping table to map the dependency version of the first framework (such as CRN) to the compatible version of the second framework (such as xTaro) and resolve version conflicts. Its essence is to restructure the dependency ecosystem and ensure that the migrated code can compile and run normally under the new framework. Its key logic is:

[0097] 1. Dependency mapping: Establish the version correspondence between the old and new framework dependencies (e.g. `react-native@0.68` → `@tarojs / react-native@3.0`);

[0098] 2. Version compatibility check: Verify whether the mapped dependencies meet the version requirements of the new framework (such as React 17+);

[0099] 3. Dynamically adjust rules: trigger downgrade, replacement, or alarm strategies based on compatibility results.

[0100] Step 1013 resolves the dependency ecosystem differences between the new and old frameworks through dependency mapping tables and dynamic version adjustments. Its beneficial effects are:

[0101] 1. Compatibility assurance: Reduce manual intervention through a preset rule base and automatic downgrade strategy;

[0102] 2. Dependency tree optimization: eliminate transitive dependency conflicts and improve build stability;

[0103] 3. Multi-terminal consistency: Ensure that all platforms (mini programs, H5, App) use the same dependency version.

[0104] This step is the core link of engineering implementation in cross-framework migration and directly affects the success rate of migration.

[0105] Step 102: Parse the build configuration and entry files to determine the entry point and compilation rules for code migration. Then, analyze the first framework code using an abstract syntax tree to generate a list of target code ranges to be migrated. The list of target code ranges includes the code elements to be migrated in the first framework code and the identifiers of the code elements corresponding to the functions in the second framework protocol.

[0106] The core goal of step 102 is to convert the routing configuration of the first framework (such as CRN) into the compatible syntax of the second framework (such as xTaro) through routing rule migration and generate a migration scope list. Its essence is:

[0107] Routing rule extraction: Extract the routing path, parameters and nested relationships of CRN through AST parsing;

[0108] Syntax mapping conversion: Mapping CRN's routing syntax (such as React Navigation) to xTaro's routing syntax (such as Taro Router);

[0109] Configuration file generation: Generate xTaro's routing configuration file (such as app.config.js) and include it in the migration list.

[0110] Alternatively, see Figure 3 Step 102 specifically includes:

[0111] Step 1021: traverse the routing configuration nodes of the first framework code through the abstract syntax tree to extract routing rules; the routing rules include: path, parameters and nested relationships.

[0112] The core goal of step 1021 is to extract routing rules (paths, parameters, and nested relationships) from the routing configuration code of the first framework (such as CRN) by traversing the abstract syntax tree (AST), providing structured data for subsequent routing syntax mapping and configuration generation. Its essence is to abstractly extract code semantics and convert framework-specific syntax into a general rule description. Key logic:

[0113] 1. Node identification: Locate routing configuration nodes (such as React Navigation's `Stack.Screen` or VueRouter's `path` definition);

[0114] 2. Attribute extraction: Parsing node attributes (such as `name`, `path`, `params`);

[0115] 3. Relationship modeling: Build routing hierarchical relationships (such as parent-child structures of nested routes).

[0116] Step 1021 solves the routing semantic conversion problem from CRN to xTaro through AST traversal and rule extraction. Its beneficial effects are:

[0117] 1. Code semantic abstraction: converting framework-specific syntax (such as React Navigation) into general rules;

[0118] 2. Multi-terminal compatibility guarantee: ensuring that routing rules adapt to the path specifications of different platforms;

[0119] 3. Automation foundation: Provide structured input for subsequent code generation, reducing the amount of manual coding.

[0120] This step is a key part of code parsing and reconstruction in routing migration, and directly affects the migration efficiency and accuracy.

[0121] Step 1022: In combination with the routing syntax specification of the second framework protocol, the routing rules are mapped into routing syntax adapted to the second framework protocol.

[0122] The core goal of step 1022 is to convert the routing rules of the first framework (such as CRN) into the syntax specifications of the second framework (such as xTaro) through syntax mapping, ensuring the compatibility of routing logic in a multi-terminal environment. Its essence is the standardized reconstruction of syntax sugar to resolve the differences in routing definitions, parameter transfer, and navigation behaviors between frameworks. Key logic:

[0123] 1. Syntax difference mapping: Identify the grammatical features of the target framework (such as URL parameter concatenation and path hierarchy specifications in xTaro);

[0124] 2. Parameter transfer adaptation: adjust the parameter encoding method (e.g. `initialParams` in CRN → dynamic URL parameters in xTaro);

[0125] 3. Navigation behavior alignment: Map routing jump methods (such as CRN's `navigation.navigate` → xTaro's `Taro.navigateTo`).

[0126] Step 1022 resolves the routing syntax differences between CRN and xTaro through syntax mapping and parameter adaptation. Its beneficial effects are:

[0127] 1. Path standardization: unify multi-terminal routing path specifications (such as the ` / pages` prefix);

[0128] 2. Parameter compatibility: Adapt to the parameter passing mechanism of different frameworks;

[0129] 3. Lifecycle alignment: Hide the differences in underlying frameworks and reduce migration costs.

[0130] This step is a key part of code reconstruction in routing migration and directly affects the stability of multi-terminal navigation functions.

[0131] Step 1023: Generate a routing configuration file according to the construction configuration of the second framework protocol, and include the routing configuration file in the target code range list.

[0132] The core goal of step 1023 is to ensure the executable nature of routing logic in a multi-terminal environment by generating a routing configuration file adapted to the second framework and incorporating it into the migration checklist. Its essence is to integrate configuration standardization with the build process, resolving differences in configuration file formats, path specifications, and runtime loading mechanisms between frameworks. Key logic:

[0133] 1. Configuration file generation: Generate the configuration file of the target framework according to the mapped routing rules (such as xTaro's `app.config.js`);

[0134] 2. Build rule adaptation: Adjust the compilation configuration (such as Webpack, Taro CLI) to recognize the newly generated routing files;

[0135] 3. Manifest management: Add the generated configuration files to version control to ensure that subsequent build processes rely on their existence.

[0136] Step 1023 solves the routing configuration implementation problem from CRN to xTaro by integrating configuration file generation and construction. Its beneficial effects are:

[0137] 1. Unified multi-terminal configuration: Centrally manage routing rules through `app.config.js` to reduce maintenance costs;

[0138] 2. Standardize the build process: Adapt to xTaro's compilation rules to ensure that routing files are packaged correctly;

[0139] 3. Automation foundation: Provides an executable routing environment for subsequent page migration.

[0140] This step is the final step in the engineering implementation of routing migration and directly affects the consistency and maintainability of multi-terminal functions.

[0141] Step 103: Apply preset conversion rules to the first framework code based on the target code range list and the dependency list to generate a second framework code adapted to the second framework protocol. The preset conversion rules are dynamically adjusted based on the version compatibility of the dependency list.

[0142] The core goal of step 103 is to convert the code of the first framework (such as CRN) into executable code compatible with the second framework (such as xTaro) through preset conversion rules and dependency compatibility adaptation. Its essence is to standardize the code semantics and resolve differences in component definitions, style syntax, API calls, etc. between frameworks. Key logic:

[0143] Component mapping: Establish the identifier mapping relationship between CRN components and xTaro components;

[0144] Style refactoring: convert CRN's nested style objects to xTaro's flat structure, and separate inline styles into independent files;

[0145] Dependency replacement: Replace or downgrade incompatible dependencies (such as React 18→17) based on the compatibility test results;

[0146] Dynamic adaptation: Ensure rendering logic consistency through platform underlying API calls (such as the difference in style units between mini programs and the web).

[0147] Optionally, the preset conversion rule includes at least one of the following:

[0148] The nested structure flattening rule converts style declarations based on compound attribute syntax or hierarchical nesting syntax in the first framework's code into a flat object structure supported by the second framework's protocol. The core goal of this rule is to convert nested style declarations (such as those based on object hierarchies or compound attributes in CRN) into a flat key-value structure (such as the independent attributes supported by xTaro), ensuring consistency and maintainability across different frameworks. Essentially, it restructures and standardizes style semantics, resolving differences in style syntax, attribute naming, and rendering logic between frameworks.

[0149] The nested structure flattening rule resolves the style syntax differences between CRN and xTaro through hierarchical deconstruction and attribute standardization. Its beneficial effects are:

[0150] 1. Rendering consistency: Ensure that effects such as shadows and margins are consistent across multiple devices;

[0151] 2. Reduced maintenance costs: Flat structures are easier to read and modify;

[0152] 3. Automation foundation: Provide predictable style output for subsequent component migration.

[0153] This rule is the core link of code refactoring in cross-framework style migration, and directly affects the restoration degree and development efficiency of multi-terminal UI.

[0154] The style separation rule involves decoupling inline style declarations in the first framework's code from component logic, extracting them into independent external style files and establishing reference associations through modular imports. The core goal of this rule is to decouple inline styles from component logic, centrally manage style rules through external style files, and enable style reuse through modular imports. Essentially, it decouples style from logic, addressing differences in style definition, scope isolation, and reuse efficiency between frameworks.

[0155] Key logic:

[0156] 1. Style extraction: extract inline styles (such as `style={{}}`) into independent CSS / class names;

[0157] 2. Modular management: achieve style scope isolation through class names or CSS Modules;

[0158] 3. Dynamic binding: Import reference styles in components through modular import.

[0159] The style separation rule solves the style compatibility issue between CRN and xTaro by decoupling logic and style, modular management, and dynamic binding. Its beneficial effects are:

[0160] 1. Improved maintainability: Centralized style management avoids mixing logic and styles;

[0161] 2. Multi-terminal consistency: Ensure consistent style across different frameworks through unified standards;

[0162] 3. Automation foundation: Provide standardized input for subsequent component library construction.

[0163] This rule is a key step in the engineering implementation of cross-framework style migration, and directly affects the efficiency and stability of multi-terminal UI development.

[0164] The standardization of composite attributes involves splitting composite style attributes unique to the first framework's code into independent, dimensioned attributes common to the second framework's protocol. The core goal of this rule is to decompose framework-specific composite style attributes (such as nested composite objects or custom attributes in CRN) into independent attributes common to the target framework (such as flattened attributes supported by xTaro), ensuring consistency and maintainability across different frameworks. Essentially, this standardization splits style semantics, resolving differences in style syntax, attribute naming, and rendering logic between frameworks.

[0165] The composite attribute standardization rule resolves the style syntax differences between CRN and xTaro through nested deconstruction and attribute splitting. Its beneficial effects are:

[0166] 1. Rendering consistency: Ensure that effects such as shadows and rounded corners appear consistent across multiple devices;

[0167] 2. Reduced maintenance costs: independent properties are easier to read and modify;

[0168] 3. Automation foundation: Provide standardized input for subsequent component library construction.

[0169] This rule is the core link of code refactoring in cross-framework style migration, and directly affects the restoration degree and development efficiency of multi-terminal UI.

[0170] Alternatively, see Figure 4 Step 103 specifically includes:

[0171] Step 1031: Based on the first framework component identifier marked in the target code range list, determine the mapping relationship between the first framework component identifier and the second framework protocol component identifier.

[0172] The core goal of step 1031 is to establish a mapping between component identifiers in the first framework (CRN) and those in the second framework (xTaro), resolving semantic and functional differences between components across the frameworks. Essentially, this involves semantic alignment at the component abstraction layer, ensuring that CRN components can find functionally equivalent or similar alternatives in xTaro.

[0173] Step 1031 solves the compatibility issue between CRN and xTaro components through component identifier mapping and functional equivalent replacement. Its beneficial effects are:

[0174] 1. Functional consistency: Ensure that core components (such as buttons and lists) behave consistently across multiple devices;

[0175] 2. Improved development efficiency: Reduce manual rewriting costs through automated mapping;

[0176] 3. Scalability guarantee: Provide standardized templates for the subsequent migration of complex components (such as forms and navigation).

[0177] This step is the basic link for component layer reconstruction in cross-framework migration, which directly affects the multi-terminal functional restoration and development experience.

[0178] Step 1032: According to the component dependency relationship declared in the dependency list, replace the first framework component reference with the adaptation layer component identifier of the second framework protocol during the compilation phase.

[0179] The core goal of step 1032 is to map component references from the first framework (e.g., CRN) to the adaptation layer components of the second framework (e.g., xTaro) through compile-time dependency replacement, resolving cross-framework component interface differences. This is essentially dynamic redirection of modular dependencies, ensuring framework adaptation is completed during code compilation rather than dynamic loading at runtime.

[0180] Step 1032 resolves the component interface differences between CRN and xTaro through dependency mapping and compile-time replacement. Its beneficial effects are:

[0181] 1. Compatibility isolation: shielding the underlying differences of the framework through the adaptation layer;

[0182] 2. Improved compilation efficiency: Adaptation is completed during the build phase, reducing runtime overhead;

[0183] 3. Dynamic guarantee: supports seamless replacement of dynamically imported components.

[0184] This step is a key part of modular reconstruction in cross-framework migration and directly affects the runtime stability of multi-terminal codes.

[0185] Step 1033: By dynamically calling the platform underlying API of the second framework protocol, ensure that the adaptation layer component is consistent with the rendering logic and device capability calls of the underlying framework.

[0186] The core goal of step 1033 is to ensure that the adaptation layer components maintain consistency with the underlying framework (xTaro) in terms of rendering logic, device capability calls (such as network, storage, and sensors), and other aspects by dynamically calling the underlying platform APIs of the target framework (xTaro). This is essentially cross-platform capability abstraction and dynamic adaptation, resolving API differences between frameworks and platform feature compatibility issues.

[0187] Step 1033 solves the problem of device capability differences between CRN and xTaro through dynamic API call layer and platform capability mapping. Its beneficial effects are:

[0188] 1. Multi-terminal consistency: Business code does not need to pay attention to the underlying platform, and the calling interface is unified;

[0189] 2. Scalability: When adding a new platform, only the adaptation layer needs to be expanded without modifying the business logic;

[0190] 3. Downgrade compatibility: Provide alternative solutions for unsupported capabilities (such as web-based simulated positioning).

[0191] This step is a key link in abstracting device capabilities in cross-framework migration, and directly affects the functional integrity and user experience of multiple terminals.

[0192] Optionally, preset conversion rules are dynamically adjusted based on the version compatibility of the dependency list, including:

[0193] Step 1041: Based on the dependency list, detect the compatibility of the version number of the dependency in the first framework code with the version of the second framework protocol; and / or detect the availability of the API interface of the dependency in the first framework code in the second framework protocol;

[0194] The core goal of this step is to dynamically adjust the preset conversion rules through dependency version analysis and API compatibility testing to ensure that CRN dependencies meet version requirements and are functionally equivalent in xTaro. Its essence is to rely on the compatibility governance of the ecosystem to resolve issues such as version conflicts, API deprecation, or behavioral differences. Key logic:

[0195] 1. Version compatibility detection: Compares the CRN dependency version with the version range supported by xTaro; automatically upgrades / downgrades the dependency version or provides compatibility patches.

[0196] 2. API availability verification: Check whether the API of CRN dependencies exists in xTaro or whether the parameters are consistent; generate API mapping table or adaptation layer code.

[0197] This step solves the dependency compatibility issue between CRN and xTaro through version locking, API mapping, and conditional compilation. Its benefits are:

[0198] 1. Reduce migration risks: Automated detection avoids manual verification costs;

[0199] 2. Improve compatibility: support multi-version coexistence and gradual upgrades;

[0200] 3. Standardized output: Generate adaptation layer code and mapping table to facilitate subsequent maintenance.

[0201] This rule is a key link in cross-framework migration that relies on ecological governance and directly affects the stability and maintainability of multi-terminal construction.

[0202] Step 1042: In response to detecting an incompatible and / or unavailable dependency, trigger an alarm and generate a downgrade strategy, where the downgrade strategy is based on the compatibility rules of the second framework protocol.

[0203] The core goal of this step is to resolve compatibility issues caused by version conflicts or API deprecation in CRN dependencies in xTaro through automated detection and dynamic policy generation. Its essence is to build a fault-tolerant mechanism and downgrade plan to ensure that business functions can still run stably even when dependencies are abnormal. Key logic:

[0204] 1. Dependency detection: statically analyze the matching degree between the CRN dependency version and the xTaro compatibility rule base; dynamically verify the availability of the API interface in xTaro (such as parameter and return value differences).

[0205] 2. Alarm triggering: Output a compatibility report (such as Markdown / HTML format), marking conflicting dependencies and the scope of impact; integrate into the CI / CD pipeline to prevent incompatible code from being merged.

[0206] 3. Downgrade strategy generation: Based on xTaro compatibility rules, provide alternative solutions (such as downgrading API, enabling Polyfill); generate adaptation code snippets or configuration patches.

[0207] This step solves the dependency compatibility issue between CRN and xTaro through compatibility detection, alarm blocking, and policy generation. Its beneficial effects are:

[0208] 1. Risk control: Identify incompatible dependencies in advance to avoid runtime crashes;

[0209] 2. Downgrade flexibility: Provide multi-level emergency plans to balance functionality and stability;

[0210] 3. Automated closed loop: Tooling is used throughout the entire process from detection to repair, reducing the cost of manual intervention.

[0211] This rule is the core guarantee for dependency governance in cross-framework migration, and directly affects system robustness and migration success rate.

[0212] This example uses an automated code conversion engine to achieve one-click migration from CRN code to xTaro code. The core benefits include:

[0213] Component layer reconstruction: CRN component references are replaced with xTaro adaptation layer components (such as @c2x / react-native), while retaining the original logical semantics;

[0214] Style system migration: RN's StyleSheet writing method is converted to xTaro's SCSS modular solution, which supports multi-terminal style isolation and dynamic injection;

[0215] JSX syntax standardization: The mixed style writing (style={[...]}{...}) is unified into xTaro's className+xMergStyle combination mode, which is compatible with multi-end rendering rules.

[0216] Example 2

[0217] Corresponding to the aforementioned cross-framework code migration method embodiment, the present disclosure also provides an embodiment of a cross-framework code migration system.

[0218] Figure 5 A schematic diagram of a cross-framework code migration system provided by an exemplary embodiment of the present disclosure includes:

[0219] The present disclosure provides a cross-framework code migration system, which includes:

[0220] The framework module 21 is used to perform framework-level conversion on the first framework code to generate a target project skeleton adapted to the second framework protocol; the target project skeleton includes: build configuration, entry file, and dependency list;

[0221] The parsing module 22 is used to parse the build configuration and entry files, determine the entry point and compilation rules for code migration, and analyze the first framework code through an abstract syntax tree to generate a target code range list to be migrated; the target code range list includes: the code elements to be migrated in the first framework code and the code element identifiers of the corresponding functions in the second framework protocol;

[0222] The migration module 23 is used to apply preset conversion rules to the first framework code according to the target code range list and the dependency list to generate a second framework code adapted to the second framework protocol; wherein the preset conversion rules are dynamically adjusted based on the version compatibility of the dependency list.

[0223] Optionally, the framework module 21 is specifically configured to:

[0224] Replace the build tool chain of the first framework code with the build tool chain corresponding to the second framework protocol, so that the first framework code adapts to the compilation rules of the second framework protocol;

[0225] Inject the global configuration of the second framework protocol into the target project skeleton to generate an entry file that is compatible with multiple terminals;

[0226] Based on the dependency compatibility mapping table of the second framework protocol, the original dependency list of the first framework code is adapted to the corresponding version of the second framework protocol, and the dependency list is updated.

[0227] Optionally, the parsing module 22 is specifically configured to:

[0228] Traverse the routing configuration nodes of the first framework code through the abstract syntax tree to extract routing rules; routing rules include: path, parameters and nested relationships;

[0229] In combination with the routing syntax specification of the second framework protocol, the routing rules are mapped to the routing syntax adapted to the second framework protocol;

[0230] Generate a routing configuration file according to the build configuration of the second framework agreement, and include the routing configuration file into the target code scope list.

[0231] Optionally, the preset conversion rule includes at least one of the following:

[0232] Nested structure flattening rules, including converting style declarations based on compound attribute syntax or hierarchical nesting syntax in the first framework code into a flat object structure supported by the second framework protocol;

[0233] Style separation rules, including decoupling inline style declarations from component logic in the first framework code, extracting them into independent external style files, and establishing reference associations through a modular import mechanism;

[0234] The composite attribute standardization rules include splitting composite style attributes unique to the first framework code into independent dimension attributes common to the second framework protocol.

[0235] Optionally, the migration module 23 is specifically configured to:

[0236] Determining a mapping relationship between the first framework component identifier and the second framework protocol component identifier based on the first framework component identifier marked in the target code range list;

[0237] According to the component dependencies declared in the dependency list, the first framework component reference is replaced with the adaptation layer component identifier of the second framework protocol during the compilation phase;

[0238] By dynamically calling the platform's underlying API of the second framework protocol, the adaptation layer components are ensured to be consistent with the rendering logic and device capability calls of the underlying framework.

[0239] Optionally, the migration module 23 is specifically configured to:

[0240] Based on the dependency list, detecting the compatibility of the version number of the dependency in the first framework code with the version of the second framework protocol; and / or detecting the availability of the API interface of the dependency in the first framework code in the second framework protocol;

[0241] In response to detecting an incompatible and / or unavailable dependency, an alert is triggered and a downgrade strategy is generated, the downgrade strategy being based on compatibility rules of the second framework protocol.

[0242] This example uses an automated code conversion engine to achieve one-click migration from CRN code to xTaro code. The core benefits include:

[0243] Component layer reconstruction: CRN component references are replaced with xTaro adaptation layer components (such as @c2x / react-native), while retaining the original logical semantics;

[0244] Style system migration: RN's StyleSheet writing method is converted to xTaro's SCSS modular solution, which supports multi-terminal style isolation and dynamic injection;

[0245] JSX syntax standardization: The mixed style writing (style={[...]}{...}) is unified into xTaro's className+xMergStyle combination mode, which is compatible with multi-end rendering rules.

[0246] Since the system embodiments generally correspond to the method embodiments, reference will be made to the description of the method embodiments for relevant details. The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components of the units may or may not be physical units, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of the disclosed solution.

[0247] Example 3

[0248] Figure 6 This is a structural diagram of an electronic device showing an example embodiment of the present disclosure. The electronic device includes a memory, a processor, and a computer program stored in the memory and used to run on the processor. When the processor executes the computer program, the cross-framework code migration method of any of the above embodiments is implemented. Figure 6 The electronic device 90 shown is only an example and should not limit the functionality and scope of use of the embodiments of the present disclosure.

[0249] like Figure 6 As shown, the electronic device 90 may be a general-purpose computing device, such as a server device. Components of the electronic device 90 may include, but are not limited to, the at least one processor 91, the at least one memory 92, and a bus 93 connecting different system components (including the memory 92 and the processor 91).

[0250] The bus 93 includes a data bus, an address bus, and a control bus.

[0251] The memory 92 may include a volatile memory, such as a random access memory (RAM) 921 and / or a cache memory 922 , and may further include a read-only memory (ROM) 923 .

[0252] The memory 92 may also include a program tool 925 (or utility) having a set (at least one) of program modules 924, such program modules 924 including but not limited to: an operating system, one or more application programs, other program modules and program data, each of which or some combination may include an implementation of a network environment.

[0253] The processor 91 executes various functional applications and data processing by running computer programs stored in the memory 92, such as the cross-framework code migration method provided in any of the above embodiments.

[0254] The electronic device 90 can also communicate with one or more external devices 94 (e.g., a keyboard, pointing device, etc.). This communication can occur via an input / output (I / O) interface 95. Furthermore, the electronic device 90 can communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) via a network adapter 96. As shown, the network adapter 96 communicates with other modules of the electronic device 90 via a bus 93. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the electronic device 90, including but not limited to microcode, device drivers, redundant processors, external disk drive arrays, RAID (RAID) systems, tape drives, and data backup storage systems.

[0255] It should be noted that although several units / modules or sub-units / modules of the electronic device are mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more units / modules described above can be embodied in one unit / module. Conversely, the features and functions of one unit / module described above can be further divided and embodied by multiple units / modules.

[0256] Example 4

[0257] An embodiment of the present disclosure further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the cross-framework code migration method provided in any of the above embodiments.

[0258] The readable storage medium may include, but is not limited to, a portable disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0259] Example 5

[0260] An embodiment of the present disclosure further provides a computer program product, including a computer program, which implements any of the above-mentioned cross-framework code migration methods when executed by a processor.

[0261] The program code for executing the computer program product of the present disclosure may be written in any combination of one or more programming languages, and the program code may be executed entirely on the user device, partially on the user device, as a standalone software package, partially on the user device and partially on a remote device, or entirely on the remote device.

[0262] While specific embodiments of the present disclosure have been described above, those skilled in the art will appreciate that these are merely illustrative and that the scope of protection of the present disclosure is defined by the appended claims. Those skilled in the art may make various changes or modifications to these embodiments without departing from the principles and essence of the present disclosure, and such changes and modifications are intended to fall within the scope of protection of the present disclosure.

Claims

1. A cross-framework code migration method, characterized in that: The code migration method includes: Performing framework-level conversion on the first framework code to generate a target project skeleton adapted to the second framework protocol; the target project skeleton includes: build configuration, entry file, and dependency list; Parsing the build configuration and the entry file to determine the entry point and compilation rules for code migration, and analyzing the first framework code through an abstract syntax tree to generate a target code range list to be migrated; the target code range list includes: code elements to be migrated in the first framework code and code element identifiers of corresponding functions in the second framework protocol; According to the target code range list and the dependency list, preset conversion rules are applied to the first framework code to generate a second framework code adapted to the second framework protocol; wherein the preset conversion rules are dynamically adjusted based on the version compatibility of the dependency list.

2. The code migration method according to claim 1, wherein: The framework-level conversion of the first framework code to generate a target engineering skeleton adapted to the second framework protocol includes: Replacing the construction tool chain of the first framework code with the construction tool chain corresponding to the second framework protocol, so that the first framework code adapts to the compilation rules of the second framework protocol; Injecting the global configuration of the second framework protocol into the target project skeleton to generate the entry file adapted to multiple terminals; Based on the dependency compatibility mapping table of the second framework protocol, the original dependency list of the first framework code is adapted to the corresponding version of the second framework protocol, and the dependency list is updated.

3. The code migration method according to claim 1, wherein: The parsing of the build configuration and the entry file, determining the entry point and compilation rules for code migration, and analyzing the first framework code through an abstract syntax tree to generate a list of target code ranges to be migrated include: Traversing the routing configuration nodes of the first framework code through an abstract syntax tree to extract routing rules; the routing rules include: paths, parameters, and nested relationships; In combination with a routing syntax specification of the second framework protocol, mapping the routing rule to a routing syntax adapted to the second framework protocol; A routing configuration file is generated according to the construction configuration of the second framework protocol, and the routing configuration file is incorporated into the target code range list.

4. The code migration method according to claim 1, wherein: The preset conversion rule includes at least one of the following: Nested structure flattening rules, including converting style declarations based on compound attribute syntax or hierarchical nesting syntax in the first framework code into a flat object structure supported by the second framework protocol; Style separation rules, including decoupling inline style declarations from component logic in the first framework code, extracting them into independent external style files, and establishing reference associations through a modular import mechanism; The composite attribute standardization rule includes splitting the composite style attributes unique to the first framework code into independent dimension attributes common to the second framework protocol.

5. The code migration method according to claim 1, wherein: The step of applying a preset conversion rule to the first framework code according to the target code range list and the dependency list to generate a second framework code adapted to the second framework protocol includes: Determining a mapping relationship between the first framework component identifier and the second framework protocol component identifier based on the first framework component identifier marked in the target code range list; According to the component dependencies declared in the dependency list, replacing the first framework component reference with the adaptation layer component identifier of the second framework protocol during the compilation phase; By dynamically calling the platform's underlying API of the second framework protocol, the adaptation layer components are ensured to be consistent with the rendering logic and device capability calls of the underlying framework.

6. The code migration method according to claim 1, wherein: The preset conversion rules are dynamically adjusted based on the version compatibility of the dependency list, including: Based on the dependency list, detecting compatibility between the version numbers of the dependencies in the first framework code and the version of the second framework protocol; and / or detecting availability of the API interfaces of the dependencies in the first framework code in the second framework protocol; In response to detecting the incompatible and / or unavailable dependencies, an alarm is triggered and a downgrade strategy is generated, the downgrade strategy being based on compatibility rules of the second framework protocol.

7. A cross-framework code migration system, characterized in that: The code migration system includes: The framework module is used to perform framework-level conversion on the first framework code to generate a target project skeleton adapted to the second framework protocol; the target project skeleton includes: build configuration, entry files, and dependency list; a parsing module, configured to parse the build configuration and the entry file, determine the entry point and compilation rules for code migration, and analyze the first framework code through an abstract syntax tree to generate a target code range list to be migrated; the target code range list includes: code elements to be migrated in the first framework code and code element identifiers of corresponding functions in the second framework protocol; A migration module is used to apply preset conversion rules to the first framework code according to the target code range list and the dependency list to generate a second framework code adapted to the second framework protocol; wherein the preset conversion rules are dynamically adjusted based on the version compatibility of the dependency list.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and configured to run on the processor, wherein: When the processor executes the computer program, the cross-framework code migration method according to any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the cross-framework code migration method according to any one of claims 1 to 6 is implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the cross-framework code migration method according to any one of claims 1 to 6 is implemented.

Images