Methods, systems, devices, and storage media for implementing a cross-platform web component architecture
By defining an abstract Web component model and platform adapters, and utilizing the runtime environment for adapter registration and mapping, the problem of insufficient platform compatibility and scalability in cross-platform Web componentization technology is solved, realizing the reusability and flexibility of cross-platform Web components.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- THREE GORGES HI TECH INFORMATION TECH CO LTD
- Filing Date
- 2025-08-19
- Publication Date
- 2026-07-21
AI Technical Summary
Existing Web componentization technologies suffer from poor platform compatibility, insufficient scalability, and lack of flexibility in cross-platform compatibility.
By defining an abstract Web component model and a platform adapter, the adapter is registered using the registration API provided by the runtime environment. The target platform adapter is selected and loaded, and the target platform adapter calls the target platform API to map the abstract Web component model to the target platform.
It achieves reusability and flexibility of cross-platform web components and solves the problem of insufficient scalability of cross-platform web component architecture.
Smart Images
Figure CN121070355B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of software technology, and specifically to a cross-platform Web component architecture method, system, device, and computer-readable storage medium. Background Technology
[0002] As Web technologies continue to develop, Web applications are becoming increasingly complex, and the need to improve scalability and flexibility is becoming more and more urgent.
[0003] Among related technologies, the main Web componentization technologies include the Web Components standard, framework-based componentization solutions, and cross-platform Web frameworks. However, existing Web componentization technologies have significant problems in terms of cross-platform compatibility. Different browsers have varying degrees of support for the Web Components standard, resulting in poor platform compatibility of components; framework-based components are usually tightly bound to specific frameworks, making them difficult to reuse across different frameworks, and even Web Components may encounter compatibility issues when used in different frameworks, greatly limiting component reusability; existing cross-platform Web componentization solutions have relatively fixed component architectures, and their scalability and flexibility are still insufficient. Summary of the Invention
[0004] This application provides a method, system, device, and computer-readable storage medium for implementing a cross-platform Web component architecture, which can solve the technical problems of insufficient scalability and flexibility of existing cross-platform Web component architectures.
[0005] In a first aspect, embodiments of this application provide a method for implementing a cross-platform Web component architecture, the method comprising: In a Web component, each platform adapter calls the registration API provided by the runtime environment to register each platform adapter with the runtime environment; each platform adapter contains an interface that implements the interface defined by the abstract Web component model and a standard adapter interface that implements the runtime environment. Before a web component runs on a target platform, the runtime environment selects and loads the target platform adapter corresponding to the target platform. The target platform adapter calls the target platform's API to map the abstract web component model to the target platform.
[0006] In conjunction with the first aspect, in one implementation, the runtime environment selecting and loading the target platform adapter corresponding to the target platform includes: The runtime environment identifies the target attributes of the target platform; Select and load the target platform adapter that matches the target attributes; The runtime environment provides a standard platform adapter interface, which allows the runtime environment to call the corresponding platform adapter on any platform, regardless of the platform it is on.
[0007] In conjunction with the first aspect, in one implementation, the abstract Web component model is defined through a metadata structure. The abstract Web component model only defines structural specifications and does not involve specific implementation logic, thereby decoupling the abstract Web component model from any platform.
[0008] In conjunction with the first aspect, in one implementation, mapping the abstract Web component model to the target platform includes: If the target platform has a native DOM environment, the platform adapter directly calls the target platform's native DOM API to implement the mapping of the abstract Web component model to the target platform.
[0009] In conjunction with the first aspect, in one implementation, mapping the abstract Web component model to the target platform includes: If the target platform does not have a native DOM environment, the platform adapter uses a virtual DOM library to simulate DOM operations and generate HTML strings. The target platform parses the generated HTML strings to enable the mapping of the abstract Web component model to the target platform.
[0010] Secondly, embodiments of this application provide a system for implementing a cross-platform Web component architecture. The system includes an abstract Web component model, a runtime environment, and multiple platform adapters, wherein: Each platform adapter calls the registration API provided by the runtime environment to register itself with the runtime environment; each platform adapter contains a complete implementation of the interfaces defined by the abstract Web Components model and a complete implementation of the standard adapter interfaces defined by the runtime environment. Before a web component runs on a target platform, the runtime environment selects and loads the target platform adapter corresponding to the target platform. The target platform adapter calls the target platform's API to map the abstract web component model to the target platform.
[0011] In conjunction with the second aspect, in one implementation, the target platform adapter is specifically used for: If the target platform has a native DOM environment, then the target platform's native DOM API is called to enable the mapping of the abstract Web component model to the target platform.
[0012] In conjunction with the second aspect, in one implementation, the target platform adapter is specifically used for: If the target platform does not have a native DOM environment, a virtual DOM library is used to simulate DOM operations and generate HTML strings; The target platform is specifically used to parse the generated HTML string in order to enable the mapping of the abstract Web component model to the target platform.
[0013] Thirdly, embodiments of this application provide an apparatus for implementing a cross-platform Web component architecture. The apparatus for implementing a cross-platform Web component architecture includes a processor, a memory, and a program for implementing a cross-platform Web component architecture stored in the memory and executable by the processor. When the program for implementing a cross-platform Web component architecture is executed by the processor, it implements the steps of the method for implementing a cross-platform Web component architecture as described in the first aspect.
[0014] Fourthly, embodiments of this application provide a computer-readable storage medium, characterized in that the computer-readable storage medium stores a program for implementing a cross-platform Web component architecture, wherein when the program for implementing the cross-platform Web component architecture is executed by a processor, it implements the steps of the method for implementing a cross-platform Web component architecture as described in the first aspect.
[0015] The beneficial effects of the technical solutions provided in this application include: In a Web component, each platform adapter calls the registration API provided by the runtime environment to register itself with the runtime environment. Each platform adapter includes interfaces implementing the abstract Web component model and standard adapter interfaces defined by the runtime environment. Before the Web component runs on the target platform, the runtime environment selects and loads the target platform adapter corresponding to the target platform. The target platform adapter calls the target platform's API to map the abstract Web component model to the target platform. This embodiment of the application solves the technical problem of insufficient scalability and flexibility in cross-platform Web component architectures in related technologies. Attached Figure Description
[0016] Figure 1 This is a flowchart illustrating an embodiment of the method for implementing a cross-platform Web component architecture according to this application; Figure 2 Detailed flowchart of an embodiment of the method for implementing a cross-platform Web component architecture according to this application; Figure 3 This is a schematic diagram of the hardware structure of the device implementing the cross-platform Web component architecture involved in the embodiments of this application. Detailed Implementation
[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.
[0018] First, some of the technical terms used in this application will be explained to help those skilled in the art understand this application.
[0019] Runtime Environment: In the cross-platform architecture of Web components, the runtime environment is a lightweight core scheduling layer responsible for coordinating the interaction between component logic and different target platforms. It acts as a "translator" and "scheduling center," allowing components to focus on business logic implementation without worrying about underlying platform differences.
[0020] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.
[0021] In a first aspect, embodiments of this application provide a method for implementing a cross-platform Web component architecture.
[0022] In one embodiment, reference is made to Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of a method for implementing a cross-platform Web component architecture according to this application. Figure 1 As shown, methods for implementing a cross-platform Web component architecture include: Step S10: In the Web component, each platform adapter calls the registration API provided by the runtime environment to register each platform adapter to the runtime environment; wherein, each platform adapter includes an interface that implements the interface defined by the abstract Web component model and a standard adapter interface that implements the runtime environment. Step S20: Before the Web component runs on the target platform, the runtime environment selects and loads the target platform adapter corresponding to the target platform. In step S30, the target platform adapter calls the target platform's API to map the abstract Web component model to the target platform.
[0023] In this embodiment of the application, for example, if a Web component has compatibility issues on the target platform (such as browser DOM, Node.js server-side rendering environment, React framework, Vue framework, etc.), then within the Web component, an abstract Web component model described using a standardized data structure (such as JSON Schema) is first defined to force the Web component to separate the core business logic from the platform-related rendering logic.
[0024] For example, the content of a defined abstract web component model should include at least: Lifecycle hooks: Define a set of standard lifecycle phases (such as initialization, mounting, updating, and destruction), during which web components can perform initialization, resource allocation, update logic, and cleanup operations. The names and triggering times of these hooks are platform-independent.
[0025] Properties: Define how a web component receives external data. The model specifies how properties are declared, their types (which can include common types such as strings, numbers, booleans, objects, arrays, etc.), default values, and the response mechanism when properties change, but it does not specify how the underlying data transfer is implemented.
[0026] Events: Define how a web component sends notifications to the outside world. The model specifies how events are declared, their names, and the data structure of their payloads, but does not specify the underlying mechanisms for triggering and listening to these events.
[0027] Method: Define the public methods of the Web component that can be called externally, along with their parameters and return value types.
[0028] Then, the platform adapter design process is executed. The platform adapter acts as a bridge between the abstract Web Component model and the target platform, primarily responsible for translating and mapping the abstract Web Component model into a structure recognizable by the target platform. Each target platform requires a corresponding platform adapter, and each platform adapter contains all the interfaces defined in the abstract Web Component model, including its lifecycle (such as initialization, mounting, updating, and destruction), properties, events, and methods, in order to translate the operations of the abstract Web Component model into platform-specific operations.
[0029] For example, adapter interface operations might include: Create platform-specific component instances; Add the child component to the parent component; Set component properties; Add an event listener; Render the component into the specified container; Destroy component instances and release resources, etc.
[0030] Furthermore, referring to Figure 2 , Figure 2 This is a detailed flowchart illustrating an embodiment of the method for implementing a cross-platform Web component architecture according to this application. Figure 2 As shown, the process of implementing a cross-platform Web component architecture can be broken down as follows: Since the Web component cannot determine which platform adapter to use as the target platform adapter when running on the target platform, a runtime environment is needed to manage the entire process. Therefore, a runtime environment is built in the Web component, which is essentially a lightweight core library. It is responsible for coordinating the entire mapping and execution process of the abstract Web component model, platform adapter, and target platform. First, the runtime environment provides a registration API for the platform adapter to call when it is generated, so that each platform adapter can be registered in the runtime environment. Second, the runtime environment also provides a set of standard adapter interfaces. Each generated platform adapter fully implements this set of standard adapter interfaces, so that the runtime environment can uniformly schedule the corresponding platform adapter when the Web component runs on different target platforms, without having to consider the underlying logic and compatibility issues of the target platform when running across platforms, thus shielding the differences between platforms. Finally, when the runtime environment selects a target platform adapter, it first determines the target attributes of the target platform, and then selects the appropriate target platform adapter based on the platform identifier of the platform adapter.
[0031] The specific technical means by which platform adapters shield platform differences include: Abstract Interfaces: Defining platform-independent abstract interfaces is key. Platform adapters only need to implement these interfaces, allowing the code of the upper-level abstract Web component model and framework to interact with the platform without needing to know the specific implementation of the underlying platform.
[0032] Conditional statements and branching: Within the platform adapter, conditional statements can be used to execute different code branches based on the current running platform or environment. For example, the native DOM API is used in the browser platform adapter, while the virtual DOM API is used in the Node.js adapter.
[0033] Feature detection: This function checks at runtime whether the platform supports certain APIs or features. For example, it can detect whether it's a browser environment or whether a specific Web API exists, selecting different implementation paths based on the detection results.
[0034] Spacers / Compatibility Layers: For APIs or features missing on certain platforms, spacers or compatibility layers can be used to simulate and supplement them, making their behavior consistent with the target platform. For example, in some older browsers, compatibility layers can be used to provide support for new JavaScript APIs or Web APIs. In the context of the virtual DOM, the virtual DOM itself can also be seen as a spacer for the real DOM, used to simulate DOM operations in non-DOM environments.
[0035] Dependency Injection / Service Locator: Patterns such as dependency injection or service locators can be used to manage and select appropriate target platform adapters. At runtime, the appropriate adapter instance is injected or located based on the environment or configuration.
[0036] Building a cross-platform web component runtime environment essentially involves constructing a lightweight, cross-platform runtime environment responsible for component loading, mounting, communication, and lifecycle management. The runtime environment provides a unified API for developers. The core idea is to create a lightweight, modular system focused on providing the core functionalities required to run and manage cross-platform web components, working in conjunction with platform adapters to shield against platform differences and achieve a reusable web component architecture. The process of building a cross-platform web component runtime environment can be summarized by the following key steps: Modular architecture design: The runtime environment is broken down into multiple independent modules, each responsible for a specific function, for example: Component Loader: Responsible for loading component definitions and code, and can support different component definition formats (e.g., class-based, functional components, etc.) and loading methods (e.g., loading from local files, remote URLs).
[0037] Renderer: Responsible for the rendering process of components. It works with the platform adapter to translate the virtual DOM or rendering description of components into platform-specific rendering instructions.
[0038] Event Manager: Responsible for event handling of components, including event registration, triggering, and bubbling / capturing mechanisms. It needs to work with the platform adapter to handle platform-specific event systems.
[0039] Lifecycle Manager: Responsible for managing the lifecycle of components, such as initialization, mounting, updating, and unmounting, and provides lifecycle hook functions for component developers to use.
[0040] Props & State Manager: Responsible for managing the component's props and state, providing a unified API for accessing and updating them, and triggering the component's re-rendering.
[0041] Component Registry: Maintains information about registered components, such as component name, component definition, and component metadata, to facilitate component search and instantiation.
[0042] Runtime API Layer: Provides a unified API for developers to use, such as component registration, component instantiation, and component lifecycle control.
[0043] Abstract core interface: Define abstract interfaces for various modules of the runtime environment, such as rendering engine interfaces, event manager interfaces, lifecycle manager interfaces, etc.
[0044] These interfaces should be platform-independent, focusing only on the core logic and operations of the component during runtime.
[0045] Platform adapters need to implement these interfaces to translate abstract operations into platform-specific implementations.
[0046] Implement the core module: Based on a modular architecture and abstract interfaces, the various core modules of the runtime environment are implemented.
[0047] The implementation of core modules remains lightweight and platform-independent, avoiding the introduction of platform-specific dependencies.
[0048] For example, the rendering engine can be based on a virtual DOM or other lightweight rendering description methods, rather than directly manipulating the platform DOM.
[0049] API Design and Implementation: The design provides a simple, easy-to-use, platform-independent API interface for developers to register components, instantiate components, and control component lifecycles.
[0050] API interfaces hide underlying platform differences, allowing developers to operate cross-platform web components in a unified way.
[0051] Platform adapter integration: The design mechanism integrates the platform adapter into the runtime environment.
[0052] You can select the appropriate platform adapter at runtime based on the target platform through dependency injection, service locators, or simple configuration methods.
[0053] The runtime environment interacts with the platform adapter through an abstract interface, thereby enabling cross-platform capabilities.
[0054] In addition, cross-platform web components developed based on the abstract web component model, in order to achieve true cross-platform reuse and maximize their value, must possess the following essential characteristics: Platform-independent implementation: The core logic does not depend on any platform-specific API (such as directly manipulating the document or a specific framework's API).
[0055] Dependency on abstract interfaces: Interact with the outside world through APIs provided by the runtime environment and communicate through interfaces (props, events, methods) defined by the abstract Web component model.
[0056] Encapsulation: The internal state and implementation details of a component are well encapsulated, exposing only the necessary interfaces.
[0057] Configurability: Configuration is received via properties (Props), and slots may be supported for custom content.
[0058] Advantages: Since the components themselves are platform-independent, the same component codebase can theoretically run in browsers, Node.js, Electron, or even integrated into React or Vue applications by simply switching different platform adapters and runtime environments, with only minor or no modifications to the component source code.
[0059] In addition, a cross-platform web component architecture should provide flexible ways to extend component functionality or runtime capabilities to adapt to specific needs.
[0060] The specific expansion method is as follows: Mixins: Allow reusable functionalities (such as data validation and access control) to be mixed into multiple components.
[0061] Higher-order components: These are components that wrap existing components with functions to enhance their functionality or properties.
[0062] Custom lifecycle hooks: Allows additional lifecycle hooks to be registered in the runtime environment for use by components or plugins.
[0063] Custom rendering logic: Allows developers to provide custom rendering logic for specific components or optimize rendering strategies for specific platforms.
[0064] Plugin system: The runtime environment can be designed with plugin interfaces, allowing third-party developers to extend the core functionality of the runtime, such as adding global state management, routing integration, etc.
[0065] In this embodiment, by defining an abstract Web component model, designing each platform adapter, and jointly constructing a runtime environment, the process of mapping and translating the abstract Web component model to the target platform is realized, enabling Web components to be reused across platforms. This solves the technical problem of insufficient scalability and flexibility of cross-platform Web component architecture in related technologies.
[0066] Furthermore, in one embodiment, the runtime environment selecting and loading the target platform adapter corresponding to the target platform includes: The runtime environment identifies the target attributes of the target platform; Select and load the target platform adapter that matches the target attributes; The runtime environment provides a standard platform adapter interface, which allows the runtime environment to call the corresponding platform adapter on any platform, regardless of the platform it is on.
[0067] In this embodiment of the application, for example, if a cross-platform button component needs to run in a browser environment, when the web component is loaded, the runtime environment first detects the target attributes of the current platform: Check if the global objects window and document have browser context characteristics; Verify the availability of DOM APIs such as document.createElement; The runtime environment verifies the browser user agent string (e.g., navigator.userAgent contains identifiers like Chrome / Firefox). Based on these characteristics, the runtime environment determines that the target platform is a standard browser environment. Then, the runtime environment retrieves matches from the registered adapters based on the target attribute (browser), finds the adapter with the key name "browser" (e.g., BrowserAdapter), and directly loads the instance of that adapter. After loading, the runtime environment schedules the platform adapter to render the web component through a standard interface.
[0068] Furthermore, in one embodiment, the abstract Web component model is defined through a metadata structure. The abstract Web component model only defines structural specifications and does not involve specific implementation logic, thereby decoupling the abstract Web component model from any platform.
[0069] In this embodiment, the abstract Web component model focuses on the state management, data processing, and external interaction logic of Web components, while delegating the specific UI rendering to the next step, the platform adapter.
[0070] Furthermore, in one embodiment, mapping the abstract Web component model to the target platform includes: If the target platform has a native DOM environment, the target platform adapter directly calls the target platform's native DOM API to implement the mapping of the abstract Web component model to the target platform.
[0071] In this embodiment, taking the native browser environment as an example, the target platform of the browser platform adapter is a standard browser environment (Chrome, Firefox, Safari, Edge, etc.), whose platform characteristics are based on the DOM API, browser event system, and rendering engine. The key to implementing this platform adapter lies in directly utilizing the browser's native Web API to implement the abstract Web component model mapping. The specific implementation scheme is as follows: using the native DOM API to create elements, add child elements, set attributes, and add event listeners (such as addEventListener), directly adding the component to the container for rendering by the browser, and removing the element through the native DOM API, thus completing the implementation of mapping the abstract Web component model to the browser platform.
[0072] Furthermore, in one embodiment, mapping the abstract Web component model to the target platform further includes: If the target platform does not have a native DOM environment, the target platform adapter uses a virtual DOM library to simulate DOM operations and generate HTML strings. The target platform parses the generated HTML strings to enable the mapping of the abstract Web component model to the target platform.
[0073] In this embodiment, taking a Node.js environment as the target platform as an example, since this platform lacks a native DOM environment, the target platform adapter uses a virtual DOM library to simulate DOM operations and generate HTML strings. The specific implementation scheme is as follows: elements are created, child elements are added, and attributes are set through the virtual DOM; the container object on the server side is a virtual DOM node, or used to generate HTML strings; a dedicated rendering method is added to call the string generation capabilities of the virtual DOM library to complete the HTML transfer process from the server to the client, while also including the destruction operation of the virtual DOM environment, ultimately completing the mapping of the abstract Web component model to the browser platform.
[0074] Secondly, embodiments of this application also provide a system for implementing a cross-platform Web component architecture.
[0075] In one embodiment, a system for implementing a cross-platform Web component architecture includes: the system for implementing a cross-platform Web component architecture includes an abstract Web component model, a runtime environment, and multiple platform adapters, wherein: Each platform adapter calls the registration API provided by the runtime environment to register itself with the runtime environment; each platform adapter contains a complete implementation of the interfaces defined by the abstract Web Components model and a complete implementation of the standard adapter interfaces defined by the runtime environment. Before a web component runs on a target platform, the runtime environment selects and loads the target platform adapter corresponding to the target platform. The target platform adapter calls the API of the target platform to map the abstract Web component model to the target platform, ultimately realizing a reusable Web component.
[0076] Furthermore, in one embodiment, the runtime environment is specifically used for: The runtime environment identifies the target attributes of the target platform; Select and load the target platform adapter that matches the target attributes; The runtime environment provides a standard platform adapter interface, which allows the runtime environment to call the corresponding platform adapter on any platform, regardless of the platform it is on.
[0077] Furthermore, in one embodiment, the abstract Web component model is specifically used for: The abstract Web component model is defined through a metadata structure. The abstract Web component model only defines the structural specifications and does not involve specific implementation logic, thus decoupling the abstract Web component model from any platform.
[0078] Furthermore, in one embodiment, the target platform adapter is specifically used for: If the target platform has a native DOM environment, the target platform adapter directly calls the target platform's native DOM API to implement the mapping of the abstract Web component model to the target platform.
[0079] Furthermore, in one embodiment, the target platform adapter is specifically used for: If the target platform does not have a native DOM environment, the target platform adapter uses a virtual DOM library to simulate DOM operations and generate HTML strings. The target platform parses the generated HTML strings to enable the mapping of the abstract Web component model to the target platform.
[0080] The functions of each module in the system that implements the cross-platform Web component architecture correspond to the steps in the method embodiment that implements the cross-platform Web component architecture. Their functions and implementation processes will not be described in detail here.
[0081] Thirdly, embodiments of this application provide a device for implementing a cross-platform Web component architecture. The device for implementing the cross-platform Web component architecture can be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.
[0082] Reference Figure 3 , Figure 3 This is a schematic diagram of the hardware structure of a device implementing a cross-platform Web component architecture as described in an embodiment of this application. In this embodiment, the device implementing the cross-platform Web component architecture may include a processor, memory, a communication interface, and a communication bus.
[0083] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.
[0084] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used to interconnect devices within a cross-platform Web component architecture device, as well as interfaces used to interconnect the cross-platform Web component architecture device with other devices (such as other computing devices or user devices). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user devices can be displays, keyboards, etc.
[0085] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.
[0086] The processor can be a general-purpose processor, which can call a program for implementing a cross-platform web component architecture stored in memory and execute the method for implementing a cross-platform web component architecture provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the program for implementing a cross-platform web component architecture is called can be referred to in the various embodiments of the method for implementing a cross-platform web component architecture in this application, and will not be repeated here.
[0087] Those skilled in the art will understand that Figure 3The hardware structure shown does not constitute a limitation of this application and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0088] Fourthly, embodiments of this application also provide a computer-readable storage medium.
[0089] This application stores a program for implementing a cross-platform web component architecture on a computer-readable storage medium, wherein when the program for implementing a cross-platform web component architecture is executed by a processor, it implements the steps of the method for implementing a cross-platform web component architecture as described above.
[0090] The method implemented when the cross-platform Web component architecture program is executed can be referred to in the various embodiments of the cross-platform Web component architecture method of this application, and will not be repeated here.
[0091] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.
[0092] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.
[0093] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.
[0094] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.
[0095] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.
[0096] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.
[0097] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.
Claims
1. A method for implementing a cross-platform Web component architecture, characterized in that, The method for implementing a cross-platform Web component architecture includes: In a Web component, each platform adapter calls the registration API provided by the runtime environment to register each platform adapter with the runtime environment; each platform adapter contains a complete implementation of the interfaces defined by the abstract Web component model and a complete implementation of the standard adapter interfaces defined by the runtime environment. Before a web component runs on a target platform, the runtime environment selects and loads the target platform adapter corresponding to the target platform. The target platform adapter calls the target platform's API to map the abstract Web component model to the target platform; The abstract Web component model is defined through a metadata structure. The abstract Web component model only defines the structural specifications and does not involve specific implementation logic, thus decoupling the abstract Web component model from any platform. The runtime environment selects and loads the target platform adapter corresponding to the target platform, including: The runtime environment identifies the target attributes of the target platform; Select and load the target platform adapter that matches the target attributes; The runtime environment provides a standard platform adapter interface, which allows the runtime environment to call the corresponding platform adapter on any platform, regardless of the platform it is on.
2. The method for implementing a cross-platform Web component architecture as described in claim 1, characterized in that, Mapping the abstract Web component model to the target platform includes: If the target platform has a native DOM environment, the target platform adapter directly calls the target platform's native DOM API to implement the mapping of the abstract Web component model to the target platform.
3. The method for implementing a cross-platform Web component architecture as described in claim 1, characterized in that, The process of mapping the abstract Web component model to the target platform includes: If the target platform does not have a native DOM environment, the target platform adapter uses a virtual DOM library to simulate DOM operations and generate HTML strings. The target platform parses the generated HTML strings to enable the mapping of the abstract Web component model to the target platform.
4. A system for implementing a cross-platform Web component architecture, characterized in that, The system implementing the cross-platform Web component architecture includes an abstract Web component model, a runtime environment, and multiple platform adapters, wherein: Each platform adapter calls the registration API provided by the runtime environment to register itself with the runtime environment; each platform adapter contains a complete implementation of the interfaces defined by the abstract Web Components model and a complete implementation of the standard adapter interfaces defined by the runtime environment. Before a web component runs on a target platform, the runtime environment selects and loads the target platform adapter corresponding to the target platform. The target platform adapter calls the target platform's API to map the abstract Web component model to the target platform; The abstract Web component model is defined through a metadata structure. The abstract Web component model only defines the structural specifications and does not involve specific implementation logic, thus decoupling the abstract Web component model from any platform. The runtime environment selects and loads the target platform adapter corresponding to the target platform, including: The runtime environment identifies the target attributes of the target platform; Select and load the target platform adapter that matches the target attributes; The runtime environment provides a standard platform adapter interface, which allows the runtime environment to call the corresponding platform adapter on any platform, regardless of the platform it is on.
5. A system for implementing a cross-platform Web component architecture as described in claim 4, characterized in that, The target platform adapter is specifically used for: If the target platform has a native DOM environment, then the target platform's native DOM API is called to enable the mapping of the abstract Web component model to the target platform.
6. A system for implementing a cross-platform Web component architecture as described in claim 4, characterized in that, The target platform adapter is specifically used for: If the target platform does not have a native DOM environment, a virtual DOM library is used to simulate DOM operations and generate HTML strings; The target platform is specifically used to parse the generated HTML string in order to enable the mapping of the abstract Web component model to the target platform.
7. A device for implementing a cross-platform Web component architecture, characterized in that, The device for implementing a cross-platform Web component architecture includes a processor, a memory, and a program for implementing a cross-platform Web component architecture stored in the memory and executable by the processor, wherein when the program for implementing a cross-platform Web component architecture is executed by the processor, it implements the steps of the method for implementing a cross-platform Web component architecture as described in any one of claims 1 to 3.
8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program for implementing a cross-platform Web component architecture, wherein when the program for implementing the cross-platform Web component architecture is executed by a processor, it implements the steps of the method for implementing a cross-platform Web component architecture as described in any one of claims 1 to 3.