3

ИМХО: получение данных из компонента довольно затратная операция (нужно передавать callback родителя, учитывать структуру данных и т.д.)

поэтому имеет смысл создавать дочерние компоненты только для отображения данных

например:

class ItemsList extends React.Component {
      render() {
        return(
        <div>         
            <ul>
                <Item name="Item1" />
                <Item name="Item2" />
...

но в большинстве случаев код Item довольно тривиален:

class Item extends React.Component {
      render() {
        return <li>{this.props.name}</li>;
      }
    }

тогда возникает вопрос, зачем создавать компонент для 1-2х строк HTML-кода, если их можно разместить в родителе?

ravend
  • 1,312
  • 11
  • 25
  • 1
    "ИМХО: получение данных из компонента довольно затратная операция" - нет. Это экономия на спичках которая оборачивается усложнением кода. Узкое место таки обычно голова программиста. Запись в дом узкое место. Создание пары-трйоки небольших js-объектов в памяти - обычно не узкое место. – Утка Учится Укрываться May 17 '17 at 10:21
  • Рекомендую использовать stateless functional components для таких простых штук (с реакта 0.14) const Item = props =>
  • {props.name}
  • , в них по слухам даже есть какой-то микровыигрыш в перформансе – Утка Учится Укрываться May 17 '17 at 10:22
  • https://hackernoon.com/react-stateless-functional-components-nine-wins-you-might-have-overlooked-997b0d933dbc – Утка Учится Укрываться May 17 '17 at 10:24
  • Но конкретно в этом примере можно элемент списка и не выносить в компонент офк, он еще не усложнился на мой вкус) – Утка Учится Укрываться May 17 '17 at 10:26
  • Рекомендую также посмотреть этот вопрос-ответ: https://ru.stackoverflow.com/questions/618640/react-js-%D0%9A%D0%BE%D0%B3%D0%B4%D0%B0-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D1%8C-%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82 – Утка Учится Укрываться May 17 '17 at 10:27
  • @УткаУчитсяУму, в более сложных компонентах чем Item, Вы сохраняете данные в дочернем или в родительском компоненте? например input куда сохранять? – ravend May 17 '17 at 12:01
  • 1
    ну да, работа с формами в реакте осложняется, потому что компоненты форм по своей природе стейтфул. Для работы с этим используется паттерн controlled components (ну то есть да, в дочернем). Подробнее тут: https://facebook.github.io/react/docs/forms. Но опять же, если у вас компонент просто форма отвечающая за объект одной степени вложенности, то можно на мелкие кусочки не дробить. – Утка Учится Укрываться May 17 '17 at 12:18
  • Best practices - они такие. Это всегда компромисс между двумя стульями: то ли множество бесполезных кусочков и мешающиеся абстракции (а у любой абстракции есть цена), то ли глобальный ужасный объект при взгляде на список состояний которого становится нехорошо – Утка Учится Укрываться May 17 '17 at 12:19
  • Я где-то уже писал свое эмпирическое правило: если я за полминуты плохо понимаю что происходит в компоненте, значит что-то пошло не так и возможно пора бить. – Утка Учится Укрываться May 17 '17 at 12:26
  • @УткаУчитсяУму, видел Ваше изречение и согласен с ним https://ru.stackoverflow.com/questions/618640/react-js-%D0%9A%D0%BE%D0%B3%D0%B4%D0%B0-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D1%82%D1%8C-%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82 – ravend May 17 '17 at 12:42
  • @УткаУчитсяУму, как Вы получаете данные из input-дочки при обработки в родителе? я знаю только такой способ: при создании дочки предать в неё callback или state родителя, и уже сама дочка будет вносить изменения в родителя, но тогда я возвращаюсь к началу своего вопроса, зачем создавать дочку если она все равно пишет в родителя? только изза деструктуризация большого компонента? ведь по сути дочка жестка привязывается в родителю и повторно может быть использована только в похожем компоненте – ravend May 17 '17 at 12:47
  • 1
    1). Суть при разбиении на компоненты не только и не столько повторное использование, сколько уменьшение количества вещей о которых приходится думать при работе над компонентами. То есть разбивать на штуки о которых проще думать. Это раз. 2) Все обычно колбек прокидывают, это нормальаня практика. Прокидывать пропсом штуку чтобы потом ее мутировать - категорически не рекомендуется. Пропсы считаются иммутабельными, и с какйо-то версии кажется физически морозятся – Утка Учится Укрываться May 17 '17 at 13:00
  • 1
    3). Если вам много надо с формами работать, то есть тележка всяческих оберток. Самая распространенная - redux-form, но лично у меня с ней опыт весьма печален – Утка Учится Укрываться May 17 '17 at 13:01
  • @УткаУчитсяУму, есть ли возможности в компонент другой компонент передать? например: есть компонент popupDialog (единый подход для всего сайта), но на каждой странице свое содержимое – ravend May 17 '17 at 13:07
  • 1
    компонент - это физически просто навороченный js-объект, так что да, разумеется такая возможность есть. Можно компоненты-контейнеры писать типа и обращаться к итемам внутри контейнера как к this.props.children. Но для всяких модальных окон которые одинаковы везде полезно использовать паттерн "портал" - это когда компонент рендерит себя в другую часть дома. Подробнее читать например тут: https://habrahabr.ru/company/smartprogress/blog/306096/ – Утка Учится Укрываться May 17 '17 at 13:15
  • 1
    В общем компонент пропсами прокидывать иногда нужно, но для всяких модальных окон-сообщений почему бы просто не импортировать в нужном месте а не везде пропсами таскать? – Утка Учится Укрываться May 17 '17 at 13:22
  • @УткаУчитсяУкрываться не могли бы Вы оформить все Ваши комментарии в один отличный ответ – Alexandr Tovmach Feb 01 '19 at 09:36
  • @AlexandrTovmach, не, мне лень – Утка Учится Укрываться Feb 15 '19 at 10:27
  • @УткаУчитсяУкрываться =)) – Alexandr Tovmach Feb 15 '19 at 10:58