Extjs itemId в определении класса

Question

Неплохая практика иметь конфигурацию itemId в определении класса (вместо создания экземпляра)?

Есть ли какая-то официальная документация, подтверждающая его или это просто вопрос мнения?

Возможно, есть какая-то логика, которую я пропускаю, что делает очевидным, что это плохая практика.

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

Потому что я понимаю, что если есть больше чем один экземпляр, и я использую Itemid как селектор я хотел бы получить оба экземпляра. Но скажем, я знаю, что я не буду иметь более одного экземпляра за раз, а также скажу, что создание экземпляра может происходить в трех разных местах, я не хочу добавлять itemId в эти 3 разных места, и я, конечно, не хотите, чтобы те itemId были разными.

Итак, есть официальная позиция об использовании конфигурации itemId при определении класса?

Answer 1

Из документов из Ext.AbstractComponent.itemId:

ItemId может быть использован в качестве альтернативного способа, чтобы получить ссылку на компонент, когда нет ссылки на объект не доступен. Вместо использования id с Ext.getCmp используйте itemId с Ext.container.Container.getComponent, который будет извлекать элементы itemId или id. Поскольку itemId является индексом внутреннего MixedCollection контейнера, itemId локально локализуется в контейнере - избегая потенциальных конфликтов с Ext.ComponentManager, для которого требуется уникальный идентификатор.

С itemId используется как индекс, он должен быть уникальным в контейнере.Если вы добавили два экземпляра любого компонента, у которого один и тот же элемент itemId, в тот же контейнер, второй будет фактически перезаписывать первый.

Вы можете наблюдать это поведение в этой скрипкой: https://fiddle.sencha.com/#fiddle/m2n

Особенно учитывая этот факт, на мой взгляд, не имеет смысла, чтобы указать Itemid в определении класса непосредственно, потому что:

• Если вы хотите добавить более одного экземпляра этого компонента в один и тот же контейнер, он просто не будет работать (если вы не перезапишете itemId снова после создания экземпляра).

• Если это не так, вам может потребоваться не указывать itemId вообще. Вместо того, чтобы вы могли получить экземпляр его xtype:

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

• Вы действительно хотите скрыть Itemid во время создания экземпляра, что делает его более трудно понять, откуда приходит

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

Answer 2

Официальная позиция:

ItemId может быть использован в качестве альтернативного способа, чтобы получить ссылку на компонент, когда нет ссылки на объект не доступен. Вместо использования id с Ext.getCmp используйте itemId с Ext.container.Container.getComponent, который будет извлекать элементы itemId или id. Поскольку itemId является индексом внутреннего MixedCollection контейнера, itemId локально привязывается к контейнеру - избегая потенциальных конфликтов с Ext.ComponentManager, для которого требуется уникальный идентификатор.

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

Таким образом, вы можете использовать Itemid, как это она не запрещена.

Есть по крайней мере две причины, почему это плохая практика:

1. Вы можете забыть об этом поведении после того, как некоторое время
2. кто-то в вашей команде или другой программист, который будет работать с вашим кодом позже , может использовать этот компонент и сталкиваться с конфликтами.

Лучшим решением, которое вы можете решить, является преобразование itemId в конфигурационный блок со значением по умолчанию. В этом случае другой пользователь может легко изменить это свойство.

Answer 3

Добавление to @matt и @ Nikolay -

Неплохая практика иметь конфигурацию itemId для класса определение (вместо создания экземпляра)?

Целесообразно не делать этого. Верно, что несколько компонентов с одним и тем же элементом itemId могут существовать до тех пор, пока они находятся в разных контейнерах (даже дочерний контейнер может содержать компонент с тем же itemId, что и один из присутствующих в родительском). Однако проблема заключается в том, что мы должны быть осторожны в том, чтобы основывать нашу логику на уникальных элементах itemIds. Если мы будем следовать уникальному itemId для всех экземпляров, тогда мы с легкостью выполним запросы компонентов только с уникальным itemId и будем уверены, что тот, который нам нужен, всегда возвращается, - это не будет иметь место в случае, когда мы вводим дубликаты itemIds в системе, и мы всегда должны убедиться, что правильный селектор запросов передан. Если, безусловно, абсолютно неизбежно требуется. Я бы пошел с уникальным itemId.