Although xtype has been around since Ext 2.0, there is still a lot of confusion on what it is, how can it be used and what it is good for. The clarification in this article gives you all information you need to use xtype (and other [a-z]types) effectively.
Definition
For example, your class has the name MyApp.view.MyGrid. This is the normal class name that you use when you need to create the class. For example:
var myGrid = Ext.create('MyApp.view.MyGridView',{
title:'My Grid'
});
In addition to class name you can give your class an alias this way:
Ext.define('MyApp.view.MyGridView',{
extend:'Ext.grid.Panel'
,alias:'widget.mygrid'
});
OK, got it. But what it is good for?
The first, simplest but valuable benefit is that you do not need to type probably long class names, but you can use short(er) aliases when you need to use the class. Imagine that we need to use the above class in a layout.
Without alias, we need to type:
Ext.create('Ext.container.Container',{
layout:'vbox'
,items:[
Ext.create('MyApp.view.MyGridView',{
// config
})
]
});
and with alias, we type:
Ext.create('Ext.container.Container',{
layout:'vbox'
,items:[{
xtype:'mygrid'
// config
}]
});
The latter is about 20 keystrokes less than the former one. Now imagine that you need to use your classes hundreds of times in bigger applications. It is obvious that xtype save a considerable amount of typing not speaking about reducing the risk of typos in long names.
Second, also very valuable benefit is that Ext.create instantiates the class unconditionally, whether it is needed or not. You can have many views, tabpanels or card layouts in a big application that the user may never click on, or very rarely.
In other words, some of the defined classes never to be instantiated, or they can wait until the user needs them. Thus, xtype can save the memory, what is not very important in modern computers because instantiated Ext/Touch classes do not eat gigabytes.
What is more important, the application startup time can be improved with xtypes, and that’s worth more. The faster, the better.
The last benefit I want to mention, and this is really important, is a greatly improved code readability and maintainability as well. Code is not just written once and forgotten when it works, but it is read, debugged and modified by many developers so everything that makes it shorter, nicer and easier to understand counts.
Other types
We have been speaking about components, or widgets so far however alias can be assigned to almost any class type.
Plugins
To define:
Ext.define('Ext.saki.grid.Search',{
extend:'Ext.AbstractPlugin'
,alias:'plugin.saki-gms'
});
To use:
Ext.create('Ext.grid.Panel',{
plugins:[{
ptype:'saki-gms'
// rest of config
}]
});
Proxies
To define:
Ext.define('MyApp.proxy.CustomProxy',{
extend:'Ext.data.proxy.Server'
,alias:'proxy.myproxy'
});
To use:
Ext.define('MyApp.model.MyMode',{
extend:'Ext.data.Model'
,fields:[...]
,proxy:{
type:'myproxy'
}
});
… and so on
You can define aliases for readers, writers, stores, layouts, features, etc.
Alias Synonyms
There can be more than one alias defined for a class name. That can be useful for backwards compatibility, or other possible purposes. To assign a class more aliases, we just use an array of strings instead of a single string.
Ext.define('Ext.saki.grid.Search',{
extend:'Ext.AbstractPlugin'
,alias:['plugin.saki-gms', 'plugin.ux-gms']
});
Recommendation
Although Ext allows to use word xtype during the class definition, I strongly advice against it. It is just good to know when we assigning the alias and when we are actually using it.
Ext.define('MyApp.view.MyGridView',{
extend:'Ext.grid.Panel'
,xtype:'mygrid' // do not use in Ext.define
,alias:'widget.mygrid' // DO USE this
});
Conclusion
Use aliases, xtypes, ptypes, ftypes whenever you can mainly for the sake of your code quality. Of course, there may be situations when you have to instantiate a class directly with Ext.create but more often than not aliases shall do.
- Ext, Angular, React, and Vue - 27. June 2019
- The Site Resurgence - 11. February 2018
- Configuring ViewModel Hierarchy - 19. June 2015