• UID623
  • Fans4
  • Follows1
  • Posts72

[Share][Weex Tips] Intelligent use of Weex lifecycle

More Posted time:Oct 20, 2016 9:53 AM
• First, we recommend you read the Official Documents on definition of components, which introduces the lifecycle.
• In Weex projects, there is a dedicated section of Issue describing Weex lifecycles. Several clear diagrams are provided in the section. I will just illustrate the usage here.
The link above will give you a clear structure of the Weex lifecycle. It can be further summarized into the figure below:

Note: Only the new version of JS Framework (>0.15.6) supports destroyed lifecycle.
Usage of lifecycle
  module.exports = {
    data: {},
    methods: {},

    init: function () {
      console.log(’Triggered after initialization of internal variables and the event function is added’);
    created: function () {
      console.log(’Triggered after data binding and before template compilation’);
    ready: function () {
      console.log(’Triggered after template compilation and Virtual DOM generation');
    destroyed: function () {
      console.log(’Called at page destruction');

Pay attention that the lifecycle functions init, created, ready and destroyed are of the same level in attribute with data and methods, so do not put init, created, ready and destroyed functions in methods. Although this usage is supported in the current version, later versions may discard this usage.
In addition, it is not advised to define other attributes on the root objects. Data should be put in the data attribute, and the custom methods in methods. The execution environment (this) of methods is the VM object of the current component. For interfaces, refer to: Instance Apis.
The init method
When the init method is executed, the internal variables have just been initialized and the event function just added. At this time, data binding is not executed yet, and Virtual-DOM is not created. So you can neither obtain data in data through this, nor call methods defined in methods, or obtain Virtual-DOM nodes.
You can initialize some internal variables in this method, or bind some custom events.
The created method
The created method has a slightly confusing name, as it may make you think all the nodes have been created. But in fact, the method just completes the data binding and template compilation hasn't started yet. At this time, you can operate on data through this, or call methods in methods. But you cannot obtain Virtual-DOM nodes.
Since you haven’t started to execute node rendering, you can modify the data in data in the created method (such as some attributes for dynamic computing). The modifications at this time won't trigger additional rendering.
The ready method
When ready starts to be executed, it means the rendering of the current component has been completed. This process is triggered following a bottom-up approach. It will first execute the ready method of the sub-component. That is to say, when the parent component is executing the ready method, the rendering for all the sub-components has been completed, and the respective ready methods for each sub-component have been executed.

At this time, you can obtain Virtual-DOM of the node through this.$el(id), or obtain the VM instance of the sub-component through this.$vm(id).
However, you need to be careful with operations on data in the ready method and avoid frequent value assignment. At this moment the data and UI binding has been completed, and every value change may trigger partial-page re-rendering. It is recommended that you get the values subject to frequent changes, and assign the values together after the operations are executed and completed.
module.exports = {
  data: {
    count: 0
  ready: function () {
    var count = this.count;
    for (var i = 0; i < 999; i++) {
      count += Math.random();
    this.count = count;

As shown in the code, first, get the value of this.count before modifying it. After the operation execution is complete, assign the value back. If you set the value of this.count directly in the loop body, the page will trigger 999 partial-page refreshes, which may make the page get stuck.
For complicated data objects, we also recommend you update data in the approach of getting values > making modification > assigning values.
The destroyed method
The destroyed method is called for destroying components (usually at page navigation). Similar to the ready method, the destroyed method also follows a bottom-up approach, that is, the destroyed methods of sub-components are triggered first and then the destroyed method of the parent component. In addition, the framework will first execute the destroyed method defined by the developer, and then erase the internal attributes.
If you have added some global attributes or attributes for this, it is recommended that you manually erase them in the destroyed method to avoid memory leakage.
Other suggestions
It is never recommended to obtain internal attributes of VM and Virtual-DOM. This part of data is transparent to the developer and is likely to be modified during version iteration.
If you have special development requirements, you can contact the Weex development group for solutions.