Use plug-ins and plug-ins in sencha applications

Original article: Using plugins and mixins in your sencha apps

Overview

When extending the functions of a framework class, new functions are usually directly written to the derived class. However, if the same function is required to exist in multiple components, the most effective way is to define it as a plug-in or plug-in. Plug-ins and INS are classes used to add additional functions to other classes. In this article, we will introduce what these classes are, the differences between them, and how they work. At sencha fiddle, we have prepared some examples to demonstrate these concepts.

What is a plug-in and how to use it?

The plug-in is a class used for Ext. component (or derived from ext. component class) to add or modify the function. Like other classes, the plug-in must use Ext. the define method is defined and extended to Ext. plugin. abstract.

 // Simple example showing how to define a plugin// extending form Ext.plugin.Abstract Ext.define(‘Fiddle.plugin.SamplePlugin‘, {    extend: ‘Ext.plugin.Abstract‘,    alias: ‘plugin.sampleplugin‘,     init: function (cmp) {        this.setCmp(cmp);    }}); 

Interestingly, it is a class that must contain the init (CMP) method in the class you define, because the method needs to be called before component rendering through the component constructor. The plug-in can be referenced and set through the "pulugins" configuration item of the component, it can be set in the "example" of the original custom class body of the custom component or in the "example" of the configuration object during initialization.


When you create a plug-in from Ext. plugin. Abstract extension, the init, destroy, enable, and disable methods are received by default. The following describes how to use these methods effectively.

Init

Method init is the plug-in entry. It allows the plug-in to insert and interact with the component before rendering the component. In this phase, the plug-in needs to store the reference of the customer component so that the plug-in-definition method can easily reference it. Ext. plugin. Abstract provides two accessors to Reference Components Using the plug-in.

• Setcmp: In Init (CMP), you can use setcmp (CMP) to initialize the settings of the referenced component. In this way, you can reference the component through the getcmp method in the plug-in.
• Getcmp: This accessors method can be used by other methods in the plug-in.
  

The getcmp method is particularly important because the plug-in and its method work within the scope of the plug-in. That is to say, this references the plug-in itself rather than the plug-in components. When the plug-in needs to interact with its owner's components, the access method (getter) can be used to access the customer components.

The init method can set the plug-in logic when init is processed. You may need to set the plug-in logic again after HTML Rendering of its owner component. For example, a drag-and-drop area can be created only after the hmtl of the component is rendered to the Dom. In this case, you need to listen to the afterrender event of the customer component and set the component function at this time. [Example]

Destroy

The destroy method of the plug-in is called when the component is destroyed. Any class instance created through the plug-in (such as drag and drop, keyboard navigation, etc.) needs to be destroyed programmatically at this time. Any convenient attribute set to the customer component instance must also be set to null or deleted. [Example]

Enable/disable

The enable method is only used to set the disabled attribute of the plug-in to false, while the disable method sets the disabled attribute to true. You can extend this function when creating your own plug-in. You can also check the disabled status before processing to determine whether to use any plug-in logic. As you want, you can also use them further, depending on how to enable or disable the plug-in as needed. [Example]

Get references to the plug-in

In use, because the method defined in the plug-in is a plug-in rather than a component, You need to obtain a reference from the component and return a plug-in to call its method. Alternatively, it is more convenient to bind the plug-in method to the component. [Example]

When defining a plug-in class, it is very useful to give the plug-in alias such a prefix: alias: plugin. mypulugin. When customer components use plug-ins, you can easily set the plug-ins by type:

plugins: [{    ptype: ‘myplugin‘}] 

The alias allows you to use the findplugin method of the component to search for plug-in references. For example:

var thePlugin = owningClass.findPlugin(‘myplugin‘);

Finally, you can use the getplugin method and pluginid of the component to reference the plug-in.

plugins: [{    ptype: ‘myplugin‘,    pluginId: ‘myPluginId‘;}] var thePlugin = owningClass.getPlugin(‘myPluginId‘);

What is mixed in and how to use it?

A class is used to add functions to a class. However, it differs from plug-ins in the following ways:

1. You can add functions to any class, And the plug-in can only be used for the Ext. component class.
2. As long as the mixins configuration item is used in the class definition, the plug-in can be defined in the class or the instance of the class.
3. Blending can be a general design for any class they want to mix in the function (see Ext. Mixin. observable for the fire/Listen function of any class to mix in the event ). That is to say, it can more clearly limit application access to classes of a specific category (see Ext. Panel. pinnable is designed to only be mixed into panel classes ).
4. The method defined in the inner is applied to the prototype of the target class.
   

When you create an instance that uses the mixed class, you can directly call any mixed definition method in the class. The scope of this in these methods is the class itself. [Example] it is possible that the method defined in the blending process has the same name as the method of the class itself. In this case, the blending method will not be copied to the prototype of the target class. In this case, the method that calls this class will always be the original defined method.

To call a mix-in method with the same name, you must obtain the reference from the class to which it belongs, and then directly call the mix-in method. When you directly call the mixed method, its scope will be mixed into the class, so this will point to the mixed class itself [Example ]. As shown in the following example, if there is a destroy with the ID util mixed in, the destroy method defined in the mixed in will be called as follows:

this.mixins.util.destroy.call(this);

Define your own mix

Although we recommend that you use Ext. Mixin extension to define mixing, you can also use Ext. Define. The main benefit of defining Ext. Mixin by extension is that you can define a "hook" when defining a mixed class ". Hooks are defined as methods that are mixed into the class. They are automatically called before or after receiving the corresponding methods of the class. For example, to ensure that the afterdestroy method is called after the class is destroyed, you can use the after HOOK:

mixinConfig: {    after: {        destroy: ‘afterDestroy‘    }}

For more details about how to use the before, after, on, and extended hooks, see the top description of the Ext. Mixin API documentation.

Use your own mix

The first choice for self-mixing is to use the complete class name in the array. The mixed classes in the configuration item mixins are processed in the order listed in the array.

mixins: [    ‘My.utility.MixinClass‘  // "util" is used to reference the mixin] 

The object syntax (see option 2 below) provides backward compatibility, but it is not recommended because the key name does not conform to the ID definition of the mixed class.

Obtain the reference of the mixed class

You may need to obtain the reference of mixed classes from the class instance. This can be referenced by the mixins attribute of the instance to which the class belongs, and then by the mixed ID (for example, this. mixins. util ). We recommend that you always set a unique ID for the mixed classes when defining the mixed classes. You can set or determine the IDs of the mixed classes in the following three ways:

1. If it is not extended to Ext. minxn, you can set the mixinid configuration item in the class body of the mixed class. For example:
   

   mixinId: ‘util‘

   
   If the mixed class is extended from Ext. Mixin, you can set the ID in the mixinconfig configuration item:
   

   mixinConfig: {    id: ‘util‘}

   
   
   
   
2. Mixins configuration items can also be regarded as an object in East Asia and define a key for each mixed class. For example:
   
   

   mixins: {    util: “My.utility.MixinClass”} 

   
   
   
   
3. If you do not use the above method to set the ID, you can also use the complete Class Name of the mixed class:
   
   

   Ext.define(‘My.utility.MixinClass‘);var utilMixin = owningClass.mixins[‘My.utility.MixinClass‘];

   
   

When to use plug-ins or mix in

Now that you have learned about plug-ins and INS, when should you use plug-ins and ins when defining classes? Because the same functions may not be able to write to any type, you need to consider how to use these functions in the application. The plug-in is more flexible because it can be used on the instance and only adds overhead to the instance. However, if the function is for all classes, the built-in definition logic is more efficient, because the plug-in example is not created when each instance is created.

Seth lemmons
Seth lemmons is a senior engineer on the sencha support team. He has experience in ext JS, sencha touch, and software development. He lives in Boise, Idaho with his wife and ~ 200 K other very nice people. Look for slemmon on the forums.

Use plug-ins and plug-ins in sencha applications