# behaviors

behaviors Is a feature used for code sharing between components, similar to the “mixins” or “traits”。

Each behavior You can include a set of properties, data, life periodic functions, and methods.When a component refers to it, its properties, data, and methods are incorporated into the component, and a life-periodic function is invoked at the appropriate time. Each component may refer to multiple behaviorbehavior You can also refer to other behavior

Please refer to the detailed meaning and use of parameters Behavior Reference documents

# Components are used in

When a component is referenced, the behaviors You can list them individually in the definition section.

Code example:

{% Minicode ('Yq4RqCm87thO') %}

// my-component.js
var myBehavior = Require('my-behavior')
Component({
  behaviors: [myBehavior],
  properties: {
    myProperty:  {
      type: String
    }
  },
  data: {
    myData: 'my-component-data'
  },
  created: function () {
    console.log('[my-component] created')
  },
  attached: function () { 
    console.log('[my-component] attached')
  },
  ready: function () {
    console.log('[my-component] ready')
  },
  methods: {
    myMethod: function () {
      console.log('[my-component] log by myMethod')
    },
  }
})

In the above example, my-component Into the component definition my-behavior

and my-behavior Structured as:

  • Properties:myBehaviorProperty
  • Data Fields:myBehaviorData
  • Method:myBehaviorMethod
  • Life periodic function:attachedcreatedready

This will make my-component The final structure is:

  • Properties:myBehaviorPropertyMyProperty
  • Data Fields:myBehaviorDatamyData
  • Method:myBehaviorMethodmyMethod
  • Life periodic function:attachedcreatedready

When a component triggers a lifecycle, the order of execution of the life periodic functions in the example above is:

  1. [my-behavior] created
  2. [my-component] created
  3. [my-behavior] attached
  4. [my-component] attached
  5. [my-behavior] ready
  6. [my-component] ready

Detailed Rules Reference Covering and Combining Rules for Fields with the Same Name

# Covering and Combining Rules for Fields with the Same Name

Component and what it refers to behavior Can contain fields with the same name. These fields are handled as follows

  • If there are properties with the same name (properties) Or method (methods):
    1. If the component itself has this property or method, the component's property or method overrides the behavior A property or method with the same name in
    2. If the component itself does not have this property or method, the behaviors Field that defines the last behavior Overrides the preceding property or method with the same name
    3. in 2 If there is a nested reference behavior Case, the rule is:Cited by behavior cover The quoted behavior Property or method with the same name in the.
  • If there is a data field with the same name (Data):
    • If the data fields with the same name are all object types, object merge is performed
    • The rest of the data is overwritten, and the overwriting rules are: Cited by behavior > The quoted behaviorRearward behavior > Forward behavior(The highest priority overrides the lowest priority, and the largest is the highest priority).
  • Life periodic function and observers They do not override each other, but are called individually at the corresponding trigger time:
    • Follow the execution order of component life periodic functions for different life periodic functions
    • For the same kind of life periodic function and the same field observers , follow the following rules:
      • behavior Takes precedence over component execution
      • The quoted behavior Priority to Cited by behavior implement
      • Forward behavior Priority to Rearward behavior implement
    • If the same behavior Is referenced many times by a component, it defines a life periodic function and observers It will not be repeated.

Code example:

{% Minicode ('CI5omDmT7khB') %}

# built-in behaviors

Custom components can be defined by referencing the built-in behavior To get some of the behavior of the built-in components.

Component({
  behaviors: ['wx://form-field']
})

In the above example, wx://form-field Represents a built-in behavior , which causes this custom component to behave like a form control.

built-in behavior Some properties are often added to components. Without special instructions, a component can override these properties to change its type Or add observer

# wx://form-field

Causes custom components to behave like form controls. form Components can identify these custom components and define them in the submit Event returns the field name of the component and its corresponding field value.

Detailed usage and code examples can be seen:form Component Reference Documentation

# wx://form-field-group

From the base library version 2.10.2 Start providing support.

send form Component recognizes all form controls inside this custom component.

Detailed usage and code examples can be seen:form Component Reference Documentation

# wx://form-field-button

From the base library version 2.10.3 Start providing support.

send form Component can be identified to the button If the custom component has internal settings form-type of button , which will be replaced by components outside the form Accepted.

Detailed usage and code examples can be seen:form Component Reference Documentation

# wx://component export

From the base library version 2.2.3 Start providing support.

Enable custom component support export Definition paragraph. This definition segment can be used to specify that the component is selectComponent The return value when called.

Detailed usage and code examples can be seen:selectComponent Reference documents