Question: **Is it a bad practice to have the itemId configuration on the class definition (instead of instantiation)?**

**Is there some official documentation that backs it up or is it just a matter of opinion?**

Or maybe there is some logic that I'm missing that makes it evident that this is a bad practice.

```
Ext.define('SomeApp.view.SomeFolder.MySpecialComponent',{
    extend: 'Ext.panel.Panel',
    itemId: 'specialComponent'
    // ...
});

```

Because I do understand that if there is more than 1 instance and I use the itemId as a selector I would get both instances. But let's say I know I won't have more than 1 instance at a time and also let's say that the instantiation can occur in 3 different places, I don't want to add itemId's in those 3 different places and I certainly don't want those itemId's to be different.

So is there an official posture about using itemId configuration at class definition?

Answer: 
From the docs of [Ext.AbstractComponent.itemId](http://docs.sencha.com/extjs/4.2.3/#!/api/Ext.AbstractComponent-cfg-itemId):

> 
> An itemId can be used as an alternative way to get a reference to a component when no object reference is available. Instead of using an id with Ext.getCmp, use itemId with Ext.container.Container.getComponent which will retrieve itemId's or id's. **Since itemId's are an index to the container's internal MixedCollection**, the itemId is scoped locally to the container -- avoiding potential conflicts with Ext.ComponentManager which requires a unique id.
> 
> 
> 

Since `itemId` is used as an index, it must be unique within the container. If you added two instances of any component which have the same itemId to the same container, the second one would actually overwrite the first one.

You can observe this behaviour in this fiddle: <https://fiddle.sencha.com/#fiddle/m2n>

Especially considering this fact, in my opinion it does not really make sense to specify the itemId in the class definition directly, because:

* If you wanted to add more than 1 instance of this component to the same container, it simply would not work (unless you overwrite the itemId again upon instantiation).
* If this is not the case then you might want to consider not specifying an itemId at all. Instead you could get the instance by its xtype:

```
// assuming the xtype is 'specialcomponent'
container.query('specialcomponent')

```
* You'd actually hide the itemId at instantiation time, making it more difficult to understand where it comes from

```
var ct = Ext.create('Ext.container.Container', {
    items: [{
        // not clear that this will have itemId 'specialComponent'
        xtype: 'specialcomponent'
    },{
        xtype: 'panel',
        itemId: 'somePanel'
    }];

```
Adding to @matt and @Nikolay's answers - 

> 
> Is it a bad practice to have the itemId configuration on the class
>  definition (instead of instantiation)?
> 
> 
> 

It is advisable not to. 
It's true that multiple components with the same itemId can exist so as long as they are in different containers (*even a child container can contain a component with the same itemId as one present in the parent*). However, the problem is that we've to be cautious about basing our logic on unique itemIds. If we follow unique itemId for all instances then we can easily do component queries with just the unique itemId and be sure that the component that we want is the one always getting returned - this will not be the case in the case where we introduce duplicate itemIds in the system and we'll have to always make sure that the correct query selector is passed. 
Unless, definitely absolutely unavoidably required. I'd go with unique itemId.