Cross-frame compatible method and device based on existing component, equipment and storage medium

Abstract

The invention relates to a cross-frame compatible method based on an existing component, which comprises the following steps of: extracting a functional component in an existing front-end frame, separating and packaging business logic and a UI (User Interface) component in an independent project, and abstracting an interface and a method irrelevant to the frame, so that the functional component can be loaded and run in different front-end frames. And packaging the functional component to generate an independent JS file and a resource file, combining the JS file and the resource file into an HTML (Hypertext Markup Language) page to generate an online access link, and embedding the online access link into a target front-end framework to run. Meanwhile, a standardized communication interface is utilized to realize two-way communication between functional components in the host framework and the target framework, and business data transmission and event interaction are carried out. According to the invention, through packaging of the functional component and standardization processing of the abstract interface, the problem that the functional component is difficult to reuse in different frames in the prior art is solved, and the functional component can be flexibly deployed and operated in multiple frames, so that the development workload is reduced, and the expansibility and maintenance efficiency of the system are improved.

Description

Technical Field

[0001] The present invention relates to the fields of front-end development technology and financial technology, and in particular to a cross-framework compatibility method, device, equipment and storage medium based on existing components. Background Art

[0002] Financial and insurance business systems are usually built with a variety of different technology stacks and front-end frameworks, such as React, Vue, Angular, etc. However, the compatibility differences between different frameworks make it difficult to reuse the same functional components between these platforms. Existing technologies often rely on developing independent versions of components for each framework, which not only increases development costs, but also makes maintenance and updates complicated and lengthy. Each time an update is made, the development team needs to perform separate debugging and repairs for different frameworks, further increasing the workload.

[0003] In current technical implementations, front-end functional components usually rely on specific frameworks, which limits their reuse in other frameworks. Especially in the financial and insurance industries, complex business logic and UI components need to be reused frequently, and the existing component encapsulation methods lack cross-platform portability. Even if a component can run well in one framework, when it needs to be loaded in another front-end framework, it may cause functional abnormalities or require a lot of modifications due to inconsistencies in APIs, lifecycle hooks, etc. This limitation has created a major obstacle to the business expansion and cross-platform support of insurance companies and financial institutions.

[0004] Systems in the financial and insurance industries usually need to process large amounts of data in real time and communicate with multiple front-end and back-end systems. In the prior art, the communication between the front-end and the back-end mostly uses specific interfaces and methods of their respective frameworks. Such implementation methods lack versatility and cannot meet the needs of cross-framework data transmission. In addition, the lack of a unified standardized communication interface during data transmission may lead to inconsistent event processing between different platforms and difficulty in data synchronization, which in turn affects core businesses such as real-time interaction and risk assessment of financial products. Summary of the invention

[0005] The main purpose of the present invention is to provide a cross-framework compatible method, device, equipment and storage medium based on existing components, aiming to solve the technical problem in the prior art that different front-end frameworks lack compatibility, resulting in the inability to efficiently reuse functional components and increasing development and maintenance costs.

[0006] To achieve the above object, the present invention provides a cross-framework compatibility method based on existing components, comprising:

[0007] Extract functional components from the existing front-end framework, wherein the functional components include business logic and UI components;

[0008] Create an independent project, encapsulate the functional component in the independent project, and separate the business logic of the functional component from the business logic of the existing front-end framework;

[0009] Abstracting the framework-independent interfaces and methods of the encapsulated functional components, so that the functional components are suitable for loading and running in different front-end frameworks;

[0010] Package the encapsulated functional components to generate independent JS files and resource files;

[0011] Create an HTML page containing a functional component mounting node, combine the JS file and the resource file into the HTML page, upload the combined HTML page to a server, and generate an online access link;

[0012] Loading the online access link in a page of a target front-end framework, embedding the functional component into the page of the target front-end framework for execution;

[0013] Using standardized communication interfaces, bidirectional communication is established between the host framework and the functional components in the target front-end framework for transmitting business data and event interaction.

[0014] In one embodiment, after generating the online access link, the method further includes:

[0015] Embed a WebView in a non-H5 terminal device, load the online access link through the WebView, and load the functional component into the non-H5 terminal application;

[0016] When the service side loads the online access link, a URL parameter is added to the online access link to pass the initialization data to the component side;

[0017] The component party parses the URL parameters when loading the HTML page and obtains the initialization data passed by the business party;

[0018] The component party conducts two-way communication with the business party through the WebView window object, transmits business data and events, and completes data interaction between functional components and non-H5 terminal devices.

[0019] In one embodiment, functional components are extracted from an existing front-end framework, including:

[0020] Scan the project folder of the existing front-end framework by using an automated tool, parse the directory structure in the existing front-end framework, and identify the locations of modules and files of functional components;

[0021] Perform static code analysis on the modules and files to identify and locate business logic modules and UI modules in functional components;

[0022] Use static analysis tools to separate the business logic module and UI module in the functional component to generate multiple independent logic units, which are used to be encapsulated in independent projects to form functional components that can run in different front-end frameworks.

[0023] In one embodiment, creating an independent project, encapsulating the functional components in the independent project, includes:

[0024] Create an independent project isolated from the existing front-end framework through the initialization tool, and configure dependencies, including module management tools, build tools, and cross-framework compatibility tools;

[0025] Encapsulate the business logic into an independent functional module, provide services through a standardized interface and interact with other encapsulated functional modules;

[0026] Encapsulate the UI component into an independent view module, and interact with the encapsulated functional module through event drive or interface;

[0027] The functional module and the view module are combined and encapsulated into a complete functional component through a standardized interface or event mechanism.

[0028] In one embodiment, abstracting the encapsulated functional components to obtain interfaces and methods that are independent of the framework includes:

[0029] Define a lifecycle hook interface for functional components that is independent of the front-end framework through abstract methods to handle the loading, updating, and unloading of functional components in different front-end frameworks;

[0030] Create an event listening interface for the functional component that is independent of the front-end framework, so that the functional component can listen to user interaction events in different frameworks and respond to event triggers;

[0031] Abstract a standardized state management interface for functional components, define the setState method to update the state of functional components, and define the getState method to obtain the current state of functional components;

[0032] A general data and property transfer interface is created for functional components, wherein the transfer interface includes a setProps method and a getProps method.

[0033] In one embodiment, the encapsulated functional components are packaged to generate independent JS files and resource files, including:

[0034] Split and manage the internal and external dependencies of functional components, correctly reference internal dependency modules, and separate external dependency modules;

[0035] Use Webpack or Vite for packaging configuration, and distinguish between production mode and development mode according to project requirements;

[0036] Enable code compression and module optimization in production mode, and retain debugging capabilities in development mode;

[0037] Automatically remove unused code by enabling the Tree Shaking function, and use Terser to compress JavaScript to generate lightweight JS files;

[0038] Automatically identify and extract resource files in functional components through packaging tools, and perform compression optimization;

[0039] Output the packaged files, generate independent JS files and resource files, and name the files according to the hash value.

[0040] In one embodiment, a standardized communication interface is used to establish bidirectional communication between the host framework and the functional components in the target front-end framework, including:

[0041] Define a standardized communication interface for passing messages between the host framework and the target front-end framework;

[0042] Creating a communication channel for data exchange in a host framework, wherein the communication channel supports bidirectional data transmission;

[0043] Define a unified message format for data transmission so that messages can be passed between the host framework and functional components in a structured manner;

[0044] Set up event listeners and triggers in the host framework and functional components respectively to capture and process message transmission and event triggering;

[0045] An error capture function is integrated into the communication interface to detect and handle abnormal situations during the communication process.

[0046] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a cross-framework compatible device based on existing components, wherein the cross-framework compatible device based on existing components includes a memory, a processor, and a cross-framework compatible program based on existing components stored in the memory and executable on the processor, wherein the cross-framework compatible program based on existing components implements the steps of the cross-framework compatible method based on existing components as described above when executed by the processor.

[0047] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a computer storage medium, on which a cross-framework compatible program based on existing components is stored, and when the cross-framework compatible program based on existing components is executed by a processor, the steps of the cross-framework compatible method based on existing components as described above are implemented.

[0048] Beneficial effects: The present invention relates to a cross-frame compatibility method based on existing components. By extracting functional components from existing front-end frameworks, business logic and UI components are separated and encapsulated in independent projects, and interfaces and methods that are independent of the framework are abstracted, so that functional components can be loaded and run in different front-end frameworks. The functional components are packaged to generate independent JS files and resource files. After being combined with HTML pages, online access links are generated and embedded in the target front-end framework for operation. At the same time, standardized communication interfaces are used to achieve two-way communication between the host framework and the functional components in the target framework to transfer business data and interact with events. The present invention solves the problem in the prior art that functional components are difficult to reuse in different frameworks by encapsulating functional components and standardizing abstract interfaces, so that functional components can be flexibly deployed and run in multiple frameworks, thereby reducing development workload and improving system scalability and maintenance efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0050] Figure 1 It is a flowchart of an embodiment of a cross-frame compatibility method based on existing components of the present invention;

[0051] Figure 2 It is a functional module diagram of a preferred embodiment of a cross-frame compatible device based on existing components of the present invention;

[0052] Figure 3 It is a structural diagram of the device hardware operating environment involved in the cross-frame compatible device implementation scheme based on existing components of the present invention. DETAILED DESCRIPTION

[0053] It should be understood that the specific embodiments described herein are only used to explain the present invention, and are not used to limit the present invention.

[0054] Financial and insurance business systems are usually built with a variety of different technology stacks and front-end frameworks, such as React, Vue, Angular, etc. However, the compatibility differences between different frameworks make it difficult to reuse the same functional components between these platforms. Existing technologies often rely on developing independent versions of components for each framework, which not only increases development costs, but also makes maintenance and updates complicated and lengthy. Each time an update is made, the development team needs to perform separate debugging and repairs for different frameworks, further increasing the workload.

[0055] In current technical implementations, front-end functional components usually rely on specific frameworks, which limits their reuse in other frameworks. Especially in the financial and insurance industries, complex business logic and UI components need to be reused frequently, and the existing component encapsulation methods lack cross-platform portability. Even if a component can run well in one framework, when it needs to be loaded in another front-end framework, it may cause functional abnormalities or require a lot of modifications due to inconsistencies in APIs, lifecycle hooks, etc. This limitation has created a major obstacle to the business expansion and cross-platform support of insurance companies and financial institutions.

[0056] Systems in the financial and insurance industries usually need to process large amounts of data in real time and communicate with multiple front-end and back-end systems. In the prior art, the communication between the front-end and the back-end mostly uses specific interfaces and methods of their respective frameworks. Such implementation methods lack versatility and cannot meet the needs of cross-framework data transmission. In addition, the lack of a unified standardized communication interface during data transmission may lead to inconsistent event processing between different platforms and difficulty in data synchronization, which in turn affects core businesses such as real-time interaction and risk assessment of financial products.

[0057] See also Figure 1 , Figure 1 This is a flow chart of an embodiment of a cross-framework compatibility method based on existing components provided by the present invention. It should be noted that although a logical sequence is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0058] like Figure 1 As shown, the cross-frame compatibility method based on existing components proposed by the present invention includes the following steps:

[0059] S10, extracting functional components from the existing front-end framework, wherein the functional components include business logic and UI components;

[0060] In this embodiment, the existing front-end framework refers to a currently widely used technical framework for building and developing user interfaces. These frameworks provide developers with efficient development tools and structured methods to create dynamic, interactive web applications. The main function of the front-end framework is to simplify tasks such as UI development, component management, data binding, event handling, and page rendering.

[0061] Functional components refer to code modules with independent functions, usually composed of business logic and UI components. Business logic refers to processing the core operations of the application, such as data validation, API requests, state management, etc. UI components are responsible for the display and interaction of the user interface. Business logic is the core part responsible for data processing, handling business-related rules and operations, such as form validation, data processing, or external API calls. UI components are interface elements that users see and interact with, including buttons, forms, input boxes, etc., through which they interact with business logic.

[0062] Through automated tools or manual analysis, identify the code modules associated with specific business functions in the existing front-end framework. Usually, functional components exist together with UI components and business logic to form a relatively independent unit. Analyze the business-related logic code and decouple it from the implementation of the original framework. Business logic usually includes parts related to database, API interaction or state management. Ensure that the business logic is independent when extracting and minimize the dependence on the framework. UI components associated with business logic (such as forms, pages, interactive buttons, etc.) are extracted at the same time. UI components usually rely on specific framework APIs or tools, so they need to be analyzed and the associated views and style files extracted. Ensure that when extracting functional components, all dependencies (such as third-party libraries, services, global state management tools) are correctly identified and processed to ensure that the extracted components can run independently in other environments. During the extraction of functional components, unit testing is required to ensure that business logic and UI components can run independently and are not affected by the specific implementation of the framework.

[0063] By extracting functional components from existing front-end frameworks, developers can separate business logic from UI components to ensure the independence and reusability of components. This reduces the duplication of work for developers in cross-framework development and enables components to be quickly ported and applied in different environments.

[0064] S20, creating an independent project, encapsulating the functional component in the independent project, so that the business logic of the functional component is separated from the business logic of the existing front-end framework;

[0065] In this embodiment, the purpose of creating an independent project is to isolate the extracted functional components from the existing framework to ensure that they can run independently without the original framework. An independent project usually includes an independent project structure and file system for storing business logic, UI components, styles, dependencies and other resources. The project does not rely on the original framework, thus providing a basis for cross-framework compatibility of functional components.

[0066] Create a new project directory through tools (such as command line tools, IDE, etc.). The directory should contain the basic front-end development structure, such as the src directory for source code, the assets directory for resource files, and the dist directory for build output. Use project build tools (such as npm, yarn) to initialize the project environment and configure necessary dependencies (such as packaging tools, modularization tools, etc.). Select a build tool (such as Webpack, Vite, etc.) and configure the packaging and building process so that the functional components can be packaged into independent distributable modules later.

[0067] Encapsulating functional components means integrating the extracted business logic and UI components into the new project structure to make them independent modules. The goal of encapsulation is to enable components to run normally in different environments, independent of the life cycle and dependencies of the original framework.

[0068] Modularize the extracted business logic code and encapsulate it into independent service or function modules to ensure that the business logic part can be called through the defined interface. When encapsulating, it is necessary to remove the dependence on the existing framework (such as state management, event bus, etc.) and provide standardized interfaces for external interaction. Encapsulate UI components (such as interfaces, forms, buttons, etc.) and ensure that they interact with the business logic module through events or properties. Ensure that the view part of the UI component is separated from the business logic so that the UI component can be reused in different frameworks. Use modular tools (such as ES6 modules, CommonJS, etc.) to encapsulate the business logic and UI components into modules respectively, and call and manage them by defining a unified interface.

[0069] Separating business logic means extracting the business logic of functional components from the existing framework to ensure that the functional components can run independently from the original framework. The key to this step is to remove the functional components' dependence on the existing framework's unique lifecycle management, API calls, state management, etc. to ensure their independence.

[0070] Analyze the coupling points between the business logic and the existing framework, and identify the parts of the business logic that depend on the existing framework (such as lifecycle hooks, state management mechanisms, API calls, etc.). Use framework-independent technology to replace the parts of the business logic that depend on the framework. For example, replace the framework-specific state management mechanism with a standardized state management interface, replace the framework's lifecycle hooks with an independent event mechanism, etc. Define standardized interfaces for the separated business logic so that it can be loaded and called by different front-end frameworks. In this way, the coupling between the business logic and the framework is reduced, allowing functional components to be reused across frameworks.

[0071] By encapsulating functional components in independent projects and separating business logic, the coupling problem between functional components and existing frameworks is solved. Functional components can run independently from existing frameworks, thus achieving cross-framework compatibility. Separating business logic from the logic of existing frameworks effectively reduces the workload of repeated development and maintenance in different frameworks, while improving the flexibility and scalability of the system.

[0072] S30, abstracting the encapsulated functional components into interfaces and methods that are independent of the framework, so that the functional components are suitable for loading and running in different front-end frameworks;

[0073] In this embodiment, the abstract interface refers to a standardized interface that is not dependent on a specific front-end framework and is used for the interaction between functional components and external systems. The method refers to the specific logic executed inside the functional component, which is called through the interface. The purpose of abstracting the interfaces and methods that are not related to the framework is to enable the functional components to be separated from the specific framework, adapt to the environment of different front-end frameworks (such as React, Vue, Angular, etc.), and achieve cross-framework reuse. These interfaces should be universal and cannot rely on the API or life cycle mechanism specific to a certain framework. For example, instead of using React-specific useState or Vue's computed, a custom interface is used to manage state, events, or life cycles. The abstracted method cannot rely on framework-specific tools or functions. The execution of the method is uniformly called through standard interfaces (such as component mounting, updating, destruction, etc.) to avoid deep coupling with a specific framework.

[0074] First, analyze all framework dependencies in the functional component and identify the parts related to framework-specific APIs or lifecycle hooks (such as React's useEffect, Vue's watch, etc.). Design a set of standardized interfaces for functional components so that they do not depend on any specific framework. These interfaces should handle common tasks such as data transfer, event management, state management, etc. The design of the interface should take into account the calling habits of different frameworks to ensure uniformity. Abstract the lifecycle hooks unique to each framework into a unified interface. For example, React's componentDidMount and Vue's mounted can both be abstracted into a common "component initialization" method. Do not use framework-specific state management tools (such as React's useState, Vuex), but handle them through a custom state management module. This state management module should support state acquisition and update through interfaces or callbacks. Abstract a common event handling mechanism to manage event registration, listening, and triggering through interfaces. Ensure that event management does not rely on the framework's built-in event handling system, but is implemented through a custom event mechanism.

[0075] By abstracting framework-independent interfaces and methods, functional components can be loaded and run in different front-end frameworks. Components no longer rely on the lifecycle and state management mechanisms of a specific framework, thus achieving cross-framework compatibility and reusability, reducing the duplication of multi-framework development, and improving the integration efficiency of components in different systems.

[0076] S40, packaging the encapsulated functional components to generate independent JS files and resource files;

[0077] In this embodiment, packaging refers to packaging and integrating functional components and their related dependencies (such as JavaScript code, style sheets, images, etc.) to generate independent files that can be loaded and run in the browser. Through packaging tools (such as Webpack, Vite, etc.), the encapsulated functional components are compiled, compressed and optimized to generate independent JS files and resource files. The packaged files usually include independent JavaScript files (functional logic) and resource files (such as CSS styles, fonts, images, etc.). Independent JS files are JavaScript files containing business logic and UI component code, which are usually compressed and optimized to improve page loading performance. Resource files usually refer to non-JavaScript resources related to functional components, such as style sheets (CSS / SCSS), fonts, images, etc., which are packaged together with JS files and ultimately used for deployment.

[0078] Use packaging tools such as Webpack, Vite, Parcel, etc. to configure the packaging process of the project. Set the entry file (such as index.js) and the output folder (such as dist), and determine the modules and dependencies to be packaged. During the packaging process, the code of the functional components is split and modularized so that the business logic, UI components and resource files can be managed separately. Remove unused code through Tree Shaking to reduce the size of the packaged file. Package the business logic and UI component code into one or more independent JavaScript files (such as bundle.js), and use compression tools (such as Terser) to compress and optimize the code. The generated JS files are usually lightweight and optimized to facilitate loading and running in different frameworks. Extract and compress the resource files related to the functional components (such as style sheets, images, fonts, etc.) to ensure that these files can be loaded independently of the JS files. These files are named by hash to avoid caching problems and ensure file version management. All packaging results (including JS files and resource files) will be output to a specified directory (such as dist), ready to be deployed to the server or integrated into other projects.

[0079] By packaging the encapsulated functional components and generating independent JS files and resource files, the file size can be effectively reduced and the page loading performance can be improved. At the same time, independent packaged files can be easily loaded and run in different front-end frameworks, thereby improving the cross-frame compatibility and reusability of components. The use and optimization of packaging tools can also ensure the loading order and performance improvement of resource files, avoiding unnecessary repeated loading and caching problems.

[0080] S50, creating an HTML page including a function component mounting node, combining the JS file and the resource file into the HTML page, uploading the combined HTML page to a server, and generating an online access link;

[0081] In this embodiment, the function component mounting node is a placeholder for loading and displaying the function component, which is usually an HTML tag (such as 、 <section>In different front-end frameworks, functional components are usually mounted on specific nodes as display containers for their views and logic. Mounting nodes ensure that functional components have a specific location in the page for rendering.

[0082] Create a basic HTML file that contains tags that define the mount node, such as <div id＝"app"> , which is used to load and display the packaged functional components. Configure the HTML page to support the loading of external JS files and resource files (such as using <script>标签引入JS文件、<link>标签引入CSS文件等)。

[0083] JS文件(包含功能组件逻辑)和资源文件(如CSS、图片、字体等)需要被正确引用到HTML页面中，使功能组件在页面加载时能够渲染和运行。结合意味着在HTML中加载并链接这些文件，以确保它们能在浏览器中正常工作。

[0084] 使用<script>标签将打包生成的JS文件加载到HTML页面中，如<script src＝"bundle.js">< / script> , to ensure that the logic of the functional component can be executed when the page loads. Use <link> Tags or <style>标签加载CSS文件，确保组件的样式被正确应用，如<link rel＝"stylesheet"href＝"styles.css">。其他资源文件(如图像、字体等)应通过相对路径或CDN的方式加载，确保它们能够在页面上正确显示。

[0085] 为了使HTML页面和功能组件在线访问，生成的HTML页面以及所有的相关文件(JS、CSS、图片等)需要上传到一个服务器。服务器的作用是提供这些文件的访问地址，供用户通过网络访问。

[0086] 使用FTP、SFTP或CI / CD工具(如Jenkins、GitLab CI等)将HTML页面及相关资源文件上传至服务器的指定目录。确保所有相关文件在服务器上完整无误，且路径正确指向上传后的文件目录。

[0087] 在线访问链接是服务器上HTML页面的公共URL地址，用户可以通过该链接访问并加载功能组件。链接的生成通常是通过将服务器域名与文件路径结合起来，形成唯一的访问地址。

[0088] 确保服务器配置了域名或IP地址，并为上传的HTML页面生成唯一的URL。例如，若服务器域名为www.example.com，则生成的链接可能为www.example.com / yourpage.html。该链接可供外部用户访问，通过浏览器加载页面及组件。

[0089] 通过创建包含挂载节点的HTML页面并结合JS文件与资源文件，功能组件可以在页面中被正确加载和运行。将生成的页面上传到服务器并生成在线访问链接，确保组件可以通过网络进行跨平台访问和加载，这为不同前端框架下的组件复用和交互提供了基础。

[0090] S60，在目标前端框架的页面中加载所述在线访问链接，将所述功能组件嵌入到所述目标前端框架的页面中运行；

[0091] 在本实施例中，目标前端框架是指用户希望功能组件加载和运行的前端框架，如React、Vue、Angular等。每个框架都有其特定的页面加载和组件挂载机制。在线访问链接是之前上传到服务器的HTML页面或JS文件的链接。目标前端框架通过加载这个链接，能够获取组件的代码和资源文件，并在页面中渲染它们。

[0092] 在目标前端框架中，通常会有一个挂载点或容器(如<div id＝"app">)。可以通过框架提供的API(如React的useEffect、Vue的生命周期钩子mounted等)在页面加载时触发功能组件的加载。通过<iframe>标签或动态脚本注入的方式，将在线访问链接加载到目标前端框架的页面中。例如，使用<iframe src＝"online-link.html">< / iframe>将链接嵌入到页面。

[0093] 嵌入功能组件是指将从在线访问链接获取到的JS文件和资源文件渲染到目标前端框架的页面中，使功能组件能够像本地组件一样工作。嵌入的过程通常会涉及挂载、数据传递和交互等步骤。运行功能组件是指功能组件被正确加载并渲染到页面上，用户可以与其交互，业务逻辑开始执行。

[0094] 使用目标前端框架的生命周期函数(如React的componentDidMount、Vue的mounted等)，确保在页面加载完成后再加载功能组件。通过事件监听或脚本加载的方式，将功能组件的初始化和挂载逻辑注入到目标框架中。对于复杂组件，可能还需要设置数据传递和状态同步机制。如果通过<iframe>加载，确保组件能够与目标框架的主页面进行数据和事件的双向通信，通常通过postMessage或其他通信机制实现。

[0095] 通过在目标前端框架的页面中加载在线访问链接并将功能组件嵌入页面运行，开发者可以实现功能组件的跨框架复用和加载。这使得组件能够在不同框架中保持一致的功能和表现，同时减少了重复开发和维护的工作量，并确保在多框架应用中的一致性。

[0096] S70，使用标准化的通信接口，在宿主框架与所述目标前端框架中的功能组件之间建立双向通信，用于传递业务数据和事件交互。

[0097] 在本实施例中，标准化通信接口是一个通用的接口，用于在不同框架之间传递消息和数据。标准化的通信接口确保宿主框架(即加载功能组件的框架)与目标前端框架(即运行功能组件的框架)能够通过一致的协议进行数据交换。通信接口的标准化意味着不依赖于任何特定框架，而是使用如postMessage、WebSocket等通用的通信协议来确保跨框架的数据传输和事件交互。双向通信指的是宿主框架与目标前端框架中的功能组件能够互相发送和接收消息。这是为了确保双方可以实时交换业务数据和事件，功能组件能够与宿主框架进行无缝互动。

[0098] 宿主框架指的是运行或承载外部功能组件的框架或系统。它是加载和执行功能组件的主要环境，负责与目标前端框架中的功能组件进行通信和数据交互。宿主框架通过加载外部资源(如JS文件、HTML页面等)来嵌入和运行独立开发的功能组件。它为功能组件提供加载的容器(如HTML页面中的挂载节点)。宿主框架通过标准化的通信接口(如postMessage)与目标前端框架中的功能组件进行双向数据交换，处理业务数据的传递和事件交互。这种双向通信确保功能组件可以正常工作，并与宿主框架的数据和状态保持同步。宿主框架控制着功能组件的加载、初始化、运行和销毁。它管理组件的生命周期，使功能组件在框架内部有序运行。

[0099] 示例说明：在一个React应用中，如果通过<iframe>加载另一个由Vue.js开发的功能组件，那么React应用就是宿主框架，而Vue.js的功能组件则是在目标前端框架中运行的组件。React框架需要通过标准化接口与Vue功能组件进行通信，以实现数据的同步和事件交互。

[0100] 通过通用的标准(如postMessageAPI、WebSocket、或自定义的事件总线)定义通信接口，使得宿主框架和目标前端框架能够通过该接口发送和接收数据。在宿主框架中，创建一个通信通道，并通过该通道向目标前端框架发送初始化消息，通知组件通信的开始。目标前端框架接收到消息后，也会通过相同的通道发送响应消息，以建立双向通信。

[0101] 双向通信机制通过标准化通信接口允许宿主框架和目标框架中的功能组件互相发送数据和事件。通过这种机制，宿主框架可以发送数据更新或操作指令给功能组件，功能组件则可以将处理后的数据或用户事件反馈给宿主框架。双向通信确保了数据的及时传递和处理，使得业务逻辑能够实时更新，用户交互能够被及时响应，确保系统的流畅性。

[0102] 通过postMessageAPI，宿主框架可以将业务数据发送到目标前端框架中的功能组件，功能组件也可以将事件数据返回给宿主框架。postMessage是一个常见的浏览器API，用于在不同窗口、iframe或者跨域环境中传递消息。在宿主框架和目标框架中分别设置事件监听器，用于捕获对方发送的消息。例如，在宿主框架中设置window.addEventListener('message',callback)，监听来自功能组件的消息。为了确保通信的安全性，消息在传递过程中需要校验消息来源(如origin)并处理可能的安全问题，防止恶意消息的注入。

[0103] 业务数据传递指的是宿主框架和目标前端框架之间传递与应用相关的核心业务数据，如用户信息、交易数据、配置参数等。通信接口应该支持序列化的数据格式(如JSON)来确保不同框架能够解析和处理数据。事件交互指的是通过双向通信机制，宿主框架和目标前端框架能够处理用户事件(如点击、输入等)以及系统事件(如数据加载、状态更新等)，并对这些事件做出相应的操作。

[0104] 在宿主框架中，发送经过序列化的业务数据(如JSON对象)到功能组件，功能组件通过通信接口解析数据并处理。当用户在目标前端框架中的功能组件上进行操作时(如按钮点击、表单提交)，组件将事件通过通信接口传递给宿主框架，宿主框架对该事件进行处理或根据业务逻辑触发相应操作。

[0105] 通过使用标准化的通信接口建立双向通信，宿主框架与目标前端框架之间能够无缝传递业务数据和事件交互。确保了跨框架的兼容性和灵活性，减少了跨框架数据传输和事件处理中的复杂性。双向通信实现了功能组件与宿主框架的实时同步，提升了系统的响应速度和用户体验。

[0106] 本发明涉及一种基于现有组件的跨框架兼容方法，通过提取现有前端框架中的功能组件，将业务逻辑和UI组件分离封装在独立项目中，并抽象出与框架无关的接口和方法，使得功能组件能够在不同前端框架中加载和运行。功能组件打包生成独立的JS文件和资源文件，结合到HTML页面中后，生成在线访问链接，并嵌入到目标前端框架中运行。同时，利用标准化通信接口，实现宿主框架与目标框架中功能组件之间的双向通信，进行业务数据传递和事件交互。本发明通过对功能组件的封装和抽象接口的标准化处理，解决了现有技术中功能组件在不同框架中难以复用的问题，使功能组件能够在多框架中灵活部署和运行，从而减少了开发工作量，提高了系统的扩展性和维护效率。

[0107] 在一个实施例中，上述S50中，生成在线访问链接之后，还包括：

[0108] S501，在非H5端设备中嵌入WebView，通过所述WebView加载所述在线访问链接，将功能组件加载到非H5端的应用程序中；

[0109] S502，在业务方加载所述在线访问链接时，在所述在线访问链接中附加URL参数，将初始化数据传递给组件方；

[0110] S503，组件方在加载HTML页面时解析所述URL参数，获取业务方传递的所述初始化数据；

[0111] S504，组件方通过WebView的窗口对象与业务方进行双向通信，传递业务数据和事件，完成功能组件与非H5端设备之间的数据交互。

[0112] 在本实施例中，非H5端设备指的是不基于传统浏览器Web环境的设备，如iOS、Android等移动设备上的原生应用。这些设备不直接运行HTML5页面，而是通过嵌入的WebView来加载Web内容。WebView是一种在原生应用程序中嵌入Web页面的方式，使得应用可以加载和显示HTML内容。通过WebView，可以将功能组件嵌入到非H5端设备的原生应用中。

[0113] 在非H5端设备的原生应用(如Android或iOS应用)中，嵌入WebView控件。通过WebView加载之前生成的在线访问链接，通常使用loadUrl()(Android)或loadRequest()(iOS)方法来加载链接。确保WebView的配置允许组件在原生应用中正常渲染和交互，包括启用JavaScript、处理页面导航等。

[0114] URL参数是指在URL末尾附加的键值对，通常用于传递数据到服务器或客户端。这里指的是在业务方(原生应用)加载在线访问链接时，将初始化数据(如用户ID、会话信息等)作为URL参数附加，传递给功能组件以供其初始化使用。在加载在线访问链接时，将初始化数据以键值对的形式作为查询参数附加到URL中。业务方通过生成正确的在线访问链接并附加参数，确保这些数据能够在WebView加载页面时传递到功能组件。

[0115] 在Web页面加载时，组件需要解析附加在URL中的查询参数，并根据这些参数进行初始化操作，如配置用户环境或加载特定数据。在功能组件加载的HTML页面中，使用JavaScript从URL中提取参数。可以通过window.location.search获取查询字符串，并使用URLSearchParams解析参数。将解析出的参数传递给功能组件的业务逻辑，初始化组件所需的环境和数据(如用户信息、会话数据等)。

[0116] WebView在运行时允许JavaScript与原生代码进行交互。窗口对象(如window.WebViewJavascriptBridge)是这种双向通信的接口，允许Web端和原生端之间传递消息和数据。双向通信指组件方与业务方之间的双向数据交换，组件可以通过窗口对象发送数据给业务方，业务方也可以通过WebView接口将数据发送给组件。

[0117] 使用原生平台的WebView接口实现双向通信，例如在Android中通过JavascriptInterface，在iOS中通过WKScriptMessageHandler实现与网页中的JavaScript交互。在WebView中的功能组件可以通过window.postMessage或自定义的JavaScript接口与原生应用进行数据交互。确保数据(如业务数据、事件)能够在WebView和原生应用之间顺利传递，实现业务逻辑的双向互动。

[0118] 本实施例通过在非H5端设备上嵌入WebView并加载在线访问链接，可以将Web组件灵活集成到原生应用中。URL参数用于传递初始化数据，确保功能组件根据业务方的数据进行正确配置。同时，借助WebView的窗口对象实现双向通信，确保功能组件与原生应用之间的实时数据和事件交互。这种机制使得非H5端设备能够加载并运行基于Web的功能组件，提供更灵活的解决方案。

[0119] 在一个实施例中，上述S10中，从现有前端框架中提取功能组件，包括：

[0120] S101，通过自动化工具扫描所述现有前端框架的项目文件夹，解析所述现有前端框架中的目录结构，识别功能组件的模块和文件的位置；

[0121] S102，对所述模块和文件进行静态代码分析，识别并定位功能组件中的业务逻辑模块和UI模块；

[0122] S103，使用静态分析工具将功能组件中的业务逻辑模块和UI模块分离，生成多个独立的逻辑单元，所述逻辑单元用于在独立项目中进行封装，以形成能在不同前端框架中运行的功能组件。

[0123] 在本实施例中，使用自动化工具(如代码静态分析工具、代码扫描工具)对现有前端框架的项目进行扫描和分析。该工具能够自动解析项目中的目录结构和文件组织，快速识别项目中的模块和文件。这些工具能够通过分析项目文件夹中的代码文件和目录，找到不同功能模块的位置，并识别其与其他模块之间的关系。对项目文件夹中的目录结构进行解析，确定文件和模块的层级结构和位置，确保提取的功能组件是独立、可复用的模块。

[0124] 静态代码分析是指在不执行代码的情况下，通过自动化工具对源代码进行解析和分析，识别出业务逻辑和UI逻辑。这可以帮助开发者快速定位代码中的功能组件以及它们的相互依赖关系。静态代码分析工具可以检测模块中使用的变量、函数、依赖的库等，明确每个模块的功能和用途。通过静态代码分析工具，系统可以区分出哪些模块负责处理数据和业务逻辑(如API调用、数据处理)，哪些模块负责用户界面(如视图渲染、用户输入)。

[0125] 使用静态分析工具，将功能组件中的业务逻辑部分与UI呈现部分分开，使其成为独立的逻辑单元。这种分离有助于增强代码的模块化和可维护性，使业务逻辑和UI能够在不同的环境中复用，并适应不同的前端框架。将分离后的业务逻辑和UI模块组织成独立的模块化单元，每个单元可以单独测试、封装和维护。这些逻辑单元可以在不同的前端框架(如React、Vue、Angular)中运行，具有高度的灵活性。

[0126] 本实施例通过使用自动化工具扫描项目文件夹，解析目录结构并进行静态代码分析，能够快速识别、定位并分离功能组件中的业务逻辑模块和UI模块。这种分离和模块化操作生成了独立的逻辑单元，使得功能组件可以在不同前端框架中无缝加载和运行，极大提高了功能组件的跨框架复用性和可维护性。

[0127] 在一个实施例中，上述S20中，创建独立项目，在所述独立项目中对所述功能组件进行封装，包括：

[0128] S201，通过初始化工具创建与现有前端框架隔离的独立项目，并配置依赖项，所述依赖项包括模块管理工具、构建工具和跨框架兼容工具；

[0129] S202，将所述业务逻辑封装为独立的功能模块，通过标准化接口提供服务并与封装后的其他功能模块交互；

[0130] S203，将所述UI组件封装为独立的视图模块，通过事件驱动或接口与封装后的功能模块进行交互；

[0131] S204，通过标准化接口或事件机制将所述功能模块和视图模块组合封装为一个完整的功能组件。

[0132] 在本实施例中，初始化工具指用于快速创建项目的工具，如create-react-app、Vue CLI、Angular CLI等。这些工具能够自动生成项目结构，配置必要的文件，并初始化项目环境。在创建新项目时，使其独立于现有的前端框架，以避免与当前项目之间的依赖或冲突。这意味着新项目中的业务逻辑和UI组件将不会直接依赖现有框架的代码。

[0133] 模块管理工具指的是用于管理项目中依赖的模块和库的工具，如npm、yarn等。它们能够管理第三方库、依赖模块等资源。构建工具指用于编译和打包项目的工具，如Webpack、Vite，它们能够将代码打包成在不同平台中可执行的文件。跨框架兼容工具是指在不同框架中使用的工具和库，确保组件能够在多种前端框架(如React、Vue、Angular等)中运行。

[0134] 业务逻辑封装为独立功能模块是指将业务逻辑(如数据处理、API调用等)封装成模块化的独立单元，确保它们能够单独运行和维护。通过定义标准化接口来提供服务，这些接口使模块可以通过定义的协议进行通信和数据传递，而不依赖于特定框架的API。不同的功能模块通过这些接口进行交互，共享数据和状态，实现组件的业务逻辑和操作。

[0135] 将UI界面(如按钮、输入框、表单等)封装为独立的视图模块，确保这些UI组件可以在不同的前端框架中加载和展示。通过事件机制(如点击事件、输入事件)或接口(如属性传递、回调函数)与功能模块交互，使得UI组件能够触发业务逻辑，或者从业务逻辑中接收数据并进行渲染。

[0136] 使用标准化接口或事件驱动机制将业务逻辑模块与UI模块进行组合，使得视图与逻辑紧密结合，形成独立的功能组件。这种组合方式使得功能组件在不同的框架中都能够保持一致的行为和表现。完整功能组件指的是业务逻辑和UI模块通过接口和事件机制进行结合，形成具备完整功能的组件，能够独立执行业务操作，并通过UI与用户进行交互。

[0137] 使用标准化接口将业务逻辑模块与UI模块连接，确保数据和事件能够从UI传递到业务逻辑，并在必要时将数据反馈给UI进行更新。通过事件机制(如发布-订阅模式)确保模块间的松耦合，使得功能组件内部可以灵活扩展，并在不同框架中运行时保持一致的功能表现。

[0138] 本实施例通过初始化工具创建独立项目并配置跨框架兼容的依赖项，能够使功能组件脱离现有框架，独立运行。将业务逻辑和UI组件分离并分别封装成独立模块后，再通过标准化接口和事件机制将二者组合为完整的功能组件。这种封装和组合的方式使得组件在不同前端框架中具备良好的兼容性和复用性，减少了跨框架开发中的重复劳动，并提高了系统的维护效率和扩展性。

[0139] 在一个实施例中，上述S30中，对所述封装后的功能组件抽象出与框架无关的接口和方法，包括：

[0140] S301，通过抽象方法为功能组件定义与前端框架无关的生命周期钩子接口，用于处理功能组件在不同前端框架中的加载、更新和卸载；

[0141] S302，为功能组件创建一个与前端框架无关的事件监听接口，使功能组件能够在不同框架中监听用户交互事件，并响应事件触发；

[0142] S303，为功能组件抽象出标准化的状态管理接口，定义setState方法用于更新功能组件的状态，定义getState方法用于获取功能组件的当前状态；

[0143] S304，为功能组件创建通用的数据和属性传递接口，所述传递接口包括setProps方法和getProps方法。

[0144] 在本实施例中，前端框架通常提供生命周期钩子来管理组件的加载、更新和卸载。为实现跨框架兼容性，需要抽象出与具体框架无关的生命周期钩子接口，使功能组件可以在不同的框架中遵循统一的生命周期模式。例如，React有componentDidMount，Vue有mounted，但它们都表达组件加载后的行为。抽象后的生命周期接口确保组件在加载、更新和销毁时调用适当的方法。定义统一的生命周期接口(如onMount、onUpdate、onDestroy)，用以处理组件在不同框架中的加载、更新和卸载。在不同框架的适配器中，将框架特定的生命周期钩子与抽象生命周期方法进行映射。例如，将Vue的mounted与抽象接口onMount关联。确保功能组件在调用这些钩子时，与框架的特定实现无关，便于组件在多框架下复用。

[0145] 在不同的前端框架中，用户交互事件(如点击、输入、悬停等)的监听机制有所不同。通过抽象事件监听接口，使得功能组件可以统一处理用户交互事件，而不依赖于某个框架特有的事件处理机制。例如，React使用onClick事件，Vue则使用@click。创建一个统一的事件监听接口(如addEventListener、removeEventListener)，通过该接口为组件注册和注销事件监听器。在框架适配器中，将框架特定的事件处理与抽象的事件接口关联。例如，在React中映射onClick事件到抽象接口addEventListener('click')。确保功能组件可以在任何框架中使用相同的事件监听逻辑，并响应用户的交互操作。

[0146] 在不同前端框架中，状态管理的方式有所不同。通过抽象出setState和getState方法，使功能组件能够以统一的方式管理内部状态。setState用于更新状态，getState用于获取当前状态。这样，组件不需要依赖特定的框架状态管理机制(如React的useState、Vue的reactive)。定义标准化的状态管理接口，使用setState(newState)更新组件状态，getState()返回当前组件状态。在框架适配器中，将框架特定的状态管理工具与抽象接口关联。例如，使用React的useState内部逻辑来实现setState和getState。确保无论是在React、Vue或其他框架中，功能组件都可以通过统一接口来更新和获取状态，而不需要改变组件内部的状态管理逻辑。

[0147] 在不同框架中，父组件向子组件传递数据的方式不同。为功能组件创建通用的setProps和getProps接口，确保组件可以在不同框架中通过统一的方式接收和管理外部传递的数据和属性。setProps用于接收外部传递的数据，getProps用于获取当前传递的属性。定义setProps(props)接口，用于接收父组件传递的数据，并更新组件的内部状态或显示。定义getProps()接口，允许子组件获取当前传递的属性。在框架适配器中，将框架特定的数据传递机制与抽象的setProps和getProps接口关联。例如，React中通过props传递数据，Vue通过props接收父组件的数据。

[0148] 本实施例通过抽象出与框架无关的接口和方法，功能组件可以在不同前端框架中无缝加载、运行和交互。生命周期钩子接口、事件监听接口、状态管理接口和数据传递接口的标准化，使功能组件不再依赖特定框架的API和机制，从而提高了组件的跨框架兼容性和复用性，减少了开发过程中针对不同框架的重复工作，并提高了系统的维护效率。

[0149] 在一个实施例中，上述S40包括：

[0150] S401，对功能组件的内部依赖和外部依赖进行拆分和管理，将内部依赖模块进行正确引用，并对外部依赖模块进行分离；

[0151] S402，使用Webpack或Vite进行打包配置，根据项目需求区分生产模式和开发模式；

[0152] S403，在生产模式下启用代码压缩和模块优化，在开发模式下保留调试功能；

[0153] S404，通过启用Tree Shaking功能自动移除未使用的代码，并使用Terser进行JavaScript压缩，生成轻量化的JS文件；

[0154] S405，通过打包工具自动识别和提取功能组件中的资源文件，并进行压缩优化；

[0155] S406，输出打包后的文件，生成独立的JS文件和资源文件，并通过哈希值为文件命名。

[0156] 在本实施例中，内部依赖指的是功能组件自身的模块依赖，如自定义的工具函数、组件内部的逻辑模块。这些模块是与功能组件直接相关的，不需要单独打包或外部提供。外部依赖是指功能组件使用的外部库或框架，如React、Vue、Lodash等。外部依赖需要在打包时分离，避免将其直接打包到组件中，以减少打包后的文件体积，并确保这些依赖项能够被外部管理或缓存。在项目中分析组件的依赖关系，使用工具(如Webpack的模块分析器)识别内部和外部依赖模块。将内部依赖打包到功能组件中，确保其在组件内部正常引用。外部依赖通过externals配置或peerDependencies声明，使其在打包过程中不被包含在最终的JS文件中，而是由使用该组件的应用来提供。

[0157] Webpack / Vite工具用于前端项目的打包和构建，提供模块化管理、依赖处理和文件输出。Webpack具有强大的配置能力，Vite则以开发效率和快速打包为特点。生产模式注重代码压缩和性能优化，生成轻量级的文件；开发模式则保留调试功能，便于开发者定位问题。配置Webpack或Vite的打包过程，区分生产模式(production)和开发模式(development)。在生产模式下启用优化功能，如代码压缩、性能调优等；在开发模式下启用调试功能，如source map生成和热重载等。

[0158] 在生产模式中，通过工具如Terser对JavaScript代码进行压缩，删除多余的空白和注释，减少文件体积。通过移除未使用的模块或代码段(如Tree Shaking)，进一步优化打包后的文件大小。开发模式保留调试功能(如source maps)，以便在开发过程中查看源代码并快速定位错误。

[0159] Tree Shaking是Webpack和Vite等工具中的一项优化功能，能够自动检测未使用的模块或代码，并将其从最终的打包文件中移除，从而减少文件大小。Terser是一个JavaScript压缩工具，可以将代码进行压缩和混淆，移除注释和不必要的空格，进一步减小文件体积。

[0160] 打包工具(如Webpack / Vite)能够自动识别功能组件中的CSS文件、图片、字体等资源，并将它们提取到单独的文件中，确保资源文件不会被嵌入到JavaScript代码中。对资源文件(如CSS、图片等)进行压缩，以减少文件体积，加快加载速度。例如，使用CSS压缩工具、图片优化工具等。

[0161] 为了解决浏览器缓存问题，打包工具通常会为生成的文件名添加一个唯一的哈希值。当文件内容发生变化时，文件名也会改变，确保浏览器加载最新版本的文件。打包工具会输出最终的JS文件和资源文件到指定的目录，供项目使用或部署到服务器。

[0162] 本实施例通过对功能组件进行打包、管理依赖、优化代码和资源文件，可以生成轻量化的JS文件和资源文件，确保组件在不同框架中高效运行。生产模式的压缩和模块优化显著减少了文件大小，而开发模式的调试功能便于开发和调试。通过哈希值命名文件，解决了缓存问题，确保用户始终获取到最新的组件版本。

[0163] 在一个实施例中，上述S70中，使用标准化的通信接口，在宿主框架与所述目标前端框架中的功能组件之间建立双向通信，包括：

[0164] S701，定义标准化通信接口，用于在宿主框架与目标前端框架之间传递消息；

[0165] S702，在宿主框架中创建用于数据交换的通信信道，所述通信信道支持双向数据传输；

[0166] S703，为数据传输定义统一的消息格式，使消息在宿主框架与功能组件之间能够以结构化的方式进行传递；

[0167] S704，在宿主框架与功能组件中分别设置事件监听器和触发器，用于捕捉和处理消息传递和事件触发；

[0168] S705，在通信接口中集成错误捕获功能，用于检测并处理通信过程中的异常情况。

[0169] 在本实施例中，标准化通信接口是一个通用的、与框架无关的接口，用于在宿主框架与目标前端框架中的功能组件之间进行消息传递。通信接口确保消息格式和传递逻辑一致，不依赖于某个具体的框架特性，允许不同框架之间进行无缝的数据交换和事件传递。

[0170] 通信信道是一个用于在宿主框架与目标前端框架之间传递数据的通道。通信信道支持双向传输，使得数据可以从宿主框架传递到功能组件，反之亦然。它确保了宿主框架与功能组件之间的实时数据交互。

[0171] 在宿主框架与功能组件之间传递的数据应当遵循统一的格式，以确保消息能够被双方正确解析和处理。通常使用结构化的数据格式，如JSON，来传递消息和数据。定义标准化的消息格式(如JSON)，其中包含消息类型、数据内容和其他必要的元信息。确保宿主框架和功能组件在发送和接收消息时，都能够正确地序列化和反序列化消息数据，并根据消息的类型和内容做出相应处理。

[0172] 宿主框架和功能组件需要通过事件监听器来捕捉对方发送的消息，触发器则用于向对方发送消息或触发事件。事件监听器和触发器的结合确保双向通信的实时性和可靠性。在宿主框架中设置事件监听器(如window.addEventListener('message'))，用于捕捉来自功能组件的消息，并根据消息的类型触发相应的处理逻辑。在功能组件中设置触发器，能够将特定的事件和数据传递给宿主框架，并确保响应的事件在功能组件中被正确触发。

[0173] 在双向通信过程中，可能会出现传递的数据格式错误、连接中断、或者解析失败等异常情况。集成错误捕获功能能够检测到这些问题，并提供相应的处理措施，确保通信的可靠性和稳定性。在通信接口中添加错误捕获功能(如try-catch块或专门的错误处理函数)，检测传递数据的异常情况(如格式错误、网络问题等)。当检测到错误时，向对方发送错误通知，并记录或处理该错误，确保通信恢复或及时进行故障排除。

[0174] 本实施例通过使用标准化通信接口和统一的消息格式，在宿主框架与功能组件之间建立了稳定的双向通信通道。事件监听器、触发器、以及错误捕获机制确保消息的传递准确且实时，即使在通信过程中出现异常情况，系统也能检测并处理。这种设计不仅提高了跨框架组件通信的效率和可靠性，还增强了系统的灵活性和可扩展性。

[0175] 本发明还提供一种基于现有组件的跨框架兼容装置，参照图2，图2为本发明基于现有组件的跨框架兼容装置一较佳实施例的功能模块示意图。所述基于现有组件的跨框架兼容装置包括：

[0176] 现有组件提取模块，用于从现有前端框架中提取功能组件，所述功能组件包括业务逻辑和UI组件；

[0177] 现有组件封装模块，用于创建独立项目，在所述独立项目中对所述功能组件进行封装，使所述功能组件的业务逻辑与现有前端框架的业务逻辑分离；

[0178] 抽象接口模块，用于对所述封装后的功能组件抽象出与框架无关的接口和方法，使所述功能组件适用于不同前端框架的加载和运行；

[0179] 组件打包模块，用于对封装后的功能组件进行打包，生成独立的JS文件和资源文件；

[0180] 页面生成模块，用于创建包含功能组件挂载节点的HTML页面，将所述JS文件与资源文件结合到所述HTML页面中，并将结合后的HTML页面上传至服务器，并生成在线访问链接；

[0181] 组件加载模块，用于在目标前端框架的页面中加载所述在线访问链接，将所述功能组件嵌入到所述目标前端框架的页面中运行；

[0182] 跨框架通信模块，用于使用标准化的通信接口，在宿主框架与所述目标前端框架中的功能组件之间建立双向通信，用于传递业务数据和事件交互。

[0183] 本发明基于现有组件的跨框架兼容装置的具体实施方式与上述基于现有组件的跨框架兼容方法各实施例基本相同，在此不再赘述。

[0184] 本发明还提供一种基于现有组件的跨框架兼容设备，如图3所示，该基于现有组件的跨框架兼容设备可以包括：处理器1001，例如CPU，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatilememory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储设备。

[0185] 本领域技术人员可以理解，图3中示出的基于现有组件的跨框架兼容设备的硬件结构并不构成对基于现有组件的跨框架兼容设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

[0186] 如图3所示，作为一种存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及基于现有组件的跨框架兼容程序。其中，操作系统是管理和控制基于现有组件的跨框架兼容设备与软件资源的程序，支持网络通信模块、用户接口模块、基于现有组件的跨框架兼容程序以及其他程序或软件的运行；网络通信模块用于管理和控制网络接口1004；用户接口模块用于管理和控制用户接口1003。

[0187] 在图3所示的基于现有组件的跨框架兼容设备硬件结构中，网络接口1004主要用于连接后台服务器，与后台服务器进行数据通信；用户接口1003主要用于连接客户端，与客户端进行数据通信；处理器1001可以调用存储器1005中存储的基于现有组件的跨框架兼容程序，并执行与基于现有组件的跨框架兼容方法相同的操作。

[0188] 本发明基于现有组件的跨框架兼容设备的具体实施方式与上述基于现有组件的跨框架兼容方法各实施例基本相同，在此不再赘述。

[0189] 此外，本发明实施例还提出一种计算机存储介质，计算机存储介质上存储有基于现有组件的跨框架兼容程序，基于现有组件的跨框架兼容程序被处理器执行时实现如上所述的基于现有组件的跨框架兼容方法的步骤。

[0190] 本发明计算机存储介质具体实施方式与上述基于现有组件的跨框架兼容方法各实施例基本相同，在此不再赘述。

[0191] 应当说明的是，本申请实施例中若出现了非本公司的软件工具或组件，仅仅是用于举例介绍，并不代表实际使用。< / style> < / section>

Claims

1. A cross-framework compatibility method based on existing components, characterized in that: The following steps are involved: Extract functional components from the existing front-end framework, wherein the functional components include business logic and UI components; Create an independent project, encapsulate the functional component in the independent project, and separate the business logic of the functional component from the business logic of the existing front-end framework; Abstracting the framework-independent interfaces and methods of the encapsulated functional components, so that the functional components are suitable for loading and running in different front-end frameworks; Package the encapsulated functional components to generate independent JS files and resource files; Create an HTML page containing a functional component mounting node, combine the JS file and the resource file into the HTML page, upload the combined HTML page to a server, and generate an online access link; Loading the online access link in a page of a target front-end framework, embedding the functional component into the page of the target front-end framework for execution; Using standardized communication interfaces, bidirectional communication is established between the host framework and the functional components in the target front-end framework for transmitting business data and event interaction.

2. The cross-framework compatibility method based on existing components as described in claim 1, characterized in that: After generating the online access link, it also includes: Embed a WebView in a non-H5 terminal device, load the online access link through the WebView, and load the functional component into the non-H5 terminal application; When the service side loads the online access link, a URL parameter is added to the online access link to pass the initialization data to the component side; The component party parses the URL parameters when loading the HTML page and obtains the initialization data passed by the business party; The component party conducts two-way communication with the business party through the WebView window object, transmits business data and events, and completes data interaction between functional components and non-H5 terminal devices.

3. The cross-frame compatibility method based on existing components as described in claim 1, characterized in that: Extract functional components from existing front-end frameworks, including: Scan the project folder of the existing front-end framework through an automated tool, parse the directory structure in the existing front-end framework, and identify the locations of modules and files of functional components; Perform static code analysis on the modules and files to identify and locate business logic modules and UI modules in functional components; Use static analysis tools to separate the business logic module and UI module in the functional component to generate multiple independent logic units, which are used to be encapsulated in independent projects to form functional components that can run in different front-end frameworks.

4. The cross-framework compatibility method based on existing components as claimed in claim 1, characterized in that: Create an independent project, and encapsulate the functional components in the independent project, including: Create an independent project isolated from the existing front-end framework through the initialization tool, and configure dependencies, including module management tools, build tools, and cross-framework compatibility tools; Encapsulate the business logic into an independent functional module, provide services through a standardized interface and interact with other encapsulated functional modules; Encapsulate the UI component into an independent view module, and interact with the encapsulated functional module through event drive or interface; The functional module and the view module are combined and encapsulated into a complete functional component through a standardized interface or event mechanism.

5. The cross-framework compatibility method based on existing components as described in claim 1, characterized in that: Abstracting the encapsulated functional components into interfaces and methods that are not related to the framework, including: Define a lifecycle hook interface for functional components that is independent of the front-end framework through abstract methods to handle the loading, updating, and unloading of functional components in different front-end frameworks; Create an event listening interface for the functional component that is independent of the front-end framework, so that the functional component can listen to user interaction events in different frameworks and respond to event triggers; Abstract a standardized state management interface for functional components, define the setState method to update the state of functional components, and define the getState method to obtain the current state of functional components; A general data and property transfer interface is created for functional components, wherein the transfer interface includes a setProps method and a getProps method.

6. The cross-framework compatibility method based on existing components as claimed in claim 1, characterized in that: Package the encapsulated functional components to generate independent JS files and resource files, including: Split and manage the internal and external dependencies of functional components, correctly reference internal dependency modules, and separate external dependency modules; Use Webpack or Vite for packaging configuration, and distinguish between production mode and development mode according to project requirements; Enable code compression and module optimization in production mode, and retain debugging capabilities in development mode; Automatically remove unused code by enabling the Tree Shaking function, and use Terser to compress JavaScript to generate lightweight JS files; Automatically identify and extract resource files in functional components through packaging tools, and perform compression optimization; Output the packaged files, generate independent JS files and resource files, and name the files according to the hash value.

7. The cross-framework compatibility method based on existing components as claimed in claim 1, characterized in that: Using a standardized communication interface, two-way communication is established between the host framework and the functional components in the target front-end framework, including: Define a standardized communication interface for passing messages between the host framework and the target front-end framework; Creating a communication channel for data exchange in a host framework, wherein the communication channel supports bidirectional data transmission; Define a unified message format for data transmission so that messages can be passed between the host framework and functional components in a structured manner; Set up event listeners and triggers in the host framework and functional components respectively to capture and process message transmission and event triggering; An error capture function is integrated into the communication interface to detect and handle abnormal situations during the communication process.

8. A cross-frame compatible device based on existing components, characterized in that: The cross-framework compatible device based on existing components includes: An existing component extraction module is used to extract functional components from an existing front-end framework, wherein the functional components include business logic and UI components; An existing component encapsulation module is used to create an independent project, encapsulate the functional component in the independent project, and separate the business logic of the functional component from the business logic of the existing front-end framework; An abstract interface module is used to abstract the encapsulated functional components into interfaces and methods that are independent of the framework, so that the functional components are suitable for loading and running in different front-end frameworks; The component packaging module is used to package the encapsulated functional components and generate independent JS files and resource files; A page generation module is used to create an HTML page containing a functional component mounting node, combine the JS file and the resource file into the HTML page, upload the combined HTML page to a server, and generate an online access link; A component loading module, used to load the online access link in the page of the target front-end framework, and embed the functional component into the page of the target front-end framework for operation; The cross-framework communication module is used to establish two-way communication between the host framework and the functional components in the target front-end framework using a standardized communication interface, so as to transmit business data and event interaction.

9. A cross-frame compatible device based on existing components, characterized in that: The cross-framework compatible device based on existing components includes a memory, a processor, and a cross-framework compatible program based on existing components stored in the memory and executable on the processor. When the cross-framework compatible program based on existing components is executed by the processor, the steps of the cross-framework compatible method based on existing components as described in any one of claims 1 to 7 are implemented.

10. A computer storage medium, characterized in that: The storage medium stores a cross-framework compatible program based on existing components, and when the cross-framework compatible program based on existing components is executed by the processor, the steps of the cross-framework compatible method based on existing components as described in any one of claims 1-7 are implemented.

Images