Clever Geek Handbook

Extjs itemId in class definition

Is it wrong to have the itemId configuration in the class definition (instead of instantiating it)?

Is there any official documentation that supports it or is this just a question?

Or maybe there is some logic that I am missing, making it obvious that this is bad practice.

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

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

So, is there an official position on using the itemId configuration when defining a class?

+3


source to share


3 answers


From the Ext.AbstractComponent.itemId docs :

ItemId can be used as an alternative way to get a reference to a component if an object reference is not available. Instead of using id with Ext.getCmp, use itemId with Ext.container.Container.getComponent which will retrieve the itemId or id. Because itemId is the index of the container's internal MixedCollection , itemId is localized locally in the container - avoiding potential conflicts with the Ext.ComponentManager, which requires a unique identifier.

Since it is itemId

used as an index, it must be unique within the container. If you added two instances of any component that have the same ItemId to the same container, the second will actually overwrite the first.



You can observe this behavior in this script: https://fiddle.sencha.com/#fiddle/m2n

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

  • If you want to add more than one instance of this component to the same container, it simply won't work (unless you overwrite itemId again after instantiating).

  • If this is not the case, you may need to not include itemId at all. Instead, you can get an instance using xtype:

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

  • You are actually hiding the itemId during instantiation making it difficult to understand where it is coming from

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


source


Official position:

ItemId can be used as an alternative way to get a reference to a component if an object reference is not available. Instead of using id with Ext.getCmp, use itemId with Ext.container.Container.getComponent which will retrieve the itemId or id. Because itemId is the index of the container's internal MixedCollection, the itemId binds to the container locally - avoiding potential conflicts with the 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 as it is not forbidden.



There are at least two reasons why this is bad practice:

  • You can forget about this behavior after a while
  • Someone on your team, or another programmer who will later work on your code, might use this component and run into conflicts.

The best solution you can make is to move the definition itemId

into a config block with a default value. In this case, another user can easily change this property.

+1


source


Adding to @matt and @Nikolay answers -

Is it bad practice to have an itemId configuration in a class definition (instead of an instance)?

It is advisable not to do this. It is true that multiple components with the same itemId can exist as long as they are in different containers (even a child container can contain a component with the same itemId as the one in the parent). The problem, however, is that we have to be careful about basing our logic on unique itemIds. If we follow a unique itemId for all instances, then we can easily execute component requests with only a unique itemId and be sure that the one we need is always returned - this will not be the case when we introduce duplicate itemIds in system, and we must always ensure that the correct query selector is passed. If, of course, absolutely inevitably required. I would go with a unique itemId.

0


source






More articles:


All Articles