Foreword
this article is based on Api13
I have developed a refresh library before, which is based on the V1 version Decorator. However, the voice of V2 version is still relatively high recently. There are several messages on github. I originally planned to have time to adapt again at the end of the month. I simply put it on the agenda directly.
In fact, I plan to modify the version of V1 directly. I found that the amount of changes is still relatively large. I cannot modify V1 in order to upgrade V2, which makes V1 version unavailable to users. In this way, the loss outweighs the gain. I just agree with the government and come out with a V2 version.
If you plan to use V2 version, you can directly rely on V2 version. Except for dependency and package guide, other usage methods are exactly the same.
Central Warehouse Address: https://ohpm.openharmony.cn/#/cn/detail/@abner%2Frefresh_v2
method 1: in the Terminal window, run the following command to install the third-party package. DevEco Studio automatically adds the third-party package dependency to the project oh-package.json5.
Suggestion: Execute the command under the module path used.
ohpm install @abner/refresh_v2
Method 2: Set the three-party package dependency in the project oh-package.json5. The configuration example is as follows:
"dependencies": { "@abner/refresh_v2": "^1.0.0"}
the dependency is changed from refresh to refresh_v2.
V1 and V2 are mainly different
The difference here does not mean that the refresh Library is different, but the decorators of the two versions are different. First of all, it can be thought that the official developers must not have designed it well at the beginning, while the V1 version is preconceived and optimized on the basis of V1, which has too much influence. Finally, a V2 version of decorator was built, isolated from the previous version, which is also convenient for subsequent maintenance and optimization.
In the previous article, several decorators of V2 version were also introduced. It can be found that V2 version is optimized and powerful on top of V1 version, such the @ Monitor decorator can directly Monitor whether an element has changed, which is extremely convenient for targeted monitoring.
Generally speaking, V2 version decorator enhances the observation capability to the data itself. The state variable is independent of UI. Changing the data will trigger the update of the corresponding view, support the deep observation and deep monitoring of the object, and the deep observation mechanism does not affect the observation performance. It also supports the accurate update of attribute level in the object and the minimum update of elements in the array. Similarly, it has high usability and strong expansibility, explicit input and output in the component is conducive to componentization.
V1 and V2 migration checklist
| V1 Decorator Name | V2 Decorator Name | description |
|---|---|---|
| @Observed | @ ObservedV2 | indicates that the current object is observable. But the two capabilities are not the same. |
| @Track | @trace | the V1 decorator @ Track is for accurate observation. If it is not used, it cannot accurately observe class attributes.The attributes decorated with V2 @ Trace can be accurately tracked and observed. |
| @Component | @ ComponentV2 | @ Component is a custom Component decorator used with the V1 state variable.@ ComponentV2 is a custom component decorator used with V2 state variables. |
| @State | no external initialization: @ Localexternal initialization Once: @ Param @ Once | @ State and @ Local are similar concepts of data sources. They can be migrated directly when external initialization is not required. |
| @prop | @param | @ Prop and @ Param are similar concepts of custom component parameters. |
| @link | @param@Event | @ Link is a two-way synchronization implemented by the framework itself. V2 developers can use @ Param @ Event to implement two-way synchronization. |
| @ObjectLink | @param | directly compatible, @ ObjectLink needs to be initialized with an instance of the class decorated with @ Observed, @ Param does not have this restriction. |
| @Provide | @provider | compatible. |
| @Consume | @Consumer | compatible. |
| @Watch | @Monitor | @ Monitor is used to Monitor changes in V2 state variables. When used with @ Trace, it has the ability to Monitor deeply. When the state variable changes multiple times in one event, only the final result is used to determine whether to trigger the @ Monitor event. |
| LocalStorage | global @ ObservedV2 @ Trace | compatible. |
| AppStorage | AppStorageV2 | compatible. |
| Environment | call the Ability interface to obtain system environment variables. | Environment to obtain Environment variables and AppStorage coupling. In V2, you can directly call the Ability interface to obtain system environment variables. |
| PersistentStorage | PersistenceV2 | PersistentStorage and AppStorage are coupled. PersistenceV2 can be used independently. |
Adapted
In fact, the best solution is that V2 version and V1 version are completely isolated, that is, if V2 is used, V2 will be used uniformly. After all, V2 is more powerful. Of course, I also suggest here that if you are a new project or a new function, use V2 completely.
For some old projects, there are already a large number of V1 decorator codes, allowing everyone to migrate at one time. This is a bit unrealistic, but the government also supports mixed use.
However, when mixed use, attention should be paid:
Custom components cannot be mixed, otherwise the compilation will report an error. The so-called mixed use means that your V1 custom component uses V2 decorator and V2 custom component uses V1 decorator.
If there is no variable transfer between components, different versions of custom components can be used regardless of V1 version or V2 version, including import third-party Component or ComponentV2 decorated custom components.
When there is variable transfer between components, V1 variables are transferred to V2 custom components with the following restrictions:
variables in V1 that are not decorated with decorators (later called ordinary variables):V2 can only be received with @ Param.
Variables decorated by decorators in V1 (hereinafter referred to as state variables):V2 can only be received through @ Param decorators, and is limited to simple types of data such as boolean, number, enum, string, undefined, and null.
- When there is variable transfer between components, V2 variables are transferred to V1 custom components with the following restrictions:
variables in V2 that are not decorated with decorators (hereinafter referred to as ordinary variables): If V1 uses decorators to decorate the received data, it can only use @ State, @ Prop, and @ Provide.
Variables decorated by decorators in V2 (hereinafter referred to as state variables): If V1 uses decorators to decorate the received data, the built-in data types: Array, Set, Map, and Date are not supported.
Related Summary
if you are writing a new project, it is recommended to start V2 decorator directly. Even for existing projects, V2 should be the main module for new modules.
Top comments (0)