Preview method and device for low-code components

Abstract

This specification provides a method and apparatus for previewing low-code components. The preview method includes: reading configuration data of a target component input by a user from a configuration panel, wherein the configuration data includes data and content data used to indicate a specific scenario; reading initial simulation data corresponding to the specific scenario from a preset storage area, wherein the initial simulation data includes variables corresponding to the aforementioned content data; assigning values ​​to the variables based on the content data to generate final state data for the specific scenario; injecting the final state data into a state management module; rendering the user interface based on the final state data for the specific scenario through the state management module; and displaying the user interface to the user.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of computer technology, and more particularly to a method and apparatus for previewing low-code components. Background Technology

[0002] In low-code development platforms, previewing the user interface of components across multiple scenarios is a crucial step in improving page building efficiency and verification accuracy. Taking an operational activity page as an example, components often need to present multiple business states, such as the "won," "not won," or "network error" pop-up styles of a lottery component, or the expanded style of a specific item in a FAQ component, or a frame of a carousel component. Traditional preview methods typically rely on scanning QR codes on real devices, manually triggering interactions, or simulating user behavior to verify the user interface performance under different states. This approach suffers from problems such as lengthy verification paths, low efficiency, and inability to cover complex interaction chains. Summary of the Invention

[0003] This specification describes one or more embodiments of a low-code component preview method and apparatus, which can significantly improve preview efficiency and reduce verification costs.

[0004] Firstly, a method for previewing low-code components is provided, including:

[0005] The configuration data of the target component input by the user is read from the configuration panel; wherein, the configuration data includes data for indicating the first scene and first content data;

[0006] Read initial simulation data corresponding to the first scenario from a preset storage area, wherein the initial simulation data includes a first variable corresponding to the first content data;

[0007] The first variable is assigned a value based on the first content data to generate the first state data of the first scenario;

[0008] Inject the first state data into the state management module;

[0009] The state management module renders the first user interface based on the first state data of the first scenario.

[0010] The first user interface is displayed to the user.

[0011] Secondly, a preview device for low-code components is provided, including:

[0012] A reading unit is used to read configuration data of a target component input by the user from a configuration panel; wherein the configuration data includes data for indicating a first scene and first content data;

[0013] The reading unit is further configured to read initial simulation data corresponding to the first scenario from a preset storage area, the initial simulation data including a first variable corresponding to the first content data;

[0014] The generation unit is used to assign values ​​to the first variable based on the first content data to generate the first state data of the first scenario;

[0015] An injection unit is used to inject the first state data into the state management module;

[0016] The rendering unit is used to render the first user interface based on the first state data of the first scene through the state management module;

[0017] The display unit is used to display the first user interface to the user.

[0018] A third aspect of this specification provides a computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method described in the first aspect.

[0019] A fourth aspect of this specification provides a computing device including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the method described in the first aspect.

[0020] This specification provides a computer program product in a fifth aspect, including a computer program / instructions that, when executed by a processor, implement the steps of the method described in the first aspect.

[0021] The low-code component preview method and apparatus provided in one or more embodiments of this specification read user configuration and combine it with initial simulation data of a preset scenario. By assigning values ​​to variables to generate specific states and injecting them into a state management module to drive UI rendering, this enables real-time previewing of low-code components without the need for actual interaction or real-device debugging. This solution, by dynamically constructing state data for different business scenarios, not only simplifies the preview process and improves development efficiency but also effectively solves the pain point of traditional methods' difficulty in exhaustively enumerating complex interaction chains, thereby ensuring the comprehensiveness and accuracy of polymorphic UI verification. Attached Figure Description

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

[0023] Figure 1This is a schematic diagram illustrating an implementation scenario of one embodiment disclosed in this specification;

[0024] Figure 2 A preview method flowchart of a low-code component according to an embodiment of this specification is shown;

[0025] Figure 3 This diagram illustrates a method for configuring and previewing configurations and switching them to take effect in one example of this specification.

[0026] Figure 4 A schematic diagram illustrating a method for configuring and previewing configurations and switching them into effect, as shown in another example of this specification;

[0027] Figure 5 A schematic diagram of a preview device for a low-code component according to one embodiment of this specification is shown. Detailed Implementation

[0028] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0029] In low-code platforms, developers face three major pain points when verifying the UI effects of components in different scenarios (such as winning / not winning, activity in progress / ended): First, they don't know how to configure them and lack an intuitive understanding of the mapping relationship between configuration items and the final UI; second, they don't know what they are configuring and cannot immediately perceive the specific UI elements affected by the current modification during the configuration process; and third, they cannot intuitively perceive the presentation of multiple states and must go through a cumbersome path of "saving configuration -> scanning QR code on real device -> manually triggering interaction" to see the effects of different scenarios, resulting in low verification efficiency.

[0030] To address the above issues, the following solutions are currently being adopted:

[0031] First, the code platform uses an event-driven view script injection approach, which recreates the scene trigger path by simulating user operations and using mocked interface data (such as Bakery). Taking the lottery component as an example, developers need to mock the lottery interface data and trigger the button click event through the script to preview the style of the "Winning" pop-up. However, this approach has significant drawbacks: First, complex scenarios often require combining multiple operations and multiple mocked interfaces, resulting in a cumbersome chain and high maintenance costs; second, user operation paths are diverse (e.g., scrolling to a specific position), making comprehensive coverage difficult; third, the script code and component assets are independent, requiring manual synchronization during updates, which can easily lead to inconsistencies between the script and component implementations; fourth, a large amount of DOM manipulation logic needs to be maintained on the editor side, resulting in high coupling with the component implementation; fifth, it is difficult to support non-click-triggered scenarios (such as state changes triggered by event emit), resulting in significant overall limitations.

[0032] Second, a MockScene component wrapping scheme is adopted, that is, conditional branching logic is written inside the component (such as checking the editor environment env.isEditor), and different sub-components are rendered for different scenarios (such as...). <luckscene> 、 <unluckscene>This method, while enabling polymorphic preview within the editor, suffers from several drawbacks: First, it significantly intrudes on the C-end code, still including the MockScene branch code in production environment packaging, increasing runtime size; second, it requires writing independent components for each scene, copying a large amount of business logic, resulting in high development costs; third, scene logic is scattered across multiple files, disconnected from the main component implementation, making maintenance difficult; and fourth, it requires self-maintenance of the global state, lacking a unified standard, leading to complex state management.

[0033] Third, the component snapshot preview method based on Storybook, while capable of displaying the rendering results of components under different attributes through Story registration, has the following drawbacks: First, props in the Story need to be manually written, which is disconnected from the schema configuration of the actual low-code editor and cannot reflect configuration changes in the real building environment; Second, the configuration panel is separated from the preview area, and operators cannot directly manipulate the configuration in the editor and see the effect in real time, which does not meet the core requirement of "what you configure is what you see"; Third, it can only display the initial props and cannot simulate the internal state changes after user interaction (such as pop-up display, FAQ item expansion, and other runtime states); Fourth, it requires additional maintenance of Story files, which is disconnected from the main component development process and results in high engineering costs.

[0034] Fourth, the state injection method based on React DevTools or custom Hooks, which exposes the internal state of components in development mode and is forcibly set by external tools, has the following drawbacks: First, it relies on the internal state structure of components, and will fail once the component is refactored, making it uncontrollable and unstable; second, each component needs to customize its state exposure logic, lacking a unified access standard and making it impossible to standardize and promote; third, this method is geared towards developer debugging scenarios, requiring users to have debugging tool operation capabilities, and is not suitable for production-grade low-code platforms for operations / non-developers.

[0035] Fifth, the end-to-end recording and playback solution records the user's complete operation path (clicks, scrolling, network requests, etc.) on a real device and replays it in the editor to reproduce the scenario. However, this solution has the following drawbacks: First, the recorded files are large in size, with significant data redundancy, making them difficult to manage and store; second, it relies on specific device, network, time, and other runtime contexts, resulting in a low success rate for reproduction; third, it can only "review" the recorded operation path and cannot "preset" or "actively switch" scenarios for configuration verification, making it difficult to use for configuration guidance.

[0036] In summary, the above solutions share the following common technical bottlenecks:

[0037] 1. Lack of state isolation capability: Traditional Mock solutions simulate state through script injection or global variables, without establishing an independent namespace at the component instance level. This leads to mutual state contamination in multi-instance scenarios (such as multiple lottery components on the same page), making it impossible to guarantee state consistency.

[0038] 2. Incomplete data flow loop: The script injection method couples the simulation logic with DOM operations. There is no unified data channel between the editor and the component. State changes cannot form a controllable closed loop of "configuration -> injection -> rendering", which can easily lead to the problem of view and state being out of sync.

[0039] 3. Lack of declarative scene mapping: Existing solutions require manual writing of conditional branches or event triggering logic to switch scenes, without establishing an explicit mapping relationship between configuration items and business scenes, resulting in high scene expansion costs and difficult maintenance.

[0040] To address this, this solution proposes reading user configurations and combining them with initial simulation data from preset scenarios. It then uses variable assignment to generate specific states and injects these states into a state management module to drive UI rendering, enabling real-time previewing of low-code components without requiring actual interaction or real-device debugging. By dynamically constructing state data for different business scenarios, this solution not only simplifies the preview process and improves development efficiency but also effectively solves the pain point of traditional methods struggling to exhaustively enumerate complex interaction chains, thus ensuring the comprehensiveness and accuracy of polymorphic UI verification.

[0041] Figure 1 This is a schematic diagram illustrating an implementation scenario of one of the embodiments disclosed in this specification. Figure 1 In this system, users can configure and preview components through a low-code platform. This low-code platform includes a configuration panel, a preset storage area, and a state management module. Additionally, it may include a state injection engine, interceptors, and a component preview area.

[0042] Specifically, configuration data related to a specific scenario for the target component can be read from the configuration panel first. Additionally, initial simulation data corresponding to that specific scenario can be read from the preset storage area. Next, the configuration data and initial simulation data can be merged using the state injection engine, and the merged final state data can be injected into the state management module. This state management module then renders and displays the user interface of the target component in the specific scenario within the component preview area.

[0043] Of course, in practice, an interceptor can also be used to intercept update requests for the user interface, and based on the above configuration data and the initial simulation data of the new scene, update state data can be calculated, and the updated interface of the target component in the new scene can be rendered and displayed through the state management module.

[0044] Figure 2 A preview method flowchart of a low-code component according to one embodiment of this specification is shown. It will be understood that this method can be executed by any device, apparatus, platform, or cluster of devices with computing and processing capabilities. Figure 2 As shown, the method includes the following steps:

[0045] Step S202: Read the configuration data of the target component input by the user from the configuration panel.

[0046] The target component here refers to the "blueprint" or "template" definition of a certain type of UI unit or functional module, describing the general structure, style, configurable properties, and default behavior of that type of component. Common target components can include basic form components (such as input boxes, dropdown selectors, date pickers), display components (such as cards, lists, image carousels), feedback components (such as pop-ups, prompts, loading statuses), and layout container components, etc.

[0047] It should be noted that the target component mentioned above typically does not contain specific data; it is equivalent to the concept of a "class." A corresponding instance, called a component instance, can be created for this target component.

[0048] Taking a "lottery pop-up component" (LotteryDialog) as an example, the corresponding component instance can be as follows:

[0049] Table 1

[0050]

[0051] In one example, the configuration data of the target component is driven by the schema definition and mainly includes data (hereinafter referred to as scenario data) used to indicate several business scenarios and their corresponding content data.

[0052] Taking a pop-up window as the target component as an example, the corresponding configuration data can be as follows:

[0053] - winDialogConfig (Prize Winning Pop-up Configuration): Object {

[0054] + winDialogConfig(Winning Pop-up Configuration): Object [group: "Winning"] {

[0055] title (main title text): String

[0056] }

[0057] - failDialogConfig (Configuration for the "Not Winning" pop-up): Object {

[0058] + failDialogConfig(Configuration for "Not Winning" pop-up): Object [group: "Not Winning"] {

[0059] title (main title text): String

[0060] }

[0061] In the example above, the configuration data covers two scenarios: "winning" and "not winning". Specifically, winDialogConfig is marked as [group: "winning"] and failDialogConfig is marked as [group: "not winning"], which constitutes two scenarios to distinguish different business contexts. Simultaneously, the configuration data can include specific fields such as title (main title text), which constitute content data used to define the specific text or style attributes displayed by the target component in a specific business scenario. This structure supports fixed grouping of static scenarios and dynamic scenario configuration implemented through Array + sceneAttr, thus flexibly describing the behavior of the target component in different states.

[0062] It should be understood that in practice, the above configuration data may include other data, and this specification does not limit this.

[0063] The core function of this step is to accurately obtain the user-defined target component configuration from the configuration panel, parse out the scene identifier and specific content data, and provide accurate input for subsequent state simulation. By structurally extracting scene groups and content data, this step establishes a mapping relationship between configuration data and business scenarios, ensuring that the preview process can be initialized based on the correct context, thus smoothly transitioning to the next step.

[0064] Step S204: Read the initial simulation data corresponding to the specific scenario from the preset storage area.

[0065] The initial simulation data (also known as a mock snapshot) mentioned above refers to a predefined set of static data used to simulate the backend interface response or application state under a specific scenario. It is usually stored in a structured format (such as JSON) and contains variables corresponding to the scenario content. These variables can be fixed values ​​or dynamic placeholders referencing other configurations.

[0066] Example: For a "winning" pop-up scenario, the initial simulated data could be: winning.json, with the following content:

[0067] json

[0068] {

[0069] "isShowDialog": true,

[0070] Title: Congratulations on winning the prize!

[0071] "prizeList": []

[0072] }

[0073] This example shows that by default, a "Winner" pop-up window will be displayed with the title "Congratulations on winning!" and an empty prize list. Developers can quickly simulate different variations of the winning scenario (such as having a prize list, different titles, etc.) simply by modifying this JSON file.

[0074] In one implementation, the initial simulation data is recorded as a JSON file. The step of reading the initial simulation data corresponding to a specific scenario from the preset storage area further includes: reading a file whose filename matches the scenario name from the preset storage area, based on the scenario name (i.e., the group name) of the specific scenario.

[0075] For example, you can create a JSON file in the mockScene / directory. The filename must strictly match the group: "xxx" defined in the schema. For instance, if the schema defines group: "winning", then the corresponding file must be named winning.json. When the platform reads group: "winning", it will automatically load mockScene / winning.json.

[0076] In another implementation, a dynamic mocking strategy based on API interception can be used. This involves storing a set of mock rules (such as regular expressions matching URLs, request methods, and return status codes) instead of complete JSON files in the pre-defined storage area. When an application initiates a network request, the interceptor dynamically matches the rules based on the request parameters and generates simulated data that conforms to the rule structure in real time.

[0077] This approach is suitable for scenarios that require dynamic changes based on request parameters or simulation of complex interaction logic, offering greater flexibility, but also increasing implementation complexity.

[0078] It should be noted that this step, by reading initial simulation data corresponding to a specific scenario from a pre-defined storage area, provides a standardized data foundation for subsequent business logic processing or UI rendering. This decouples data from logic, storing simulation data independently of the code; modifications to the data do not require recompiling or modifying the business code, greatly improving development and debugging efficiency. Furthermore, it enables rapid scenario switching; through a strict matching mechanism between filenames and group names, developers only need to create or switch JSON files to simulate different business scenarios, eliminating the need to set up a mock server.

[0079] Step S206: Assign values ​​to the variables in the initial simulation data based on the content data of the specific scenario to generate the final state data of the specific scenario.

[0080] In one example, it can be done by Figure 1 The state injection engine assigns values ​​to variables in the initial simulation data.

[0081] In one specific implementation, the variables in the initial simulation data are dynamic placeholders. Specifically, the attribute pointed to by the dynamic placeholder in the initial simulation data can be determined, the current attribute value of the attribute pointed to by the dynamic placeholder can be read from the content data of a specific scenario, and the dynamic placeholder can be replaced with the current attribute value to obtain the final state data.

[0082] For example, assuming a specific scenario is an "error message" scenario, its content data is as follows:

[0083] javascript

[0084] / / failDialogConfig in Schema configuration

[0085] failDialogConfig: {

[0086] errors: [

[0087] { code: "ERR_001", message: "Network connection failed"},

[0088] { code: "ERR_002", message: "Internal server error"} ]

[0090] }

[0091] The error message .json file read from the preset storage area contains the following:

[0092] json

[0093] {

[0094] "isShowDialog": true,

[0095] "errorCode": "{{ failDialogConfig.errors[$index].code}}",

[0096] "errorMessage": "{{ failDialogConfig.errors[$index].message}}"

[0097] }

[0098] First, the initial simulation data is parsed to identify the dynamic placeholders {{ failDialogConfig.errors[$index].code}} and {{ failDialogConfig.errors[$index].message}}.

[0099] Determine the property path that the placeholder points to: failDialogConfig.errors[0].code and failDialogConfig.errors[0].message (assuming the current index $index=0).

[0100] Read the current attribute values ​​"ERR_001" and "Network connection failed" from the content data of a specific scenario.

[0101] Replace the placeholders with the read values ​​to generate the final state data:

[0102] json

[0103] {

[0104] "isShowDialog": true,

[0105] "errorCode": "ERR_001",

[0106] "errorMessage": "Network connection failed"

[0107] }

[0108] This approach enables dynamic linkage between mock snapshots and real configurations. During preview, the platform parses the {{ ...}} placeholders in real time, extracting corresponding values ​​from the current schema configuration and filling them in, ensuring the authenticity of the preview. Developers do not need to write complex mock servers or hardcode fake data; they can achieve dynamic data simulation for different scenarios simply by maintaining JSON files. This is the key to "low-cost integration."

[0109] In another implementation, a dynamic assignment strategy based on transformation functions can be used. That is, the variables in the initial simulation data can be not only static values ​​or placeholders, but also function expressions or script fragments. During execution, these expressions are executed through a sandbox environment, with the content data of a specific scenario passed in as context, and the final values ​​are dynamically calculated and generated.

[0110] This approach is suitable for scenarios requiring complex computational logic, data aggregation, or conditional judgments, enabling mock data to have dynamic computational capabilities, rather than simply static replacement. However, attention must be paid to sandbox security to prevent the execution of malicious code.

[0111] This step assigns values ​​to variables in the initial mock data based on scenario-specific content data, deeply integrating static mock snapshots with dynamic configuration data to generate final state data usable for component rendering. Its core functions and benefits include: 1) Dynamic data injection: Dynamically injecting real data from the schema configuration into the mock snapshot ensures consistency between the preview state and the actual runtime state, avoiding debugging deviations caused by data inconsistencies. 2) Reduced integration costs: Only a JSON file containing placeholders needs to be maintained; no additional data conversion code is required to achieve complex data associations and dynamic value retrieval, greatly improving the efficiency of multi-scenario debugging. 3) Flexibility and scalability: By supporting dynamic placeholders and even expression calculations, this step can adapt to various business needs, from simple value replacement to complex logical calculations, meeting mock scenarios of varying complexity.

[0112] At this point, the state management module (also known as the state management repository) has stored the final state data for a specific scenario, preparing for the real-time preview of the component.

[0113] Additionally, this solution also includes steps for validating and formatting the generated final state data using an interceptor, specifically including:

[0114] The interceptor reads the validation rules corresponding to the target component from the preset rule base. These rules include: field type validation (e.g., isShowDialog must be a boolean value), required field validation, and numerical range validation.

[0115] The interceptor performs field-by-field validation on the final state data. If the rules are not met, it corrects the data according to a preset strategy (such as converting non-Boolean values ​​to Boolean values) or rejects the injection and returns an error message. If the rules are met, it converts the data format according to the conversion configuration (such as renaming fields and flattening data) to generate standard state data that meets the requirements of the state management module.

[0116] The interceptor filters the final state data before injecting it into the state management module to prevent the injection of malicious fields or scripts, ensuring the security and consistency of the state injection process.

[0117] Through the aforementioned interceptor mechanism, this solution establishes a controllable verification and conversion barrier between "snapshot generation" and "state injection," ensuring the robustness of the entire data flow loop.

[0118] Step S208: Inject the aforementioned final state data into the state management module.

[0119] The aforementioned state management module, also known as the central data warehouse (shandie-store), is internally implemented based on Zustand, but encapsulated as a single hook, requiring no Provider wrapper and measuring only 7KB in size. Its core design principle is to isolate state by component instance; that is, each component instance has its own independent namespace, preventing interference between the states of different components or different instances of the same component. It is the Single Source of Truth, ensuring that all views and logic operate based on a unified state.

[0120] In one specific implementation, the state management module can allocate independent namespaces for different component instances, thereby injecting the final state data into the namespace corresponding to the instance of the target component.

[0121] The aforementioned namespace can be constructed by concatenating ComponentID (component type identifier) ​​and InstanceID (instance identifier), in the format ${componentId}_${instanceId}. ComponentID is generated based on the unique key used when the component is registered on the low-code platform (e.g., 'LotteryDialog'), and all instances of the same component type share the same ComponentID. InstanceID is an auto-incrementing numeric ID or UUID assigned by the platform when the component is instantiated, ensuring that multiple instances of the same component type on the same page have different InstanceIDs.

[0122] For example, when the same page contains two lottery component instances, their namespaces are LotteryDialog_001 and LotteryDialog_002, respectively. The state data of each instance (such as the status of the winning pop-up and the prize list) are completely isolated and do not interfere with each other.

[0123] In addition, the state management module provides the getStateByNamespace(namespace, path) and setStateByNamespace(namespace, path, value) interfaces, allowing interceptors or rendering engines to manipulate the state precisely by namespace.

[0124] Through the above mechanism, this solution achieves state isolation at the component instance level, fundamentally solving the state pollution problem in multi-instance scenarios.

[0125] More specifically, the target component instance (such as a Dialog popup component) that needs to receive state can be determined first based on the scenario configuration or the current context. Then, the state management module automatically assigns or identifies the corresponding namespace for each component instance (usually based on component type or instance ID). Finally, the final state data is merged into the state tree under that namespace, triggering updates for all views subscribed to that namespace.

[0126] When using a central data warehouse, there is no need to manually manage namespaces or provider configurations; it can be automatically integrated simply through the useStore Hook.

[0127] javascript

[0128] import { useStore} from '@alipay / shandie-store';

[0129] const DialogComponent = (props) => {

[0130] / / useStore automatically isolates state by component instance, with each instance having its own independent namespace.

[0131] const { state, setState} = useStore();

[0132] const { isShowDialog, title, prizeList} = state;

[0133] return (

[0134] <dialog visible="{isShowDialog}" title="{title}">

[0135] {prizeList.map(prize => {prize.name} )}

[0136] < / dialog> );

[0138] };

[0139] In summary, this solution will achieve automatic isolation, that is, useStore() will automatically allocate namespaces based on the component instance that calls it, and the states of different instances of the same component type will not interfere with each other.

[0140] In addition, traditional state management solutions (such as Redux) require a top-level Provider wrapper, while shandie-store achieves out-of-the-box functionality by encapsulating zustand, reducing integration costs.

[0141] Finally, once the state is updated via setState (or injected directly in this step), all components using the state of that namespace will immediately re-render.

[0142] Step S210: Render the user interface based on the final state data of a specific scenario through the state management module.

[0143] Step S212: Display the above user interface to the user.

[0144] This step utilizes the final state data already injected into the central data warehouse (shandie-store) to drive the target component to complete the actual rendering of the user interface. Specifically, in the component preview area, real-time rendering can be performed based on the state in the central data warehouse, presenting a "what you see is what you get" visual effect.

[0145] Suppose the final state data for a specific scenario is as follows:

[0146] json

[0147] {

[0148] "isShowDialog": true,

[0149] Title: Congratulations on winning the prize!

[0150] "prizeList": [

[0151] { "id": 1, "name": "iPhone 15"},

[0152] { "id": 2, "name": "Coupon worth 100 yuan"} ]

[0154] }

[0155] After steps S210-S212 are executed, the prize-winning pop-up window on the right side of the component preview area will immediately appear with the title "Congratulations on winning!" and display the prize list. Users can see the complete UI effect of the "winning scenario" in real time without refreshing the page or performing any additional operations. If isShowDialog in the JSON file is changed to false, the pop-up window in the component preview area will automatically close, achieving true "what you see is what you get".

[0156] This step, serving as the endpoint of the entire data processing chain (from data preparation to final presentation), transforms the final state data into a user-visible and interactive graphical interface through the state management module. Its core functions and beneficial effects include: 1) After a user modifies the Mock data (JSON file), the component preview area immediately displays the corresponding effect without manual refresh or recompilation, greatly improving the efficiency of UI debugging and scene verification. 2) Based on the responsive mechanism of the central data warehouse, state changes automatically drive UI display, eliminating the need for developers to write additional interface refresh code and reducing development complexity. 3) By loading Mock snapshots matching the group name, the component preview area can highly reproduce the UI performance under different scenarios (such as winning state, error state, empty data state, etc.), helping users to discover and fix interface problems in advance. 4) The entire rendering process relies entirely on the single real data source in the central data warehouse, avoiding the common problem of data and view being out of sync and ensuring the reliability of the preview.

[0157] After the user interface is displayed to the user, when the user triggers a scene change (such as clicking a button or switching tabs), the state-driven re-rendering mechanism will be triggered immediately to automatically update the view, ultimately achieving real-time UI synchronization, ensuring that the interface display remains strictly consistent with the latest state, and forming an efficient closed-loop feedback.

[0158] Specifically, in response to a user's scene switching operation triggered by the aforementioned user interface, a new scene is determined. Initial simulation data corresponding to the new scene is read from a preset storage area, including new variables corresponding to the content data of the new scene. Values ​​are assigned to the new variables based on the content data of the new scene to generate the final state data of the new scene. The final state data of the new scene is injected into the state management module, and the new user interface is rendered and displayed through the state management module.

[0159] Suppose a user is previewing a pop-up effect of a "Winning Scene" in a low-code platform. The user then clicks the "Not Winning" tab in the component preview area. The platform captures this interaction event and determines the new scene name to be "Not Winning". This scene name must strictly match the predefined group: "Not Winning" in the schema. The platform reads the initial simulation data corresponding to the new scene from the preset storage area (mockScene / directory): not winning.json. Example file content:

[0160] json

[0161] {

[0162] "isShowDialog": true,

[0163] Title: "Unfortunately, you did not win the prize".

[0164] "prizeList": [],

[0165] "tipsMessage": "{{ failDialogConfig.errors[$index].message}}"

[0166] }

[0167] The `{{ failDialogConfig.errors[$index].message}}` is a dynamic placeholder (a new variable) that needs to reference a value from the schema configuration.

[0168] Next, the platform parses the initial simulation data and identifies the dynamic placeholder `{{ failDialogConfig.errors[$index].message}}`. It then reads the corresponding attribute value (such as "Thank you for participating, see you next time") from the current schema configuration to replace the dynamic placeholder, generating the final state data for the new scenario.

[0169] json

[0170] {

[0171] "isShowDialog": true,

[0172] Title: "Unfortunately, you did not win the prize".

[0173] "prizeList": [],

[0174] "tipsMessage": "Thank you for participating, see you next time!"

[0175] }

[0176] After obtaining the final state data of the new scenario, the interceptor specifically captures the final state data, verifies, transforms or enhances the final state data, and then safely writes it back to the central data warehouse, thereby ensuring the controllability and consistency of state changes.

[0177] In this example, the interceptor can verify whether isShowDialog is a boolean value, whether prizeList is an array, etc., to ensure the data is valid before writing it into the central data warehouse.

[0178] Ultimately, any changes to the central data warehouse are automatically broadcast to the component preview area, driving the component to re-render. This means the pop-up message in the component preview area changes from "Congratulations on winning!" to "Unfortunately, you didn't win," the prize list is cleared, and the message is updated to "Thank you for participating, try again next time." This forms a real-time feedback loop of "user interaction -> status update -> UI synchronization."

[0179] It should be noted that the entire process of this solution is not unidirectional and linear. Instead, it uses a "feedback loop and iteration" mechanism at the bottom to feed the preview results back to the development configuration stage. For example, if developers find the prompt text for the "not won" scenario unfriendly, they can immediately modify the "not won.json file" or adjust the schema configuration. The component preview area will then automatically update again, thus forming an efficient and agile development iteration loop.

[0180] The following explanation uses the example of an array-type component as the target component to illustrate other UI update scenarios.

[0181] It should be noted that for array-type components, the configuration data usually also includes the path identifier of the array-type component.

[0182] Specifically, in response to a user's trigger action on any array element in an array-type component, the index value of that array element is determined. Based on the path identifier of the array-type component, the corresponding state variable naming convention is read from the rule base, and the corresponding state variable is determined from the state management module based on it. The index value is written to the state variable to drive the target user interface displaying the array element corresponding to that index value as active.

[0183] This step specifically addresses the interaction scenarios of array-type components (such as FAQ collapsible panels, banner carousels, list items, etc.). The core requirement for these components is that when a user clicks on an array element, that element needs to be "activated" (e.g., highlighted, expanded, selected), while other elements return to their default state.

[0184] In this solution, users only need to name the state variable ${schemaPath}.activeIndex according to the agreed specifications, and the platform will automatically inject the index of the item clicked by the user into this path, without the need to manually write index management logic.

[0185] Taking the FAQ list component as an example, suppose a developer is configuring an array-like component containing multiple question and answer items, and defines its path identifier as `questionList` in the configuration data. First, according to the naming conventions for state variables read from the rule base, the platform requires the developer to name the state variable `${schemaPath}.activeIndex`, which in this example is `questionList.activeIndex`. Subsequently, the state management module (shandie-store) maintains this state variable, for example, by default setting `questionList.activeIndex` to 0, indicating that the first FAQ item is active.

[0186] javascript

[0187] / / Example of state in the store

[0188] {

[0189] questionList: [

[0190] { Question: "How do I register an account?", Answer: "Click the register button in the upper right corner..."},

[0191] { Question: "What should I do if I forget my password?", Answer: "Click to retrieve password..."},

[0192] { Question: "How do I contact customer service?", Answer: "Dial 400-xxx..."}

[0193] ],

[0194] "questionList.activeIndex": 0 / / The first FAQ is active by default.

[0195] }

[0196] When a user clicks the second FAQ item (index value 1) in the component preview area, the platform captures the click event and determines the index value as index = 1. Then, based on the path identifier `questionList`, it retrieves the state variable name `questionList.activeIndex` from the rule base and locates this variable in the state management module. Next, the platform writes the index value to the state variable using `setState`.

[0197] javascript

[0198] / / Update store

[0199] setState({ "questionList.activeIndex": 1});

[0200] During this process, the platform automatically injects the index of the item clicked by the user into the path, without requiring the user to write any event handling code. The component subscribes to the `questionList.activeIndex` state and automatically compares the current index with its own index. If they are equal, the component displays an active style (such as expanding the answer and highlighting the background); otherwise, it displays a default style (such as collapsing the answer and displaying a normal background). Finally, the user interface in the component preview area updates automatically: the first FAQ item switches from active to collapsed, and the second FAQ item becomes active and displays the answer content with a highlighted background.

[0201] Similarly, for the Banner carousel component, the path identifier is bannerList, and the state variable is named bannerList.activeIndex. When the user clicks the indicator dot or the left / right toggle button, the platform will automatically inject the corresponding index into this variable, driving the carousel to switch to the specified image.

[0202] In summary, the core innovations of this solution include: First, a declarative scene grouping mechanism that automatically binds configuration items to scenes by adding [group: "scene name"] metadata to the schema; second, a state snapshot-driven multi-scene preview architecture that abstracts UI scenes as JSON snapshots of component states and achieves "what you configure is what you see" through lightweight Store injection; third, a standardized array state naming convention ${schemaPath}.activeIndex to solve the scene preview problem of multiple arrays and nested arrays; fourth, a dynamic placeholder template engine that supports the {{ path.to.value}} syntax to dynamically integrate configuration data and states; and fifth, a progressively enhanced zero-intrusion architecture where mockScene is treated as an independent asset and automatically excluded from production builds, ensuring zero redundancy in C-end code.

[0203] Based on the above innovations, this solution can improve operational configuration efficiency by more than 70% (without requiring real device QR code verification), reduce component access costs to no more than 3 file modifications, and support combined previews of complex nested scenarios (such as "Shanghai user + winning status").

[0204] Figure 3 This diagram illustrates a method for configuring, previewing, and switching to take effect in one example from this specification. Figure 3 In this approach, the method begins by reading the configuration data of the target component, input by the user, from the configuration panel. The configuration data is driven by a schema definition and primarily contains scenario data indicating several business scenarios and their corresponding content data. Developers clearly distinguish business scenarios by marking different configuration objects as different groups in the schema (e.g., group: "Winning", group: "Not Winning"). Subsequently, state management is integrated: users only need to bind the component to the state management module (shandie-store) via a useStore Hook, without manually managing namespaces or Provider configurations. Simultaneously, users must pre-create JSON-formatted mock snapshots (e.g., winning.json, not winning.json) in the mockScene / directory that strictly match the group names to simulate data under different scenarios. At runtime, the platform is responsible for parsing the schema configuration and automatically loading the corresponding mock snapshots based on the group names, driving Store initialization, thereby completing the first round of component rendering and presenting the initial interface.

[0205] Once the interaction phase begins, when a user triggers a scene switch in the preview area (e.g., clicking a button or switching tabs), the system determines the new scene name, reads the initial simulation data corresponding to the new scene from the preset storage area, and assigns values ​​to variables based on the content data of the new scene to generate the final state data. These update requests do not directly modify the store; instead, they first pass through an interceptor to verify, transform, or enhance the final state data of the new scene before safely writing it back to the shandie-store via setState. This change immediately triggers the state-driven re-rendering mechanism. Any changes to the store are automatically broadcast to the component preview area, driving the component to re-render, ultimately achieving real-time UI synchronization. This ensures that the interface display remains strictly consistent with the latest state, forming a real-time feedback loop of "user interaction -> state update -> UI synchronization".

[0206] Figure 4 This diagram illustrates a method for configuring and previewing, and switching to take effect, as shown in another example of this specification. Figure 4 In this method, the main steps are as follows:

[0207] Phase 1: Development Configuration

[0208] First, define the configuration data of the target component in the configuration panel using Schema, marking different business scenarios as independent groups (e.g., group: "Winning", group: "Not Winning"), and configuring the corresponding content data (e.g., title text). Then, bind the component to the state management module (shandie-store) using a useStore Hook, eliminating the need for manual namespace or Provider configuration management. Finally, create JSON-formatted mock snapshots (e.g., winning.json, not winning.json) in the mockScene / directory that strictly match the group names, providing basic data support for different scenarios. Mock data supports static values ​​as well as dynamic placeholders {{ ...}}, and can reference real data from the Schema configuration.

[0209] Phase Two: Editor Initialization;

[0210] First, the schema configuration is parsed to identify the defined grouping of scenarios, and the corresponding mock snapshots are automatically loaded from the mockScene / directory based on the scenario name. Next, dynamic placeholders in the initial mock data are parsed and replaced: the attribute path pointed to by the placeholder is determined, the current attribute value is read from the schema content data, and this value is used to replace the placeholder, generating the final state data for the specific scenario. The generated final state data is injected into the state management module (shandie-store), which allocates independent namespaces for each component instance to achieve state isolation. Finally, the stored state is injected into the component, driving the first round of component rendering, presenting the initial user interface, and preparing for real-time preview.

[0211] Phase 3: User Interaction & Update;

[0212] Once in live preview mode, when a user triggers a scene switch in the component preview area (such as clicking a tab, switching tabs, or clicking an element in an array-type component), the new scene name is first determined, the corresponding mock snapshot is read from the mockScene / directory, and dynamic placeholders are assigned values ​​based on the content data of the new scene to generate the final state data of the new scene. These update requests do not directly modify the store, but first pass through an interceptor—this interceptor specifically captures the updated data, validates, transforms, or enhances it (such as validating boolean values, array types, etc.), and then safely writes it back to shandie-store via setState. Any changes to the store are automatically broadcast to the component preview area, driving the component to re-render and achieving real-time UI differentiation.

[0213] Specifically, for array-type components (such as FAQ collapsible panels and banner carousels), users only need to name the state variables according to the ${schemaPath}.activeIndex specification. The platform will automatically inject the index of the item clicked by the user into this path, eliminating the need to manually write event handling code. The component automatically compares the index and displays the active / default style by subscribing to this state. Ultimately, this ensures that the interface seen by the user is completely consistent with the actual running effect.

[0214] Corresponding to the above-described method for previewing low-code components, one embodiment of this specification also provides a device for previewing low-code components, such as... Figure 5 As shown, the device may include:

[0215] The reading unit 502 is used to read configuration data of the target component input by the user from the configuration panel, wherein the configuration data includes data for indicating the first scene and first content data;

[0216] The reading unit 502 is also used to read initial simulation data corresponding to the first scene from a preset storage area, the initial simulation data including a first variable corresponding to the first content data;

[0217] The generation unit 504 is used to assign values ​​to the first variable based on the first content data to generate the first state data of the first scene;

[0218] The injection unit 506 is used to inject the first state data into the state management module;

[0219] The rendering unit 508 is used to render the first user interface based on the first state data of the first scene through the state management module;

[0220] Display unit 510 is used to display the first user interface to the user.

[0221] In one embodiment, the above configuration data is based on the component configuration protocol schema definition, and the first scenario is identified by the group field in the schema.

[0222] In one embodiment, the initial simulation data is recorded as a JSON file.

[0223] In one embodiment, the reading unit 502 is specifically used for:

[0224] Based on the scene name of the first scene, read the file whose file name matches the scene name from the preset storage area.

[0225] In one embodiment, the first variable is a dynamic placeholder, and the generation unit 504 includes:

[0226] Determine submodule 5042, which is used to determine the attribute pointed to by the dynamic placeholder in the initial simulation data;

[0227] The read submodule 5044 is used to read the current attribute value of the attribute pointed to by the dynamic placeholder from the first content data;

[0228] Replace submodule 5046, which is used to replace the dynamic placeholder with the current attribute value to obtain the first state data.

[0229] In one embodiment, the configuration data further includes data for indicating a second scene and second content data, and the device further includes:

[0230] The switching unit 512 is used to determine the second scene in response to a scene switching operation triggered by the user based on the first user interface;

[0231] The reading unit 502 is also used to read initial simulation data corresponding to the second scene from a preset storage area, including a second variable corresponding to the second content data;

[0232] Assignment unit 514 is used to assign a value to the second variable based on the second content data to generate the second state data of the second scene;

[0233] The injection unit 506 is also used to inject the second state data into the state management module, and render and display the second user interface through the state management module.

[0234] In one embodiment, the target component is an array-type component, and the configuration data further includes a path identifier for the array-type component. The device also includes:

[0235] The determining unit 516 is used to determine the index value of the array element in response to a user's trigger operation on any array element in the array component.

[0236] The reading unit 502 is also used to read the naming convention of the state variable corresponding to the array-type component from the rule base according to the path identifier, and determine the corresponding state variable from the state management module based on it;

[0237] The writing unit 518 is used to write the index value to the state variable to drive the target user interface that displays the array element corresponding to the index value as active.

[0238] In one embodiment, the state management module assigns independent namespaces to different component instances;

[0239] Injection unit 506 is specifically used for:

[0240] Inject the first state data into the namespace corresponding to the instance of the target component;

[0241] Rendering unit 508 is specifically used for:

[0242] Read the first state data from the namespace corresponding to the instance of the target component, and render the first user interface based on it.

[0243] The functions of each functional module of the apparatus in the above embodiments of this specification can be implemented through the steps of the above method embodiments. Therefore, the specific working process of the apparatus provided in one embodiment of this specification will not be repeated here.

[0244] The low-code component preview device provided in one embodiment of this specification can significantly improve preview efficiency and reduce verification costs.

[0245] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform a combination Figure 2 The method described.

[0246] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements a combination... Figure 2 The method described.

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

[0248] The steps of the methods or algorithms described in conjunction with the disclosure in this specification can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, external hard disk, CD-ROM, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a server. Of course, the processor and storage medium can also exist as discrete components in the server.

[0249] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0250] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26k20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0251] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or physical entities, or by products with certain functions. A typical implementation device is a server system. Of course, this application does not exclude the possibility that, with the future development of computer technology, the computer implementing the functions of the above embodiments can be, for example, a personal computer, a laptop computer, an in-vehicle human-machine interaction device, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0252] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps listed in the embodiments is merely one possible order of execution among many steps and does not represent the only possible order. In actual device or end product execution, the methods shown in the embodiments or drawings may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even a distributed data processing environment). The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded. For example, the use of terms such as "first," "second," etc., is to denote names and does not indicate any particular order.

[0253] For ease of description, the above devices are described in terms of function, divided into various modules. Of course, when implementing one or more of these specifications, the functions of each module can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

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

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

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

[0257] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0258] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0259] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage, graphene storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

[0261] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0262] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, system embodiments are basically similar to method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments. In the description of this specification, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification and the features of different embodiments or examples.

[0263] The above description is merely an embodiment of one or more embodiments of this specification and is not intended to limit the scope of these embodiments. Various modifications and variations can be made to these embodiments by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims.< / unluckscene> < / luckscene>

Claims

1. A method for previewing a low-code component, comprising: The configuration data of the target component input by the user is read from the configuration panel; wherein, the configuration data includes data for indicating the first scene and first content data; Read initial simulation data corresponding to the first scenario from a preset storage area, wherein the initial simulation data includes a first variable corresponding to the first content data; The first variable is assigned a value based on the first content data to generate the first state data of the first scenario; Inject the first state data into the state management module; The state management module renders the first user interface based on the first state data of the first scenario. The first user interface is displayed to the user.

2. The method according to claim 1, wherein, The configuration data is based on the component configuration protocol schema definition, and the first scenario is identified by the group field in the schema.

3. The method according to claim 1, wherein, The initial simulation data record is a JSON format file.

4. The method according to claim 3, wherein, The step of reading the initial simulation data corresponding to the first scenario from the preset storage area includes: Based on the scene name of the first scene, read the file whose file name matches the scene name from the preset storage area.

5. The method according to claim 1, wherein, The first variable is a dynamic placeholder; the assignment of a value to the first variable based on the first content data includes: Determine the attribute pointed to by the dynamic placeholder in the initial simulation data; Read the current attribute value of the attribute pointed to by the dynamic placeholder from the first content data; The dynamic placeholder is replaced with the current attribute value to obtain the first state data.

6. The method according to claim 1, wherein, The configuration data also includes data for indicating the second scene and second content data; the method further includes: In response to a scene switching operation triggered by the user based on the first user interface, a second scene is determined; Read the initial simulation data corresponding to the second scenario from the preset storage area, including the second variable corresponding to the second content data; The second variable is assigned a value based on the second content data to generate the second state data of the second scenario; The second state data is injected into the state management module, and the second user interface is rendered and displayed through the state management module.

7. The method according to claim 1, wherein, The target component is an array-type component; the configuration data also includes the path identifier of the array-type component; the method further includes: In response to a user's trigger operation on any array element in the array component, the index value of that array element is determined; Based on the path identifier, the naming convention for the state variable corresponding to the array-type component is read from the rule base, and the corresponding state variable is determined from the state management module based on it; Write the index value into the state variable to drive the target user interface to display the array element corresponding to the index value as active.

8. The method according to claim 1, wherein, The state management module allocates independent namespaces for different component instances; The step of injecting the first state data into the state management module includes: Inject the first state data into the namespace corresponding to the instance of the target component; The rendering of the first user interface based on the first state data of the first scenario includes: The first state data is read from the namespace corresponding to the instance of the target component, and the first user interface is rendered based on it.

9. A preview device for a low-code component, comprising: A reading unit is used to read configuration data of a target component input by the user from a configuration panel; wherein the configuration data includes data for indicating a first scene and first content data; The reading unit is further configured to read initial simulation data corresponding to the first scenario from a preset storage area, the initial simulation data including a first variable corresponding to the first content data; The generation unit is used to assign values ​​to the first variable based on the first content data to generate the first state data of the first scenario; An injection unit is used to inject the first state data into the state management module; The rendering unit is used to render the first user interface based on the first state data of the first scene through the state management module; The display unit is used to display the first user interface to the user.

10. A computing device comprising a memory and a processor, wherein the memory stores executable code, and the processor, when executing the executable code, implements the method of any one of claims 1-8.

Images