behaviors

Behaviors are features used for code sharing between components, similar to "mixins" or "traits" in some programming languages.

Each behavior can contain a set of properties, data, lifecycle functions, and methods. W hen a component references it, its properties, data, and methods are merged into the component, and lifecycle functions are called at the corresponding time. Each component can reference more than one behavior, or the behavior can refer to another behavior.

Refer to the Behavior reference documentation for detailed parameter meaning and use.

Used in components

When components are referenced, list them one by one in the behaviors definition segment.

Code example:

// 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 example above, my-behavior was added to the my-component component definition,

The my-behavior structure is:

• Property: myBehaviorProperty
• Data field: myBehaviorData
• Method: myBehavior Method
• Life cycle functions: attached, create, ready

This will make the final structure of my-component:

• Properties: myBeaviorProperty, myProperty
• Data fields: myBehaviorData, myData
• Methods: myBehavior Method, myMethod
• Life cycle functions: attached, create, ready

When a component triggers a life cycle, the above example lifecycle function is executed in the following order:

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 Refer to the coverage and combined rules of the same field.

Covering and combined rules of the same name

Components and it can contain the fields of the same name in the BEHAVIOR that it references, the processing methods for these fields are as follows:

• If there is a property with the same name or method: If the component itself has this property or method, the component's property or method overrides the property or method of the same name in the behavior; , the rule is: Parent behavior overrides a property or method with the same name in child behavior.
• If there are data fields with the same name: If the data fields with the same name are all object types, object merges are performed, and the rest of the data overrides, overwriting the following rules: components and parent behaviors, child behaviors, and back behaviors, and forward behaviors. (High priority coverage low priority, the largest priority is the highest priority)
• Lifecycle functions are not overridden by each other, but are called one by one at the corresponding trigger time: for different lifecycle functions, follow the order in which component lifecycle functions are executed, follow the following rules for the same lifecycle function: behavior takes precedence over component execution, child behavior takes precedence over parent behavior execution, forward behavior takes precedence over back behavior execution, and if the same behavior is referenced multiple times by a component , it defines a lifecycle function that is executed only once.

Code example:

Preview the effect in the developer tool

Built-in behaviors

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

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

In the example above, wx://form-field represents a built-in behavior that makes this custom component behave like a form control.

Built-in behavior tends to add some properties to components. In the absence of special instructions, a component can override these properties to change its type or add observer.

wx://form-field

Make custom components behave like form controls. The form component recognizes these custom components and returns the component's field name and its corresponding field value in the submit event.

Detailed usage and code samples are visible: form component reference documentation

wx://form-field-group

Support starts with base library version 2.10.2.

Enables the form component to recognize all form controls within this custom component.

Detailed usage and code samples are visible: form component reference documentation

wx://form-field-button

Support starts with base library version 2.10.3.

Makes the form component recognize the button inside this custom component. If there is a button with form-type set inside the custom component, it will be accepted by the form outside the component.

Detailed usage and code samples are visible: form component reference documentation

wx://component-export

Support starts with base library version 2.2.3.

Make custom components support export definition segments. This definition segment can be used to specify the return value when a component is called by selectComponent.

Detailed usage and code examples are available: SelectComponent reference documentation