A dynamic state processing method, device and equipment of a service scenario and a medium

Abstract

The application relates to the front-end and e-commerce technical fields and relates to a dynamic state processing method and device for a business scenario, equipment and a medium. The method part comprises the following steps: a state condition mapping table is configured, the state condition mapping table comprises a plurality of rule objects, and a condition judgment function is used to receive a system instance as a parameter; in the running process of the system instance, condition attribute data carried by the system instance in real time is extracted to generate a condition judgment result related to an e-commerce marketing scenario and is cached; the state condition mapping table is traversed to transmit the system instance into the condition judgment function of each rule object; when the condition judgment function of the first rule object returns a condition satisfaction, the traversal is terminated and a corresponding state identifier is returned; if the condition judgment functions of all the rule objects do not satisfy the return condition, a default termination state identifier is returned; and corresponding front-end components, interactive scripts and trigger events are matched from a state component mapping table based on the state identifier, so as to drive the dynamic rendering of the front end.

Description

Technical Field

[0001] This application relates to the field of front-end technology, and in particular to a method, apparatus, device and medium for dynamic state processing in a business scenario. Background Technology

[0002] In marketing campaign scenarios, such as "invite friends to help with a lucky draw" or "cross-platform flash sales" in e-commerce, there are complex interactive scenarios. Traditionally, in front-end solutions, business state judgment and event binding logic are tightly coupled, as are front-end component rendering. Each state requires a dedicated if-else conditional statement to determine the button's current state and trigger the button's bound event. This not only causes the code size to increase linearly with the number of states but also significantly reduces code maintainability. Furthermore, state changes trigger a full rendering, resulting in significant performance overhead. Summary of the Invention

[0003] This application provides a method, apparatus, device, and medium for handling dynamic states in business scenarios, in order to solve the technical problems of low code maintainability and full rendering triggered by changes in business states in traditional solutions.

[0004] A method for handling dynamic states in a business scenario, comprising: A configurable state condition mapping table is pre-configured. The state condition mapping table contains multiple rule objects. Each rule object includes a condition judgment function and a corresponding state identifier. The condition judgment function is used to receive a system instance as a parameter and perform combined judgment on the multi-dimensional conditions in the system instance. The system instance is an instantiated object generated during the operation of the e-commerce marketing activity business system. The system instance is used to carry various condition attribute data under the current e-commerce marketing scenario in real time. During the operation of the system instance, the conditional attribute data carried in real time in the system instance is extracted, and the extracted conditional attribute data is calculated based on the preset calculation rules of the e-commerce marketing scenario to generate conditional judgment results related to the e-commerce marketing scenario, and the conditional judgment results are cached. According to the priority order of the business rules reflected in the state condition mapping table of the rule objects, the state condition mapping table is traversed to pass the system instance to the condition judgment function of each rule object. During the execution of the condition judgment function, the cached condition judgment result is called to complete the combined judgment. The traversal terminates and the corresponding status flag is returned when the condition judgment function of the first rule object returns that the condition is met. If the condition judgment function of all rule objects does not meet the return condition, the default termination status flag is returned. Based on the state identifier, the corresponding front-end component, interactive text, and triggering event are matched from the state component mapping table to drive the dynamic rendering of the front-end. The state component mapping table stores the correspondence between state identifiers and front-end resources.

[0005] Furthermore, the priority of the rule object is determined by its configuration order in the state condition mapping table. During the traversal, the condition judgment function of each rule object is executed in the configuration order, and only the state identifier corresponding to the first rule object that satisfies the condition judgment function is matched and returned.

[0006] Furthermore, the condition judgment function of each rule object contains multi-level sub-conditions arranged in a preset logical order. The multi-level sub-conditions include a basic qualification layer, a scene feature layer, and a resource threshold layer. Each level of sub-condition is sequentially associated with and depends on the judgment result of the previous level. When executing the conditional judgment function, each sub-condition is checked sequentially in hierarchical order: Basic Qualification Layer: Determine whether the conditional attribute data related to the basic participation qualification of the e-commerce marketing activity in the system instance meets the preset basic participation qualification requirements. If it does, then determine that the sub-conditions of the basic qualification layer are met. Scene Feature Layer: Under the premise that the sub-conditions of the basic qualification layer are met, it is determined whether the condition attribute data related to a specific marketing scene meets the preset scene limitation requirements. If they do, it is determined that the sub-conditions of the scene feature layer are met. Resource threshold layer: Under the premise that the scene feature layer is satisfied, it is determined whether the condition attribute data related to the resource value meets the preset resource threshold requirements. If it does, it is determined that the sub-condition of the resource threshold layer is satisfied. If any sub-condition at any level fails to meet the validation, the subsequent level's judgment process is immediately terminated, and the entire condition judgment function returns that the condition is not met; the condition judgment function returns that the condition is met only when all sub-conditions at all levels have been validated.

[0007] Furthermore, after the first conditional judgment function returns that the traversal is terminated and the corresponding status flag is returned, the method further includes: Query the pre-configured state component mapping relationship library to obtain the component identifier and configuration information corresponding to the state identifier. The configuration information includes the component type, interaction logic code and rendering parameters related to the e-commerce marketing scenario. The obtained component identifiers are compared with the currently loaded component set to determine the list of components to be created, components to be updated, and components to be destroyed; Perform the following operations on the components in the front-end page according to the list: instantiate and render unloaded components to be created; adjust the properties of loaded components to be updated; remove and release resources of components to be destroyed that do not need to be displayed; and load the configuration information to ensure that the components in the current front-end page are correctly displayed and respond according to the configuration information.

[0008] Furthermore, after the first conditional judgment function returns that the traversal is terminated and the corresponding status flag is returned, the method further includes: The component identifier associated with the state identifier is marked as the target component, and the remaining components are marked as non-target components; Activate the rendering process for the target component and perform resource release and rendering pause processes for non-target components; In response to an update request for the target component, a virtual node tree of the before and after states is generated, and a difference set is calculated by comparing node attributes. A document object model operation instruction containing only the difference portion is generated. The document object model operation instruction is used to modify the actual document object model elements of the target component in the front-end page.

[0009] Furthermore, the pre-configured configurable state condition mapping table includes: Collect parameters of the current operating environment, including operating system name and version, hardware processor model, screen resolution, and set of interaction event types; Query the adaptation rule base to obtain adaptation rules that match the current environment parameters. The adaptation rules include state condition adjustment rules and component configuration adjustment rules. The adaptation rules are injected into the rule objects of the state condition mapping table, so that the condition judgment function of the rule object can adapt to the condition attribute data format of the system instance of the e-commerce marketing activity business system under different program running platforms.

[0010] Furthermore, the execution of the adaptation rules includes: Based on the parameters of the current operating environment, the format of the conditional attribute data carried in the system instance is converted so that the conditional judgment function can parse the conditional attribute data under different program running platforms; Based on the event types supported by the current platform, convert the triggered events associated with the status identifiers into the event format of the corresponding platform; Based on the performance parameters of the current front-end hardware processor, and in accordance with the calculation frequency control rules, the execution interval of the condition judgment function is set. Based on the current screen resolution of the front-end device, and according to the rendering parameter correction rules, calculate the scaling ratio of the front-end component size, and adjust the layout pixel units and font display precision.

[0011] A dynamic state processing device for a business scenario, comprising: The configuration unit is used to pre-configure a configurable state condition mapping table. The state condition mapping table contains multiple rule objects. Each rule object includes a condition judgment function and a corresponding state identifier. The condition judgment function is used to receive a system instance as a parameter and perform combined judgment on the multi-dimensional conditions in the system instance. The system instance is an instantiated object generated during the operation of the e-commerce marketing activity business system. The system instance is used to carry various condition attribute data under the current e-commerce marketing scenario in real time. The caching unit is used to extract the conditional attribute data carried in real time in the system instance during the operation of the system instance, calculate the extracted conditional attribute data based on the preset calculation rules of the e-commerce marketing scenario, generate conditional judgment results related to the e-commerce marketing scenario, and cache the conditional judgment results. The traversal unit is used to traverse the state condition mapping table according to the priority order of the business rules reflected in the state condition mapping table of the rule objects, so as to pass the system instance to the condition judgment function of each rule object. During the execution of the condition judgment function, the cached condition judgment result is called to complete the combined judgment. When the condition judgment function of the first rule object returns that the condition is met, the traversal is terminated and the corresponding state identifier is returned. If the condition judgment function of all rule objects does not meet the return condition, the default termination state identifier is returned. The processing unit is used to match the corresponding front-end component, interactive text and triggering event from the state component mapping table based on the state identifier, so as to drive the dynamic rendering of the front end.

[0012] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a dynamic state processing method for a business scenario as described in any of the preceding claims.

[0013] A computer-readable storage medium storing a computer program, characterized in that, when executed by a processor, the computer program implements a dynamic state processing method for a business scenario as described in any of the preceding claims.

[0014] As can be seen, this application achieves decoupling of business rules and code logic through a configurable state condition mapping table. Adding / modifying a state only requires adjusting the configuration table, not the core code. Combined with a computed property caching mechanism, redundant calculations are reduced, triggering updates only for affected components and avoiding full-page re-rendering. This significantly reduces redundant rendering in high-frequency state change scenarios, improving page interaction smoothness. Simultaneously, it lowers code maintenance costs and supports rapid iteration of business rules. Compared to traditional state management solutions, this method avoids full-page re-rendering when a single state changes through precise state-component mapping, reducing redundant layout calculations and effectively minimizing redundant rendering operations in high-frequency state change scenarios, thus improving page interaction smoothness. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram of a system framework for a dynamic state processing method for a business scenario according to an embodiment of this application; Figure 2 This is a system interaction diagram of a dynamic state processing method for a business scenario according to an embodiment of this application; Figure 3 This is a flowchart illustrating a dynamic state processing method for a business scenario according to an embodiment of this application. Figure 4 This is a schematic diagram of a dynamic state processing device for a business scenario according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a computer device according to one embodiment of this application. Detailed Implementation

[0017] To make the technical problems, technical solutions, and beneficial effects solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0018] like Figure 1 and Figure 2 To facilitate understanding of the embodiments of this application, the system framework used in the embodiments of this application will be described first from the perspective of module layering and process.

[0019] like Figure 1 and 2The module hierarchy in this application embodiment includes a three-level architecture of "environment → rule → state-driven". This system framework uses "environment adaptation - rule decision - state-driven" as its core logic, and is divided into an environment detection module, a rule decision module, and a state-driven module. Data is passed and interactions are triggered layer by layer to achieve cross-platform dynamic rendering and business rule configuration. Module layering includes: 1. Environment detection module, core function: identify the current running platform (program A / program B / HTML5, etc.), load the corresponding platform's SDK, API or boot strategy, and ensure that the function is available in different program running platform environments.

[0020] ① Environment Awareness Module: As an explanatory note, it determines the platform type (such as program A / program B / PC / mobile) by parsing the UA (extracting browser User-Agent features). ② Policy loader: Distributes different policies based on platform type. For example, as an explanatory note: Program A environment: Loads the API encapsulation of program A and directly invokes the functions of program A; In program B environment: If a redirect is required, the user will be directed to the default onboarding page (e.g., when the user onboarding page is opened, a message will be displayed saying "It is recommended to open program A"). PC / HTML5 environment: Load general HTML5 logic or PC-side adaptation components.

[0021] 2. Rule Decision Module: Core function: Defines the mapping relationship between "business state → component rendering / interaction logic" through a configurable "state condition mapping table", enabling flexible adjustment of rules without hard coding.

[0022] ①Status Condition Mapping: Maintains multiple sets of business rules, each set of rules being associated with a specific status type; ②State dispatcher (determine Status Type): Iterates through the state condition mapping table, uses short-circuit matching (stops when the first rule that meets the condition is found), and outputs the current corresponding state identifier to provide a basis for subsequent component rendering.

[0023] 3. State-driven module, core function: dynamically loads corresponding components based on state identifiers, realizes partial page updates, avoids full rendering, and improves the smoothness of interaction.

[0024] ① Status Component Mapping: Maintains the correspondence between status identifiers and components; ② Dynamically load components: Match and render components based on the status indicators output by the rule decision module; ③ DOM (Document Object Model) partial update: Only the DOM area rendered by the component is updated, reducing redundant rendering.

[0025] Process sequence: Environment recognition → Rule-based decision-making → Dynamic rendering closed loop At runtime, the three-level modules can be linked together in the order of environment → rules → state-driven to form a complete business loop: Environment layer startup: First, the platform is identified through the environment detection module (UA resolution → policy loading) to ensure that the functions are compatible with the current operating environment; Rule-based decision-making: Based on the available environment output by the environment layer, the rule-based decision-making module calls the condition rule table and the status dispatcher to determine the current business status; State layer rendering: The state-driven module loads the corresponding components based on the state identifier corresponding to the business state, completes partial page updates, and responds to user interactions.

[0026] As an example, such as Figure 2 The user interaction, Vue system, rule engine, and UI rendering in the interaction flowchart are deeply integrated with the state-driven module, rule decision module, and environment detection module, representing a process-oriented representation of the system framework. It should be noted that, as an example, the Vue system is the technical carrier of the state-driven + rule engine + dynamic rendering scheme in this application embodiment. Through reactive data and componentization capabilities, it connects user interaction, rule judgment, and UI updates into an automated closed loop. Of course, other technical carriers can also be used, and there is no specific limitation. When changing the technology stack, only the relevant implementation details of this application need to be replaced with the equivalent solution of the corresponding technology stack, and the core rule engine and other processing logic can be completely reused. The rule engine is the core execution unit of the rule decision module in the system framework.

[0027] Based on the overall interaction process analysis of the main system framework and examples mentioned above, the following describes each implementation in detail from the perspective of various embodiments.

[0028] like Figure 3 The present invention provides a dynamic state handling method for a business scenario, including: S10. A configurable state condition mapping table is pre-configured. The state condition mapping table contains multiple rule objects. Each rule object includes a condition judgment function and a corresponding state identifier. The condition judgment function is used to receive a system instance as a parameter and perform combined judgment on the multi-dimensional conditions in the system instance. The system instance is an instantiated object generated during the operation of the e-commerce marketing activity business system. The system instance is used to carry various condition attribute data under the current e-commerce marketing scenario in real time. S20. During the operation of the system instance, extract the conditional attribute data carried in real time in the system instance, calculate the extracted conditional attribute data based on the preset calculation rules of the e-commerce marketing scenario, generate conditional judgment results related to the e-commerce marketing scenario, and cache the conditional judgment results. S30. According to the priority order of the business rules reflected in the state condition mapping table of the rule objects, traverse the state condition mapping table to pass the system instance to the condition judgment function of each rule object. The condition judgment function calls the cached condition judgment result during the execution to complete the combined judgment. When the first condition judgment function returns that the condition is satisfied, the traversal is terminated and the corresponding state identifier is returned. If the conditions of all rule objects are not satisfied, the default termination state identifier is returned. S40. Based on the state identifier, match the corresponding front-end component, interactive text and triggering event from the state component mapping table to drive the dynamic rendering of the front end. The state component mapping table stores the correspondence between state identifiers and front-end resources.

[0029] The core function of this embodiment corresponds to the state-driven module of the system framework, and also relies on the basic configuration of the rule decision module: the STATUS CONDITION MAPPING defines the association between business rules and state identifiers; the calculation of the condition attributes of the system instance (i.e., the condition judgment result in step S20) (such as isOperationAllowedisInviter) and the caching mechanism are the core logic for component rendering data preparation in the state-driven module.

[0030] To facilitate understanding of the embodiments of this application, a "Invite Friends to Help with a Lucky Draw" marketing campaign on an e-commerce platform is used as an example to illustrate the specific implementation process of this embodiment. In this campaign, users can act as "inviters" to invite friends to help, or as helpers to assist others. The system needs to dynamically display different components and interaction logic based on real-time status (such as the number of helpers, campaign time, user roles, etc.). Specifically, as follows: The first step is to pre-configure a configurable state condition mapping table.

[0031] For the "invite friends to help with the lucky draw" scenario, a state condition mapping table (named STATUS CONDITIONMAPPING) is defined, containing multiple rule objects. Each rule object consists of a condition judgment function and a state flag, for example: Status identifier constants: such as "Inviter has reached maximum assistance" corresponding to identifier '1', "Inviter needs more assistance" corresponding to identifier '2', "Assistant can provide assistance" corresponding to identifier '5', and "Event ended (backup)" corresponding to identifier '7'.

[0032] Rule object configuration: Sorted by business priority, for example, the rule "Inviter has reached maximum support" has the highest priority, and the "Event Ended" rule serves as a fallback (lowest priority). Each rule's condition judgment function receives a system instance and combines multiple conditions (such as whether it's within the event time, whether the user's role is the inviter, whether the number of supporters has reached the target, etc.). This step corresponds to the state condition mapping table configuration in the rule decision module of the system framework, which is the basic definition for associating business rules with state identifiers.

[0033] It should be noted that, as an example, the above state condition mapping table can be maintained in the form of an independent JSON file (such as status-rules.json) to be independent of the business code. The btnType, as the unique identifier of the state, must be strictly consistent with the backend protocol, and the component field directly corresponds to the registration name of the Vue component (such as the Invitee component, which needs to be registered globally in the Vue instance).

[0034] The second step is to calculate and cache the condition judgment results during system instance operation.

[0035] The system instance (which can be understood as a real-time data carrier during activity execution) carries real-time conditional attribute data for the current scenario, such as current time, activity start and end time, user role, number of contributors, and remaining contribution attempts. Based on preset calculation rules, the system calculates this data and caches the results. For example, "Is it within the activity period?" is determined by comparing the current time with the start and end times of the activity. The result is cached and recalculated only when the current time changes.

[0036] For example, the "Is Inviter?" condition is determined by the user's role, and the result is cached. If the role remains unchanged, there's no need to recalculate. It's worth noting that, as an example, the conditional judgment results of system instances can be cached using Vue's computed properties, such as `isOperationAllowedisInviter`. These computed properties are only recalculated when their dependent underlying conditional properties change; otherwise, the cached result is reused, reducing the overhead of redundant calculations. This step is a core component of the "Component Rendering Data Preparation" module in the system framework's state-driven module, providing real-time and accurate conditional data for subsequent rule matching.

[0037] The third step is to traverse the state condition mapping table by priority and match the first rule object that satisfies the condition.

[0038] The system iterates through the rule objects in the state condition mapping table according to their configuration order (i.e., priority), passing a system instance to the condition judgment function of each rule. If the condition judgment function of a rule returns "satisfied," the iteration immediately terminates, and the corresponding state identifier for that rule is returned. If none of the rules are satisfied, a fallback "activity ended" state identifier is returned. For example, if the current user is the inviter, the number of helpers is 2 (less than 3), and the activity is within the specified time, then the rule "inviter needs more help" is matched, and state identifier '2' is returned. This step corresponds to the "state dispatcher" logic of the rule decision module in the system framework. It outputs the current business state through short-circuit matching and is a key link connecting rule configuration and component rendering.

[0039] The fourth step is to match front-end components, interactive text, and triggering events based on status identifiers.

[0040] A pre-configured status component mapping table stores the mapping between status identifiers and front-end resources: For example, the status indicator '2' corresponds to the component "InviteButton", the interactive text "Invite friends to help", and the trigger event "Share Invitation" (inviteFriends). After matching the corresponding resources based on the status indicator, the front-end is dynamically rendered. The matching of status indicators and components can be monitored in real time through Vue's watch mechanism. For example, when currentStatusType changes, componentName is immediately updated, and then...<component:is="componentName"> Dynamically switching components is achieved by using Vue's watch mechanism to listen for changes in currentStatus. It's important to note that in Vue's watch mechanism, currentStatus is a developer-defined data property to be monitored. Its core function is to declare a variable that Vue needs to listen to; when the value of this variable changes, a specified callback function is triggered. This step directly demonstrates the dynamic component loading functionality of the system framework's state-driven module, achieving precise mapping and efficient rendering between state and components.

[0041] As can be seen, this embodiment decouples business rules from code logic through a configurable state condition mapping table. Adding / modifying a state only requires adjusting the configuration table, not the core code. Combined with a computed property caching mechanism, it reduces redundant calculations, triggering updates only for affected components and avoiding full-page re-rendering. This significantly reduces redundant rendering in high-frequency state change scenarios, improving page interaction smoothness. Simultaneously, it lowers code maintenance costs and supports rapid iteration of business rules. Compared to traditional state management solutions (such as traditional Vuex solutions), this method avoids full-page re-rendering when a single state changes through precise state-component mapping, reducing redundant layout calculations and effectively minimizing redundant rendering operations in high-frequency state change scenarios, thus improving page interaction smoothness.

[0042] In one embodiment, the priority of the rule object is determined by its configuration order in the state condition mapping table. During the traversal, the condition judgment function of each rule object is executed in the configuration order, and only the state identifier corresponding to the first rule object that satisfies the condition judgment function is matched and returned.

[0043] To facilitate understanding of this embodiment, we will use an e-commerce platform's "limited-time assistance for redeeming goods" marketing campaign as an example to illustrate the logic that "the priority of rule objects is determined by the configuration order, and only the status identifier of the first one that meets the condition is returned." The specific implementation is as follows: Rule configuration (including priority) for the state condition mapping table.

[0044] The rule objects in the status condition mapping table (STATUS_CONDITION_MAPPING) are configured from high to low according to business priority: Rule 1 (highest priority): The number of inviters has reached the maximum number of people who can help (≥5 people and within the event period), and the status is marked '101' (redeemable items).

[0045] Rule 2 (Second highest priority): If the person who helped has already helped the inviter (not the inviter, helped and within the event period), the status will be marked '201' (helped, cannot be repeated).

[0046] Rule 3 (Medium Priority): The person helping has remaining help attempts (not the inviter, remaining attempts > 0 and within the event period), status indicator '202' (can help).

[0047] Rule 4 (Lowest Priority, Last Choice Rule): The activity has ended (not within the activity period), status identifier '901'. This step corresponds to the "Status Condition Mapping Table" in the rule decision module of the system framework. The priority is defined by the configuration order, which is the basis for rule matching.

[0048] System instances and conditional judgments: System instances carry data in real time, such as: the current user is a helper, has already helped the inviter, has remaining help attempts, and the activity is within the validity period.

[0049] Priority-based traversal and short-circuit matching: Traverse according to the rule configuration order, passing system instances to the conditional judgment function: Rule 1: User is a helper (not an inviter) → Not satisfied, continue iterating.

[0050] Rule 2: If the user is a helper, has already helped, and meets the requirements within the activity period, the iteration will immediately terminate and the status flag '201' will be returned.

[0051] Although the user also meets rule 3 (has remaining attempts), only the status flag for rule 2 is returned because rule 2 has a higher priority. The traversal process uses the array's `find` method to implement short-circuit matching; that is, it returns immediately after finding the first satisfied rule, terminating subsequent traversal, thus implementing a multi-level conditional short-circuit matching algorithm for priority matching. This step is the core algorithm of the "state dispatcher" module in the system framework, ensuring the efficiency and accuracy of rule judgment through priority sorting and short-circuit matching.

[0052] In this embodiment, the priority of rule objects is determined according to the configuration order, and short-circuit matching (terminating when the first condition is met) reduces invalid traversal and reduces a lot of judgment time compared to traditional multi-layer nested if-else. High-priority rules take effect first, avoiding conflicts of matching multiple states in the same scenario, improving rule matching efficiency, avoiding state conflicts, and ensuring the correctness of business logic.

[0053] In one embodiment, the condition judgment function of each rule object contains multi-level sub-conditions arranged in a preset logical order. The multi-level sub-conditions include a basic qualification layer, a scene feature layer, and a resource threshold layer. Each level of sub-condition is sequentially associated with and depends on the judgment result of the previous level. When executing the conditional judgment function, each sub-condition is checked sequentially in hierarchical order: Basic Qualification Layer: Determine whether the conditional attribute data related to the basic participation qualification of the e-commerce marketing activity in the system instance meets the preset basic participation qualification requirements. If it does, then determine that the sub-conditions of the basic qualification layer are met. Scene Feature Layer: Under the premise that the basic qualification layer is satisfied, it is determined whether the conditional attribute data related to a specific marketing scene meets the preset scene limitation requirements. If it does, it is determined that the sub-conditions of the scene feature layer are satisfied. Resource threshold layer: Under the premise that the scene feature layer is satisfied, it is determined whether the condition attribute data related to the resource value meets the preset resource threshold requirements. If it does, it is determined that the sub-condition of the scene feature layer is satisfied. If any sub-condition at any level fails to meet the validation, the subsequent level's judgment process is immediately terminated, and the entire condition judgment function returns that the condition is not met; the condition judgment function returns that the condition is met only when all sub-conditions at all levels have been validated.

[0054] To facilitate understanding, we'll use an e-commerce platform's "Invite friends to help redeem limited-time coupons" marketing campaign as an example to illustrate the logic of "conditional judgment functions containing multiple levels of sub-conditions, validating them hierarchically and depending on the result of the previous level." The specific implementation is as follows: The rule objects (including multi-level sub-conditions) in the state condition mapping table.

[0055] The condition judgment function for a certain rule object (inviter can redeem coupons) contains three layers of sub-conditions, which are sequentially related and each layer depends on the result of the previous layer: Condition judgment function = Basic qualification layer satisfied → Scene feature layer satisfied → Resource threshold layer satisfied. This step is a complex condition definition method of the "Condition Rule Table" in the rule decision module of the system framework, which refines the business logic through layering.

[0056] The specific definition of multi-level sub-conditions.

[0057] Basic Qualification Layer: Determines if a user has basic participation qualifications. Conditions: The current time is within the activity's start and end time (isActivityInTime) and the user is logged in (userIsLoggedIn). If these conditions are not met, directly return "Conditions not met".

[0058] Scene Feature Layer: Under the premise that the basic qualification layer is met, determine specific scene features. Conditions: The user role is the inviter (userRole==='inviter') and the current page is the "Invite Friends Page" (currentPage==='invitePage'). If these conditions are not met, return "condition not met".

[0059] Resource Threshold Layer: Under the premise that the scene feature layer is satisfied, determine the resource value conditions. Condition: The inviter has received help from at least 5 friends (helperCount>=5) and the coupon has stock (couponStock>0). If satisfied, return condition satisfied; otherwise, return condition not satisfied.

[0060] It should be noted that the judgment of each level of sub-conditions depends on the computed properties of the system instance (such as isActivityInTime and userIsLoggedIn). These properties avoid duplicate calculations through a caching mechanism; for example, isActivityInTime is only re-validated when currentTime changes. The status rule configuration center can be an independent status-conditions.js configuration file, which can be exported for global use. Modifying rules does not require changing the component logic code. This step demonstrates the support of the rule decision module in the system framework for complex business scenarios, reducing invalid judgments and improving rule matching accuracy through hierarchical dependencies.

[0061] System instance and hierarchical verification process.

[0062] Scenario 1: User not logged in (basic qualification level not met) → Terminate judgment, condition not met.

[0063] Scenario 2: The user is logged in and within the activity period (basic eligibility is met), but the role is an assistant (scenario feature is not met) → Terminate judgment, condition is not met.

[0064] Case 3: Both the basic qualification layer and the scenario feature layer are met, and there are 5 people assisting and there is inventory (the resource threshold layer is met) → the conditions are met, and the corresponding status identifier is returned.

[0065] In this embodiment, multi-level sub-conditions are validated sequentially in the order of "basic qualification layer → scene feature layer → resource threshold layer," and the process terminates if any layer fails to meet the requirement, thus avoiding redundant judgments. A caching mechanism relying on computational attributes ensures that calculations are only performed when the basic data changes, significantly reducing computational load and maintenance costs compared to flatter conditional judgments. In other words, it reduces the complexity of multi-dimensional conditional judgments, improves the ease of rule maintenance, reduces invalid calculations, and optimizes system performance.

[0066] It is worth noting that after adopting the configuration-based rule decision-making mechanism, when adding new status rules (such as activities not started), only 1-2 lines of configuration need to be added to STATUS_CONDITION_MAPPING, without modifying the core business logic, which reduces the amount of code changes compared to the traditional hard-coding method.

[0067] In one embodiment, after the first conditional judgment function returns that the traversal is terminated and the corresponding status flag is returned, the method further includes: S101. Query the pre-configured state component mapping relationship library to obtain the component identifier and configuration information corresponding to the state identifier. The configuration information includes the component type, interaction logic code and rendering parameters related to the e-commerce marketing scenario. S102. Compare the obtained component identifiers with the currently loaded component set to determine the list of components to be created, components to be updated, and components to be destroyed; S103. Perform operations on the components in the front-end page according to the list: instantiate and render unloaded components to be created; adjust the properties of loaded components to be updated; remove components to be destroyed that do not need to be displayed and release resources; and load the configuration information to ensure that the components in the current front-end page are correctly displayed and respond according to the configuration information.

[0068] To facilitate understanding, this example uses a marketing campaign on an e-commerce platform called "Friends Help Unlock Rewards" to illustrate the logic of "performing creation, update, and destruction operations on the front-end component after matching the component based on its status identifier" in this application's embodiment. The specific implementation is as follows: Query the state component mapping relationship library to obtain configuration information.

[0069] The state component mapping library stores the correspondence between state identifiers and front-end resources: Status indicator '1' (Help to reach the goal): Component "Unlock Reward Button", text "Unlock Reward", event "Open Lottery", style is red background, width 200px.

[0070] Status indicator '2' (Help not met): Component "Invite Button", text "Invite friends to help", event "Share Invite", style is gray background, width 200px.

[0071] When the system determines that the current state identifier is '2', it queries the library to obtain the corresponding configuration. This step corresponds to the state component mapping relationship library in the state-driven module of the system framework, and is the core configuration for state identifier → component association.

[0072] Compare the current set of components to determine the list of operations.

[0073] The system detects that the currently loaded components are ['Header', 'ProgressBar', 'UnlockButton'] (including the "Unlock Reward Button" from the previous state), compares them with the new component 'InviteButton', and generates an action list: To be created: InviteButton (not currently loaded).

[0074] To be destroyed: UnlockButton (non-target component).

[0075] Update pending: None (target component not loaded).

[0076] Perform component operations and load configuration information, following the manifest: Create an InviteButton component and load its style (gray background, 200px wide), text, and events.

[0077] Destroy the UnlockButton component, releasing its DOM nodes and event resources.

[0078] Retain the basic components (Header, ProgressBar) and do not perform any operations.

[0079] It should be noted here that the dynamic creation and switching of components mentioned above can be achieved through Vue's...<component:is="componentId"> Syntax implementation, for example, when creating an InviteButton component, directly through...<component:is="InviteButton":config="config"> "Rendering without manual DOM manipulation." This step is a detailed process of the "dynamic component loading" function in the state-driven module of the system framework. By precisely manipulating components, it avoids a full page repaint and embodies the optimization goal of "partial DOM update."

[0080] In this embodiment, a precise operation list is generated by comparing the current component set, and operations are only performed on components that are to be created, updated, or destroyed, avoiding a full page repaint; basic components (such as titles and progress bars) do not need to be reloaded, reducing a large number of DOM operations compared to traditional full rendering, reducing redundant operations of front-end components, improving page rendering performance, increasing component reusability, and reducing code redundancy.

[0081] In one embodiment, the method further includes the following steps: S201. Mark the component identifier associated with the state identifier as the target component, and mark the remaining components as non-target components; S202. Execute the activation rendering process for the target component and the resource release and rendering pause process for the non-target component. S203. In response to the update request for the target component, a virtual node tree of the before and after states is generated, and a difference set is calculated by comparing node attributes to generate a document object model operation instruction containing only the difference part. The document object model operation instruction (DOM operation instruction) is used to modify the actual document object model element of the target component in the front-end page.

[0082] To facilitate understanding, we will use the "Help to Win Big Prizes" marketing campaign on an e-commerce platform as an example to illustrate the logic of target component activation and rendering, non-target component resource release, and the generation of precise DOM instructions through virtual node tree difference calculation. Specific implementation process: Mark the target component and the non-target component.

[0083] The target components for status indicator '2' (progress 2 / 5, not yet achieved) are the "ProgressBar" and the "InviteButton". Other page components (PageTitle, RuleDescription, Footer) are non-target components. This step is a prerequisite for the "Partial DOM Update" module in the system framework, reducing unnecessary operations by differentiating component types.

[0084] Target component is activated for rendering and non-target component resources are released.

[0085] Target components: The progress bar width is recalculated (2 / 5 → 40%) and the displayed text is updated; the button retains its text but is bound to a new click event (to count the current progress).

[0086] Non-target components: Remove event listeners for non-target components (such as the expand event of the rule description), pause rendering updates, and release cached resources (such as rule images).

[0087] Generate a virtual node tree and calculate the difference set to generate the virtual node tree (an abstract DOM description) of the target component before and after the update: Before the update: the progress bar width was 20%, the text was "1 / 5 people helped"; the button event was the old share event.

[0088] After the update: the progress bar width is 40%, the text "2 / 5 people helped" is updated, and the button event is the new share event. By comparison, the differences are identified: the progress bar width and text have changed, and the button event has changed. It should be noted that the difference calculation in the virtual node tree can be implemented based on Vue's diff algorithm, comparing only the changes in the target component's properties (such as width, text, and on.click), ignoring unchanged properties and non-target components. The resulting DOM manipulation instructions only apply to the differences, achieving a "partial DOM update."

[0089] Generate DOM manipulation instructions that only contain the differences.

[0090] Based on the difference set, the system generates precise instructions: Progress bar: Update width to 40%, text to "2 / 5 people helped".

[0091] Button: Change the click event to the new share event.

[0092] After the front-end executes the command, only the differing parts of the target component are updated. This step is the underlying technology for partial DOM updates in the state-driven module of the system framework. It reduces redundant rendering and improves page response speed through a diff algorithm.

[0093] In this embodiment, the target component only updates the differences (calculated through the virtual node tree diff algorithm), while non-target components pause rendering and release resources, reducing operation time compared to a full DOM update; memory usage is reduced, making it especially suitable for mobile devices with low performance.

[0094] In one embodiment, the pre-configured configurable state condition mapping table includes: S301. Collect parameters of the current operating environment, including operating system name and version, hardware processor model, screen resolution and set of interaction event types; S302. Query the adaptation rule base to obtain the adaptation rules that match the current environment parameters. The adaptation rules include state condition adjustment rules and component configuration adjustment rules. S303. The adaptation rules are injected into the rule objects of the state condition mapping table respectively, so that the condition judgment function of the rule object is adapted to the condition attribute data format of the system instance of the e-commerce marketing activity business system under different program running platforms.

[0095] To facilitate understanding, this section uses an e-commerce platform's "Cross-Platform Assistance for Red Envelopes" marketing campaign as an example to illustrate the logic of injecting adaptation rules to ensure compatibility across multiple platforms when pre-configuring the state condition mapping table. Specific implementation process: Collect parameters of the current operating environment.

[0096] The system collects runtime environment parameters, for example, only as an explanatory note: iOS system, Apple A15 processor, screen resolution 375×812px, supports tap interaction events (indicated as program B environment).

[0097] The environment detection module is an independently encapsulated utility class (such as EnvironmentDetector.js). Its core function is to parse the User Agent (UA), call platform APIs, and determine device characteristics to output standardized environment parameters. Internally, it includes methods such as getChannel() (identifying platforms like application B / application A / PC), isMobile() (determining device type), and getUA() (extracting the raw UA string), serving as a fundamental component for cross-platform adaptation. The definition of "obtaining environment parameters through UA parsing and platform API calls" is crucial. This step is the core work of the environment detection module within the system framework, providing raw data for subsequent adaptation rule matching.

[0098] The environment detection module is an independently encapsulated utility class (such as EnvironmentDetector.js). Its core function is to parse the User Agent (UA), call platform APIs, and determine device characteristics to output standardized environment parameters. Internally, it includes methods such as getChannel() (identifying platforms like application B / application A / PC), isMobile() (determining device type), and getUA() (extracting the raw UA string). It is a fundamental component for cross-platform adaptation. The environment detection module (EnvironmentDetector) obtains environment parameters through UA parsing and platform API calls.

[0099] Query the adaptation rule library to obtain the matching adaptation rule.

[0100] The adaptation rule base stores adaptation rules for different environments, including state condition adjustment rules and component configuration adjustment rules. Based on the collected parameters, the adaptation rules for program B's environment are matched as follows: State condition adjustment rule: Convert the user identifier openId of program B to the system-wide userId.

[0101] Component configuration adjustment rules: The button width is set to 60% of the screen width, and the interaction event is changed from click to tap. The adaptation rules of the environment detection module follow the CHANNEL enumeration and CHANNEL_STRATEGIES strategy configuration (matching program A, program B, mobile terminal, and PC terminal in order of priority from high to low) to ensure the standardization of environment judgment.

[0102] It's worth noting that for platforms that don't support the business logic (such as mobile browsers that are not application B / application A), the adaptation rules will trigger the onboarding page loading logic. For example, in the `verifyEntryType` method, if `flag === 'HTML5'`, then `this.isGuide = true` is set, dynamically rendering the `guide.vue` component to redirect the user to a supported platform (such as application B). This step involves the linkage between the environment detection module "strategy loader" and the rule decision module "conditional rule table" in the system framework. The environment detection results drive rule adaptation, ensuring that the rules are compatible with the current platform.

[0103] Inject the adaptation rules into the rule object of the state condition mapping table.

[0104] State condition mapping table: The condition judgment function of the original rule depends on userId. After the rule is injected, the openId of program B is automatically converted to userId to ensure the compatibility of the judgment logic.

[0105] State component mapping table: The original component's button width is 200px, and the event is click. After injecting rules, the width is adjusted to 225px (375×60%), and the event is converted to tap, adapting to application environment B. This step demonstrates the adaptability of the rule decision module in the system framework to environmental differences, making the same core logic compatible with multiple platforms by injecting rules.

[0106] It should be noted that the platform types (such as program A, program B) and other examples involved in this embodiment and the embodiments of this application are only explanatory descriptions for the purpose of understanding the solution.

[0107] In this embodiment, by dynamically injecting state condition adjustment and component configuration adjustment rules into the adaptation rule base, the same core logic can be compatible with multiple platforms such as Program B, PC, and mobile terminals. Adding a new platform only requires adding adaptation rules instead of modifying the core code, reducing development workload compared to traditional hard-coding adaptation. This achieves efficient cross-platform environment adaptation and lowers development costs for new platforms; it also avoids coupling environment adaptation logic with business code, improving system scalability. Furthermore, after the environment detection module is separated, its code can be directly reused when integrating into a new mobile project, avoiding redundant development and saving environment adaptation development time compared to traditional solutions.

[0108] In one embodiment, the execution of the adaptation rule includes: S401. Based on the parameters of the current operating environment, convert the format of the conditional attribute data carried in the system instance so that the conditional judgment function can parse the conditional attribute data under different program running platforms. S402. Based on the event types supported by the current platform, convert the trigger event associated with the status identifier into the event format of the corresponding platform; S403. Based on the performance parameters of the current front-end hardware processor, and in accordance with the calculation frequency control rules, set the execution interval of the condition judgment function. S404. Based on the current screen resolution of the front-end device, calculate the scaling ratio of the front-end component size according to the rendering parameter correction rules, and adjust the layout pixel units and font display precision.

[0109] To facilitate understanding of the embodiments of this application, we take a certain e-commerce "cross-platform limited-time flash sale" marketing campaign as an example to illustrate the execution logic of the adaptation rules.

[0110] Convert the format of conditional attribute data in the system instance.

[0111] Different program runtime platforms use different system instance data formats, which need to be uniformly converted, for example: Program B: User identifier is openId (string), activity time is "2024-09-01 10:00" (string) → Convert to system-standard userId and timestamp.

[0112] PC version: User identifier is username (string), activity time is timestamp → converted to system-wide userId (timestamp preserved).

[0113] For platform A, user department information in the system instance needs to be obtained from platform A's API. The adaptation rules will convert it into the system's unified `deptId` format to ensure consistency of user information across platforms. The output of the environment detection module will serve as the input parameter for executing the adaptation rules. The system automatically calls the adaptation rules for platform A's environment to ensure the accuracy of data format conversion and event adaptation, reflecting the core role of the environment detection module in providing decision-making basis for adaptation rules. This step is the implementation of the data adaptation strategy output by the environment detection module's strategy loader in the system framework within the state-driven module, ensuring consistent data formats across platforms.

[0114] Convert the format of the trigger event associated with the status identifier.

[0115] Different program execution platforms support different event types, which need to be converted: Program A: Supports tap events, converting the original click event into a tap event.

[0116] PC version: Supports click events, preserving the original click event. Sets the execution interval for conditional functions, adjusting the interval based on hardware performance. Program B (Processor A): Medium performance, interval set to 1000ms (1 time / second).

[0117] PC (Processor B): High performance, interval set to 500ms (2 times / second). The execution interval setting needs to be adapted to the performance of different program running platforms. For example, in the program B environment, to avoid lag caused by frequent calculations, the interval duration needs to be adjusted according to the performance limitations of the program's BSDK.

[0118] Adjust the scaling ratio and layout parameters of the front-end components according to the screen resolution: Program B (375×812px): Scaling ratio 1:1, button width 200px, font 14px, unit px.

[0119] PC version (1920×1080px): scaling ratio 1.5:1, button width 300px (200×1.5), font 21px (14×1.5), unit rem.

[0120] For older browsers or devices with insufficient hardware performance that are not yet compatible, the adaptation rules will prioritize loading a simplified onboarding page (rather than the complete business components). The onboarding page only contains redirection prompts and basic styles, reducing resource loading. This step involves collaboration between the environment detection module (providing screen resolution parameters) and the state-driven module (component layout rendering) in the system framework to ensure consistent display across platforms.

[0121] It should be noted that the platform types (such as program A, program B) and other examples (such as program B) involved in this embodiment and the embodiments of this application are only explanatory descriptions for the purpose of understanding the solution.

[0122] In this embodiment, data format conversion solves the problem of cross-platform parameter incompatibility, event format adaptation ensures normal interactive response, execution interval adjustment adapts to hardware performance, and layout scaling ratio adapts to screen resolution. Compared with the unadapted solution, it improves cross-platform compatibility. By executing adaptation rules, it achieves data compatibility, event adaptation, performance optimization and layout consistency across multiple platforms, optimizes performance under different hardware environments, and avoids lag or layout errors.

[0123] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0124] In one embodiment, a dynamic state processing device for a business scenario is provided, which corresponds one-to-one with the dynamic state processing methods for business scenarios in the above embodiments. For example... Figure 4 As shown, the dynamic state processing device for this business scenario includes a configuration unit 401, a caching unit 402, a traversal unit 403, and a processing unit 404. Detailed descriptions of each functional module are as follows: Configuration unit 401 is used to pre-configure a configurable state condition mapping table. The state condition mapping table contains multiple rule objects. Each rule object includes a condition judgment function and a corresponding state identifier. The condition judgment function is used to receive a system instance as a parameter and perform combined judgment on the multi-dimensional conditions in the system instance. The system instance is an instantiated object generated during the operation of the e-commerce marketing activity business system. The system instance is used to carry various condition attribute data under the current e-commerce marketing scenario in real time. The caching unit 402 is used to extract the conditional attribute data carried in real time in the system instance during the operation of the system instance, calculate the extracted conditional attribute data based on the preset calculation rules of the e-commerce marketing scenario, generate conditional judgment results related to the e-commerce marketing scenario, and cache the conditional judgment results. The traversal unit 403 is used to traverse the state condition mapping table according to the priority order of the business rules reflected in the state condition mapping table of the rule objects, so as to pass the system instance to the condition judgment function of each rule object. During the execution of the condition judgment function, the cached condition judgment result is called to complete the combined judgment. When the condition judgment function of the first rule object returns that the condition is met, the traversal is terminated and the corresponding state identifier is returned. If the condition judgment function of all rule objects does not meet the return condition, the default termination state identifier is returned. The processing unit 404 is used to match the corresponding front-end component, interactive text and triggering event from the state component mapping table based on the state identifier, so as to drive the dynamic rendering of the front end.

[0125] Specific limitations regarding the dynamic state processing device for business scenarios can be found in the limitations of the dynamic state processing method for business scenarios described above, and will not be repeated here. Each module in the aforementioned dynamic state processing device for business scenarios can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0126] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements a dynamic state processing method for a business scenario as described in the above embodiment. To avoid repetition, this will not be repeated here. Alternatively, when the processor executes the computer program, it implements a dynamic state processing device for a business scenario, which performs the functions of this embodiment. To avoid repetition, this will not be repeated here.

[0127] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When executed by a processor, the computer program implements a dynamic state processing method for a business scenario described in the above embodiment, which will not be elaborated further here. Alternatively, when executed by a processor, the computer program implements the function of a dynamic state processing device for a business scenario described above, which will not be elaborated further here to avoid repetition.

[0128] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for handling dynamic states in a business scenario, characterized in that, include: A configurable state condition mapping table is pre-configured. The state condition mapping table contains multiple rule objects. Each rule object includes a condition judgment function and a corresponding state identifier. The condition judgment function is used to receive a system instance as a parameter and perform combined judgment on the multi-dimensional conditions in the system instance. The system instance is an instantiated object generated during the operation of the e-commerce marketing activity business system. The system instance is used to carry various condition attribute data under the current e-commerce marketing scenario in real time. During the operation of the system instance, the conditional attribute data carried in real time in the system instance is extracted, and the extracted conditional attribute data is calculated based on the preset calculation rules of the e-commerce marketing scenario to generate conditional judgment results related to the e-commerce marketing scenario, and the conditional judgment results are cached. According to the priority order of the business rules reflected in the state condition mapping table of the rule objects, the state condition mapping table is traversed to pass the system instance to the condition judgment function of each rule object. During the execution of the condition judgment function, the cached condition judgment result is called to complete the combined judgment. The traversal terminates and the corresponding status flag is returned when the condition judgment function of the first rule object returns that the condition is met. If the condition judgment function of all rule objects does not meet the return condition, the default termination status flag is returned. Based on the state identifier, the corresponding front-end component, interactive text, and triggering event are matched from the state component mapping table to drive the dynamic rendering of the front-end. The state component mapping table stores the correspondence between state identifiers and front-end resources.

2. The method as described in claim 1, characterized in that, The priority of the rule object is determined by its configuration order in the state condition mapping table. During the traversal, the condition judgment function of each rule object is executed in the configuration order, and only the state identifier corresponding to the first rule object that satisfies the condition judgment function is matched and returned.

3. The method as described in claim 1, characterized in that, Each rule object's condition judgment function contains multi-level sub-conditions arranged in a preset logical order. The multi-level sub-conditions include a basic qualification layer, a scene feature layer, and a resource threshold layer. Each level of sub-condition is sequentially associated with and depends on the judgment result of the previous level. When executing the conditional judgment function, each sub-condition is checked sequentially in hierarchical order: Basic Qualification Layer: Determine whether the conditional attribute data related to the basic participation qualification of the e-commerce marketing activity in the system instance meets the preset basic participation qualification requirements. If it does, then determine that the sub-conditions of the basic qualification layer are met. Scene Feature Layer: Under the premise that the sub-conditions of the basic qualification layer are met, it is determined whether the condition attribute data related to a specific marketing scene meets the preset scene limitation requirements. If they do, it is determined that the sub-conditions of the scene feature layer are met. Resource threshold layer: Under the premise that the scene feature layer is satisfied, it is determined whether the condition attribute data related to the resource value meets the preset resource threshold requirements. If it does, it is determined that the sub-condition of the resource threshold layer is satisfied. If any sub-condition at any level fails to meet the validation, the subsequent level's judgment process is immediately terminated, and the entire condition judgment function returns that the condition is not met; the condition judgment function returns that the condition is met only when all sub-conditions at all levels have been validated.

4. The method according to any one of claims 1-3, characterized in that, After the first conditional judgment function returns that the condition is met, the traversal is terminated and the corresponding status flag is returned, the method further includes: Query the pre-configured state component mapping relationship library to obtain the component identifier and configuration information corresponding to the state identifier. The configuration information includes the component type, interaction logic code and rendering parameters related to the e-commerce marketing scenario. The obtained component identifiers are compared with the currently loaded component set to determine the list of components to be created, components to be updated, and components to be destroyed; Perform the following operations on the components in the front-end page according to the list: instantiate and render unloaded components to be created; adjust the properties of loaded components to be updated; remove and release resources of components to be destroyed that do not need to be displayed; and load the configuration information to ensure that the components in the current front-end page are correctly displayed and respond according to the configuration information.

5. The method as described in claim 4, characterized in that, After the first conditional judgment function returns that the condition is met, the traversal is terminated and the corresponding status flag is returned, the method further includes: The component identifier associated with the state identifier is marked as the target component, and the remaining components are marked as non-target components; Activate the rendering process for the target component and perform resource release and rendering pause processes for non-target components; In response to an update request for the target component, a virtual node tree of the before and after states is generated, and a difference set is calculated by comparing node attributes. A document object model operation instruction containing only the difference portion is generated. The document object model operation instruction is used to modify the actual document object model elements of the target component in the front-end page.

6. The method according to any one of claims 1-3, characterized in that, The pre-configured configurable state condition mapping table includes: Collect parameters of the current operating environment, including operating system name and version, hardware processor model, screen resolution, and set of interaction event types; Query the adaptation rule base to obtain adaptation rules that match the current environment parameters. The adaptation rules include state condition adjustment rules and component configuration adjustment rules. The adaptation rules are injected into the rule objects of the state condition mapping table, so that the condition judgment function of the rule object can adapt to the condition attribute data format of the system instance of the e-commerce marketing activity business system under different program running platforms.

7. The method as described in claim 6, characterized in that, The execution of the adaptation rules includes: Based on the parameters of the current operating environment, the format of the conditional attribute data carried in the system instance is converted so that the conditional judgment function can parse the conditional attribute data under different program running platforms; Based on the event types supported by the current platform, convert the triggered events associated with the status identifiers into the event format of the corresponding platform; Based on the performance parameters of the current front-end hardware processor, and in accordance with the calculation frequency control rules, the execution interval of the condition judgment function is set. Based on the current screen resolution of the front-end device, and according to the rendering parameter correction rules, calculate the scaling ratio of the front-end component size, and adjust the layout pixel units and font display precision.

8. A dynamic state processing device for a business scenario, characterized in that, include: The configuration unit is used to pre-configure a configurable state condition mapping table. The state condition mapping table contains multiple rule objects. Each rule object includes a condition judgment function and a corresponding state identifier. The condition judgment function is used to receive a system instance as a parameter and perform combined judgment on the multi-dimensional conditions in the system instance. The system instance is an instantiated object generated during the operation of the e-commerce marketing activity business system. The system instance is used to carry various condition attribute data under the current e-commerce marketing scenario in real time. The caching unit is used to extract the conditional attribute data carried in real time in the system instance during the operation of the system instance, calculate the extracted conditional attribute data based on the preset calculation rules of the e-commerce marketing scenario, generate conditional judgment results related to the e-commerce marketing scenario, and cache the conditional judgment results. The traversal unit is used to traverse the state condition mapping table according to the priority order of the business rules reflected in the state condition mapping table of the rule object, so as to pass the system instance into the condition judgment function of each rule object. The condition judgment function calls the cached condition judgment result during the execution process to complete the combined judgment. The traversal terminates and the corresponding status flag is returned when the condition judgment function of the first rule object returns that the condition is met. If the condition judgment function of all rule objects does not meet the return condition, the default termination status flag is returned. The processing unit is used to match the corresponding front-end component, interactive text and triggering event from the state component mapping table based on the state identifier, so as to drive the dynamic rendering of the front end.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the dynamic state processing method for the business scenario as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the dynamic state processing method for the business scenario as described in any one of claims 1 to 7.

Images