Делают ли так в Reacte?

Question

[maksipes]

Вопрос о best practices в Реакте.

Есть компонент ItemsList выводящий в цикле компонент Item . Каждый Item состоит из нескольких дивов, несколько из которых должны откликаться на клик.

Чтобы не городить огород из онКликов вешаю один обработчик onClick, спущенный с App компонента, на корневой элемент Item, и на верх передаю уже любой клик по Itemу, само событие и индекс кликнутого Itema.

export default class Item extends React.Component {
  render() {
    const { item, index, onClick } = this.props;
    return (
      <div className="item" onClick={e => onClick(index, e)}>
        <div className="item-over">...</div>
        <div className="item-main">
          <div className="item-text">...</div>
          <div className="item-hint">...</div>
          <div className="item-extra">...</div>
        </div>
      </div>
    );
  }
}

В App, где вся логика, принимаю:

onItemClick = (index, e) => {
    switch (e.target.className) {
      case "item-over":
        console.log("Клинкнут блок над айтмом " + index);
        break;
      case "item-text":
        console.log("Кликнут основной текст в айтеме " + index);
        break;
      case "item-hint":
        console.log("Кликнут доп текст в айтиме " + index);
        break;
      case "item-extra":
        console.log("Кликнут дополнительный блок а айтиме");
        break;
      default: {
      }
    }
  };

Ну перед этим естественно передаю ссылку на обработчик и собственно данные для отображения:

<ItemsList items={items} onClick={this.onItemClick} />

Вопрос - нормально ли так поступать в React и если нет - то как сделать правильно?

На мой взгляд - куча условий в обработчике смотрится не очень и идентификация элемента по классу тоже как-то сомнительно выглядит.

Comments

[Петр Мухуров]

как по мне, лучше onHintClick(), onExtraClick() и т. д., это позволит избавиться от полотна в onItemClick

Answer 1

[Антон Спирин]

Ненормально так делать. Одна из целей которую преследовали разработчики современных фреймворков это уход от необходимости вручную сверяться с DOM селекторами.
Подобные места, источник возникновения целого класса багов, когда вы забудете, что селектор используется в JS и переименуете или удалите его. А выяснят, что что-то отвалилось, возможно, только ваши пользователи.
Можно, конечно, использовать дополнительные селекторы с префиксами: 'item__hint js--item__hint', но с возможностями современных фреймворков, лучше и удобней отказаться от сверки с DOM селекторами и повесть разные слушатели на разные элементы.

Comments

[maksipes]

А какая альтернатива - куча отдельных онКликов и всех их передавать вниз пропсами?

Кстати, не уверен, что тут сверяется с ДОМ. Если вы имели ввиду объект е, так это должно быть реактовский объект. Там и классНэйм вместо класс идёт.

Насчёт источника багов согласен полностью. Мне тоже не нравится этот момент.

[Антон Спирин]

maksipes, во-первых ваш кейс оторван от реальности. Не ясно зачем вам выдергивать из компонента все эти слушатели, а с ними, возможно, состояния, да и вообще зачем слушать клики по тексту.
Во-вторых да, лучше повесить разные слушатели onItemClck, onToggleHint и тд.
В-третьих, вы по клику получаете DOM элемент и сверяете его селектор. Случайно удалите или переименуете - вылезут баги. Если не покрыть этот кусок тестами, то баги улетят в prod.

Там и классНэйм вместо класс идёт.

Тут могу лишь предложить вам поближе познакомиться с Web APIs.
Событие вы получаете синтетическое, а объект нативный.
Element.className


Короче говоря, такой подход смело можно назвать bad practice.

[maksipes]

Антон Спирин, спасибо. продолжение вопроса - Делают ли так в React? .. буду благодарен за совет.