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: 
Official posture:

> 
> 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.
> 
> 
> 

<http://docs.sencha.com/extjs/4.2.2/#!/api/Ext.AbstractComponent-cfg-itemId>

So you can use itemId like this it is not prohibited.

There are at least two reasons, why it's a bad practice:

1. You can forget about this behaviour after some time
2. Somebody in your team or another programmer, who will work with your code later, can use this component and face with a conflicts.

A better solution you can make is to move `itemId` definition to a config block with a default value. In that case other user can easily change this property.
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.