Какие плюсы и минусы наследования компонентов в react?

Question

[deight]

Какие плюсы и минусы у наследования и композиции?

class Button extends React.Component {
  get content () {
    return 'Content: ' + this.props.content
  }
  render () {
    return <button>{this.content}</button>
  }
}
// чем лучше и чем хуже использование такого подхода
class SuperButton1 extends Button {
  get content () {
    return super.content + ' (Super)'
  }
}
// и такого
class SuperButton2 extends React.Component {
  render () {
    return <Button content={this.props.content + ' (Super)'} />
  }
}

Я не говорю конкретно про этот пример, я говорю в целом. Никакой адекватной инфы нет в интернете. В fb говорят используйте композицию, потому что у них не возникало надобности в наследовании (это ни разу не аргумент, вот у меня возникла). Кто-то говорит что тяжело поддерживать, но примеров конкретных нет. Есть примеры которые типа показывают несовершенство ООП в целом, но то во что они упирались и говорили что вот мол проблема, я не видел в этом проблемы потому, что ее легко решить. Буду благодарен за любой комментарий на эту тему.

Answer 1

[RubaXa]

Ну, попробуйте, но заведите метрику в виде changelog и пишете, сколько раз потомок X сломался из-за изменения родителя.

Просто ответить абстрактно сложно, по большому счёту, проблема в том, что при использовании ООП в UI-компонентах, все потомки становятся очень хрупкими. Да, это всё конечно покрывается тестами, но это только помогает быстро выявит проблему, а проблема на самом деле в переопределении.

View-компоненты на самом деле проще не наследовать, а сделать точки расширения и через `props`, в конкретном месте, передать нужные функции `renderSomeFragment/children` в замен default'ных. Т.е. вам не нужно городить новый класс и потом его использовать, вы просто его используете и всё.

Comments

[deight]

Спасибо за ответ.

проблема в том, что при использовании ООП в UI-компонентах, все потомки становятся очень хрупкими.

вы имеете ввиду наследование как в SuperButton1 или в целом?

Если именно наследование, то как писать что бы ничего не ломалось? Например в моем примере, если в Button поменять используемый пропс с content на другой, то SuperButton2 сломается, а SuperButton1 нет. И наоборот если поменять название геттера content то SuperButton1 сломается SuperButton2 нет. т.е. в этом плане оба подхода равнозначны.

Если в целом, то куда выносить общий функционал? Например лучше писать огромные компоненты в которых есть весь функционал, использование которого регулируется пропсами (в идеале один компонент на все приложение) или писать разные компоненты но общий функционал выносить в отдельный компонент или функцию. Или какие лучше использовать альтернативы для Component -> FormComponent -> Field -> Input и почему?

[Александр Таратин]

deight,
>>>то как писать что бы ничего не ломалось?

Используйте typescript и типизируйте props и state. Тогда ошибки будут выползать на этапе сборки.

[RubaXa]

Смотрите, если взять ваш пример, то я не понимаю, зачем мне наследовать кнопку, если нужно просто передать другие `props`, тут ООП только мешает, вместо простого использования, я должен создать класс и потом его использовать.

Поймите, у блоки не должны быть умными, декомпозируйте задачу. У блоков сложным может быть только поведение и если поведение нужно в многих местах или нужно просто добавить какую-то функциональность, например `draggable` или `droppable`, то вместо наследования/mixin'ов пишем HOC и все довольны.