State management model optimization method and device, electronic equipment and readable storage medium
By dividing React projects into Stores, Actions, and Views layers, and utilizing the decorator pattern and on-demand instantiation of Store and Action classes, the problem of scattered code in large projects was solved, achieving efficient project management and performance improvement.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING KNOWNSEC INFORMATION TECHNOLOGY CO LTD
- Filing Date
- 2022-06-14
- Publication Date
- 2026-07-24
AI Technical Summary
The existing React state management tool MobX is too flexible, resulting in code scattered throughout the project, making it difficult to manage in a unified manner. This makes it difficult to maintain large projects during feature refactoring, and also results in poor component reusability.
The project is divided into Stores, Actions, and Views layers, each corresponding to a different storage scope. Through layered management, the decorator pattern is used to find file locations, and on-demand instantiation of Store and Action classes is implemented.
It improves the maintainability of large projects, reduces the workload of modifying and searching files, enhances performance and component reusability, and avoids a messy project structure.
Smart Images
Figure CN115048092B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and more specifically, to a state management model optimization method, apparatus, electronic device, and readable storage medium. Background Technology
[0002] React is a JavaScript library developed by Facebook for building user interfaces. It allows you to build encapsulated components that manage their own state, and then combine these components to create complex UIs (User Interfaces). The state of a component refers to the data that drives the application. Besides maintaining its own internal state data (accessed via `this.state`), a component can also use data from outside the component (accessed via `this.props`). When a component's state data changes, React can efficiently update and render the appropriate component, resulting in a fast and responsive page.
[0003] However, React's capabilities alone are insufficient to meet the demands of today's complex applications. While React can manage some state data, the amount of state data that needs to be managed is increasing as application development becomes more complex. This state data may include server response results, cached data, UI state, page markup, and more. Moreover, the same state data may be used in multiple components, which involves data transfer between parent and child components, sibling components, and non-adjacent components. For React applications with a tree-like structure, data transfer between sibling components and non-adjacent components is difficult and significantly impacts performance.
[0004] As shown above, React requires a dedicated state management tool. This tool needs to be able to manage globally used state, making data transfer more convenient; it also needs to function like the state of React components themselves, so that when a global state changes, the corresponding components using that state will also be updated. MobX is one such existing state management tool.
[0005] One of MobX's key features is its flexibility; state data and interaction logic can be defined anywhere. However, this flexibility also means haphazardness. MobX code is scattered throughout the project, making unified management impossible and hindering modifications to state data files or interaction logic. Summary of the Invention
[0006] This application provides a state management model optimization method, apparatus, electronic device, and readable storage medium. By dividing the project into Stores, Actions, and Views layers, with each layer corresponding to a different storage range, it facilitates management. Furthermore, when modifications are required, the file to be modified can be found from the corresponding storage range, thus narrowing the search scope.
[0007] The embodiments of this application can be implemented as follows:
[0008] In a first aspect, embodiments of this application provide a method for optimizing a state management model, the method comprising:
[0009] The target project is divided into Stores, Action, and Views layers, with different storage scopes for each layer. The Stores layer includes Store classes, which contain property files. The Action layer includes Action classes that indicate interaction logic, which contain at least one Action function. The Views layer includes components.
[0010] Based on the received modification operation, the target file corresponding to the modification operation is modified, wherein the target file is the attribute file or Action function specified by the modification operation.
[0011] Secondly, embodiments of this application provide a state management model optimization apparatus, the apparatus comprising:
[0012] The layered module is used to divide the target project into Stores, Action, and Views layers. The storage scope of each layer is different. The Stores layer includes Store classes, which include property files. The Action layer includes Action classes that indicate interaction logic, which include at least one Action function. The Views layer includes components.
[0013] The modification module is used to modify the target file corresponding to the received modification operation, wherein the target file is the attribute file or Action function specified by the modification operation.
[0014] Thirdly, embodiments of this application provide an electronic device, including a processor and a memory, wherein the memory stores machine-executable instructions that can be executed by the processor, and the processor can execute the machine-executable instructions to implement the state management model optimization method described in the foregoing embodiments.
[0015] Fourthly, embodiments of this application provide a readable storage medium storing a computer program thereon, which, when executed by a processor, implements the state management model optimization method as described in the foregoing embodiments.
[0016] The state management model optimization method, apparatus, electronic device, and readable storage medium provided in this application divide the target project into Stores, Action, and Views layers, where different layers correspond to different storage scopes. The Stores layer includes Store classes, which include attribute files. The Action layer includes Action classes for indicating interaction logic, which include at least one Action function. The Views layer includes components. Based on a received modification operation, the target file corresponding to the modification operation is modified, where the target file is the attribute file or Action function specified by the modification operation. This layered approach facilitates the management of the target project. When a file needs to be modified, the corresponding file can be found in the storage scope corresponding to the layer to which the file belongs, and then modified. This method narrows the search scope and facilitates rapid modification of state data files or interaction logic. Attached Figure Description
[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a flowchart of the Mobx workflow;
[0019] Figure 2 A flowchart illustrating how user interaction triggers Action events;
[0020] Figure 3 A schematic diagram of a common MobX structure;
[0021] Figure 4 A block diagram illustrating an electronic device provided in an embodiment of this application;
[0022] Figure 5 One of the flow diagrams of the state management model optimization method provided in the embodiments of this application;
[0023] Figure 6 The second flow diagram of the state management model optimization method provided in the embodiments of this application;
[0024] Figure 7This application provides a schematic diagram of a single data source structure within an embodiment.
[0025] Figure 8 The third flow diagram of the state management model optimization method provided in the embodiments of this application;
[0026] Figure 9 for Figure 8 A flowchart illustrating the sub-steps included in step S150;
[0027] Figure 10 The fourth flow diagram of the state management model optimization method provided in the embodiments of this application;
[0028] Figure 11 One of the block diagrams of the state management model optimization device provided in the embodiments of this application;
[0029] Figure 12 A second block diagram of the state management model optimization device provided in the embodiments of this application;
[0030] Figure 13 The third block diagram of the state management model optimization device provided in the embodiments of this application.
[0031] Icons: 100 - Electronic device; 110 - Memory; 120 - Processor; 130 - Communication unit; 200 - State management model optimization device; 210 - Hierarchical module; 220 - Data source generation module; 230 - Modification module; 240 - Instantiation module. Detailed Implementation
[0032] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.
[0033] Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.
[0034] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, 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, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0035] MobX is a simple, extensible JavaScript state container that provides global, predictable state management. MobX offers a mechanism to optimize application state synchronization with React components: a reactive virtual dependency state graph that only updates when truly needed and always remains up-to-date. MobX's workflow is as follows: Figure 1 As shown.
[0036] An Action represents any piece of code that can change the state, such as user events, backend data pushes, scheduled events, etc. MobX supports unidirectional data flow; by changing the state through Actions, all derived views will be automatically updated atomically when the state changes, and the state change will update all affected views. Because the changes are atomic, MobX is more flexible.
[0037] In existing React projects, MobX can be downloaded via package managers such as npm and yarn, and then simply included in the file. Projects typically divide the state managed by MobX, its corresponding logic functions, and derivatives into a series of cooperating classes called Stores, based on system modules or pages. These are distributed throughout the project along with the system modules or pages. Each Store has any number of dependent observers. By adding the `@observable` decorator to a Store property, that property becomes observable state. The Store also contains several Action functions for modifying the observed state. Actions are the only code that can modify the state and typically send data requests to the server. Using `@observable` makes a component observable, and using `@inject` injects the observed state and Actions into the component, thus associating the component with the Store.
[0038] like Figure 2 As shown, when a user interacts with the page, the `changeKey1` event is triggered. Since this component is an observable component and `changeKey1` is an Action event, it notifies the Store to perform relevant logic processing, then updates the corresponding state, thereby triggering a page re-render. Figure 2 In this context, Component represents a component.
[0039] One of the key features of MobX is its high flexibility; common MobX structures include... Figure 3 As shown, state data can be defined anywhere. For example, it can be defined directly within a component to replace the role of state, or it can be defined in a separate Store file. Interaction logic can also be written either within a component or in a Store file. However, flexibility also means arbitrariness. MobX's various code snippets are scattered throughout the project, making unified management impossible. Moreover, user interactions often involve processing data from multiple Stores, potentially forming a cross-referenced network structure between Stores. This is a fatal weakness in large projects with a large number of pages and complex functions. This network structure leads to interdependence among various Stores, increasing coupling. When refactoring a functional module, it may involve modifying the state and methods within the corresponding Store. This requires checking whether other functional modules use the state or methods of this Store, necessitating a step-by-step investigation. This makes system function refactoring difficult, reduces component reusability, and requires more effort in combining modules.
[0040] In response to the above situation, embodiments of this application provide a state management model optimization method, apparatus, electronic device, and readable storage medium. By dividing the project into Stores, Actions, and Views layers, with different layers corresponding to different storage ranges, it is convenient for modification and other management, which can ensure the maintainability of large projects and avoid the structural mess caused by state management.
[0041] The following detailed description of some embodiments of this application is provided in conjunction with the accompanying drawings. Unless otherwise specified, the following embodiments and features can be combined with each other.
[0042] Please refer to Figure 4 , Figure 4This is a block diagram of an electronic device 100 provided in an embodiment of this application. The electronic device 100 may be, but is not limited to, a computer, a server, etc. The electronic device 100 may include a memory 110, a processor 120, and a communication unit 130. The memory 110, processor 120, and communication unit 130 are electrically connected to each other directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.
[0043] The memory 110 is used to store programs or data. The memory 110 may be, but is not limited to, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), etc.
[0044] The processor 120 is used to read / write data or programs stored in the memory 110 and execute corresponding functions. For example, the memory 110 stores a state management model optimization device 200, which includes at least one software function module that can be stored in the memory 110 in the form of software or firmware. The processor 120 executes various functional applications and data processing by running the software programs and modules stored in the memory 110, such as the state management model optimization device 200 in this embodiment, thereby implementing the state management model optimization method in this embodiment.
[0045] The communication unit 130 is used to establish a communication connection between the electronic device 100 and other communication terminals through the network, and to send and receive data through the network.
[0046] It should be understood that, Figure 4 The structure shown is only a schematic diagram of the electronic device 100. The electronic device 100 may also include components that are larger than... Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown. Figure 4 The components shown can be implemented using hardware, software, or a combination thereof.
[0047] Please refer to Figure 5 , Figure 5 This is one of the flowcharts illustrating the state management model optimization method provided in this application embodiment. The method can be applied to the aforementioned electronic device 100. The specific flow of the state management model optimization method is described in detail below. In this embodiment, the method may include steps S110 and S140.
[0048] Step S110: Divide the target project into Stores, Actions, and Views layers.
[0049] Step S140: Modify the target file corresponding to the received modification operation.
[0050] In this embodiment, the target project can be a React project specified by the user. When developers write this target project, they can place the corresponding files in the storage scope corresponding to the layer to which the files belong, thus dividing the target project into multiple layers. Different layers correspond to different storage scopes. Of course, it is understood that the above is only an example, and layering can also be implemented in other ways. The multiple layers include the Stores layer, the Actions layer, and the Views layer.
[0051] The Stores layer includes a Store class, which contains a property file; the Action layer includes an Action class for indicating interaction logic, which contains at least one Action function; and the Views layer includes components.
[0052] For example, when a developer is writing a properties file, since the properties file belongs to the Stores layer, it can be placed in storage scope 1 of the Stores layer. If the properties file needs to be found later, it can be retrieved from storage scope 1.
[0053] When developers determine that a property file or Action function needs modification based on requirements, they can search within the scope corresponding to the layer to which the file belongs, using the found property file or Action function as the target file, and then input modification operations for that target file. Upon receiving such modification operations, the target file can be modified accordingly. In this way, the file to be modified can be identified without requiring extensive searches by staff, and management is simplified.
[0054] Please refer to Figure 6 , Figure 6 This is a second flow diagram illustrating the state management model optimization method provided in this application embodiment. For further ease of management, in this embodiment, before step S140, the method may further include steps S120 and S130.
[0055] Step S120: Obtain the location of each Store class and the location of each Action class.
[0056] Step S130: Generate a single data source based on the location of each Store class and the location of each Action class.
[0057] Optionally, such as Figure 7 As shown, the locations of each Store class and each Action class can be obtained in any way to generate a single data source. Among these, Figure 7 In this example, `Store1` represents one `Store` class, and `Store2` represents another `Store` class; `action1` represents one `action` class, and `action2` represents another `action` class. As a possible implementation, since many features of MobX, such as `@observable` and `@inject`, use the decorator pattern, this approach can also use the decorator pattern for location lookup, thus maintaining consistency in MobX's functionalities. A target decorator can be predefined. The decorator is essentially a function that is executed before the decorated class is initialized, allowing access to the decorated class itself. This enables obtaining the location of the decorated `Store` and `Action` classes before their instantiation, thus forming a single data source through unified processing. This single data source can be accessed by components.
[0058] That is, a target decorator can be set in advance and executed before each Store class and each Action class is executed; the location of each Store class and the location of each Action class can be obtained using the target decorator.
[0059] The pseudocode example for this process is as follows:
[0060] Optionally, when generating a single data source, for each Store class, attribute identifiers can be generated based on the location of that Store class; for each Action class, attribute identifiers can be generated based on the location of that Action class. The attribute identifier can be an attribute name. The specific method for determining the attribute identifier based on the address can be set according to actual needs. To facilitate subsequent determination of the corresponding location based on the attribute identifier while reducing storage space usage, a mapping relationship between attribute labels and locations can be pre-set. Based on a mapping relationship, the attribute identifier can be determined either based on the address or based on the attribute identifier. After obtaining the attribute identifiers for each class, the attribute identifiers are stored in a single data source to serve as the single data source.
[0061] With a single data source, when developers need to modify files, they can locate the target file's exact location based on this single data source and then perform modification operations on that target file. This further speeds up the process of finding the target file.
[0062] Currently, the timing and method of Store instantiation are uncontrollable. The program only instantiates a Store the first time a method or state within it is used. If a page needs to be dynamically displayed based on a specific state, and instantiation is not yet complete, it will cause delayed page updates. Furthermore, because instantiation is incomplete, error messages will not include sufficient information for troubleshooting, making debugging difficult for developers and hindering their ability to accurately and quickly locate the problem.
[0063] Large projects are likely to involve interactions between multiple Stores. To avoid uncontrollable timing and methods of Store instantiation, all Stores can be identified and a globally unique data source can be created. Then, the timing and methods of Store instantiation can be controlled based on this data source. Please refer to [link / reference]. Figure 8 , Figure 8 This is the third flow diagram illustrating the state management model optimization method provided in this application embodiment. In this embodiment, after step S130, the method may further include step S150.
[0064] Step S150: When the target project is initially started, at least a portion of the classes in the single data source are instantiated.
[0065] Optionally, during the initialization of the target project, all Store and Action classes can be found and instantiated all at once based on this single data source to control the instantiation timing. Alternatively, during the initialization of the target project, only some classes can be instantiated, while others can be loaded on demand.
[0066] As one possible implementation, to improve performance, frequently used classes can be instantiated at the beginning of the project, while less frequently used classes can be instantiated as needed. This can reduce lag in state updates during development and also improve performance. Please refer to... Figure 9 , Figure 9 for Figure 8 A flowchart illustrating the sub-steps included in step S150. In this embodiment, step S150 may include sub-steps S151 to S153.
[0067] Sub-step S151: Obtain the usage frequency of each type in the single data source.
[0068] The frequency of use for each type can be set manually by staff or obtained through other means.
[0069] Sub-step S153: Select at least one first target class from the single data source based on the usage frequency of each class.
[0070] Optionally, classes with a usage frequency greater than a preset frequency can be selected as the first target classes; alternatively, classes (including Store and Action classes) in the single data source can be sorted according to their usage frequency, and then a certain number of classes can be selected as the first target classes in descending order of frequency. The usage frequency of the first target classes is not less than the usage frequency of the unselected classes (i.e., classes not selected as the first target classes).
[0071] Sub-step S153: Instantiate the first target class.
[0072] Please refer to Figure 10 , Figure 10 This is the fourth flow diagram illustrating the state management model optimization method provided in this application embodiment. In this embodiment, after step S150, the method may further include step S160.
[0073] Step S160: When it is necessary to use the uninstantiated second target class, instantiate the second target class.
[0074] When using on-demand instantiation to improve performance, at the start of the project, the locations of all Store and Action classes can be located, and those that do not require on-demand loading can be instantiated. Classes that do require on-demand loading can be instantiated only when needed. For example, when accessing the `storeA` property of the `rootStore`, if the `storeA` property already exists, the result is returned directly. If the `storeA` property does not exist, the `rootStore` is dynamically instantiated. This functionality can be achieved using JavaScript object accessor properties. A pseudocode example is shown below:
[0075]
[0076] The embodiments of this application enable state management of a single data source that is loaded on demand. This technology can significantly improve several shortcomings of MobX in large projects mentioned above, ensuring the maintainability of large projects and avoiding structural chaos caused by state management. It can uniformly manage MobX state files, reduce the burden on developers by using an automatic lookup mechanism, and improve performance by implementing on-demand instantiation of the Store.
[0077] To perform the corresponding steps in the above embodiments and various possible methods, an implementation of the state management model optimization device 200 is given below. Optionally, the state management model optimization device 200 can adopt the above-described... Figure 4 The device structure of the electronic device 100 shown. Further, please refer to... Figure 11 , Figure 11 This is one of the block diagrams of the state management model optimization device 200 provided in this application embodiment. It should be noted that the basic principle and technical effects of the state management model optimization device 200 provided in this embodiment are the same as those in the above embodiments. For the sake of brevity, any parts not mentioned in this embodiment can be referred to the corresponding content in the above embodiments. The state management model optimization device 200 may include: a layered module 210 and a modification module 230.
[0078] The layered module 210 is used to divide the target project into Stores, Action, and Views layers. The storage scope of each layer is different. The Stores layer includes Store classes, which contain property files. The Action layer includes Action classes that indicate interaction logic, each containing at least one Action function. The Views layer includes components.
[0079] The modification module 230 is used to modify the target file corresponding to the received modification operation. The target file is either an attribute file or an Action function specified by the modification operation.
[0080] Please refer to Figure 12 , Figure 12 This is a second block diagram of the state management model optimization device 200 provided in this embodiment. In this embodiment, the state management model optimization device 200 may include a data source generation module 220.
[0081] The data source generation module 220 is used to: obtain the location of each Store class and the location of each Action class; and generate a single data source based on the location of each Store class and the location of each Action class.
[0082] Please refer to Figure 13 , Figure 13 This is a third block diagram of the state management model optimization device 200 provided in this embodiment. In this embodiment, the state management model optimization device 200 may further include an instantiation module 240.
[0083] The instantiation module 240 is used to instantiate at least a portion of the classes in the single data source when the target project is initially started.
[0084] The instantiation module 240 is also used to instantiate the second target class when it is necessary to use the uninstantiated second target class.
[0085] Optionally, the above modules can be stored in the form of software or firmware. Figure 4 The memory 110 shown is either stored in or embedded in the operating system (OS) of the electronic device 100, and can be used by... Figure 4 The processor 120 executes the program. Meanwhile, the data and program code required to execute the above modules can be stored in the memory 110.
[0086] This application also provides a readable storage medium storing a computer program thereon, which, when executed by a processor, implements the state management model optimization method described above.
[0087] In summary, this application provides a state management model optimization method, apparatus, electronic device, and readable storage medium. The target project is divided into Stores, Action, and Views layers, with different storage scopes corresponding to different layers. The Stores layer includes Store classes, which contain attribute files. The Action layer includes Action classes for indicating interaction logic, each containing at least one Action function. The Views layer includes components. Based on a received modification operation, the target file corresponding to the modification operation is modified, where the target file is the attribute file or Action function specified by the modification operation. This layered approach facilitates the management of the target project. When a file needs modification, the corresponding file can be searched within the storage scope of the layer to which the file belongs, and then modified. This method narrows the search scope and facilitates rapid modification of state data files or interaction logic.
[0088] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.
[0089] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.
[0090] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0091] The above description is merely an optional embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. A method for optimizing a state management model, characterized in that, The method includes: The target project is divided into Stores, Action, and Views layers, with different storage scopes for each layer. The Stores layer includes Store classes, which contain property files. The Action layer includes Action classes that indicate interaction logic, which contain at least one Action function. The Views layer includes components. The target decorator is executed before the Store class and Action class are executed; The location of each Store class and the location of each Action class are obtained using the target decorator; A single data source is generated based on the location of each Store class and each Action class. Based on the received modification operation, the target file corresponding to the modification operation is modified, wherein the target file is the attribute file or Action function specified by the modification operation.
2. The method according to claim 1, characterized in that, The process of generating a single data source based on the location of each Store class and each Action class includes: For each Store class, generate attribute identifiers for that Store class based on its location; For each Action class, generate attribute identifiers for that Action class based on its location; The attribute identifiers of each Store class and each Action class are stored in the data source to obtain the single data source.
3. The method according to claim 1, characterized in that, The method further includes: At the initial stage of the target project, at least a subset of classes from the single data source are instantiated.
4. The method according to claim 3, characterized in that, Instantiating at least a portion of the classes in the single data source includes: Obtain the usage frequency of each category in the single data source; Based on the usage frequency of each class, at least one first target class is selected from the single data source, wherein the usage frequency of the first target class is not less than the usage frequency of the unselected classes; Instantiate the first target class.
5. The method according to claim 3, characterized in that, The method further includes: When it is necessary to use an uninstantiated second target class, instantiate the second target class.
6. A state management model optimization device, characterized in that, The device includes: The layered module is used to divide the target project into Stores, Actions, and Views layers. Different layers correspond to different storage scopes. The Stores layer includes Store classes, which contain property files. The Actions layer includes Action classes that indicate interaction logic, each containing at least one Action function. The Views layer includes components. Before executing the Store and Action classes, a target decorator is executed. The target decorator is used to obtain the location of each Store class and each Action class. Based on the location of each Store class and each Action class, a single data source is generated. The modification module is used to modify the target file corresponding to the received modification operation, wherein the target file is the attribute file or Action function specified by the modification operation.
7. An electronic device, characterized in that, It includes a processor and a memory, the memory storing machine-executable instructions that can be executed by the processor, the processor executing the machine-executable instructions to implement the state management model optimization method according to any one of claims 1-5.
8. A readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the state management model optimization method as described in any one of claims 1-5.
Citation Information
Patent Citations
A client software development method and apparatus
CN109426492A
Method for managing files in flash memory of mobile terminal
CN1627272A