Хорошо зарекомендовавший себя вариант повторного использования кода компонентов, малоизвестный в веб-разработке

[justboris]

Удивительно. Создали новое API поверх React и превратили его в Marionette.js

Кроме того, недостатки компонентов и хуков очень субьективные:

При необходимости расширения, придеться изменять код внутри компонента или хука.

Это значит, что у вас разделение между компонентом и хуком не получилось. Проблема не в API React, а в вашем коде

Любой хук же надо читать как условный код: If (isFirstRender) {… } else { ...}.

То же самое. В нормальных хуках такой проблемы нет, вы просто их неправильно готовите

У компонентов нет четкой зоны ответственности. Программист всегда стоит перед выбором, где лучше написать код – в пользовательском хуке или в компоненте.

Не очень понятно, что ваш подход тут меняет. Раньше программист стоял перед выбором, как сгруппировать код по хукам, а теперь – как сгруппировать код по behaviors. А разница в чём?

[strannik_k]

Удивительно. Создали новое API поверх React и превратили его в Marionette.js

Посмотрел, действительно в Marionette для behaviours используется такой же подход:
marionette.gitbooks.io/marionette-guides/content/en/behaviors/index.html
habr.com/ru/post/220163

Это значит, что у вас разделение между компонентом и хуком не получилось. Проблема не в API React, а в вашем коде

Скорее всего, вы просто не поняли проблему, о которой я говорю. Она редко возникает.
Создайте компонент, который использует ваш пользовательский хук. Потом попробуйте использовать этот же компонент без этого хука или с другим хуком, не меняя код компонента и код первого хука.

Любой хук же надо читать как условный код: If (isFirstRender) {… } else { ...}.

То же самое. В нормальных хуках такой проблемы нет, вы просто их неправильно готовите

Я тут не причем, это хуки так работают. Например:
const [value, setValue] = useState(10);
При первом рендере он устанавливает значение 10 и возвращает его. При остальных рендерах этот код возвращает уже не 10, а сохранённое в состоянии значение.
Лично мне не нравится, что код, который нужно выполнить только при инициализации, написан вперемешку с кодом, который выполняется при каждом рендере.

Не очень понятно, что ваш подход тут меняет. Раньше программист стоял перед выбором, как сгруппировать код по хукам, а теперь – как сгруппировать код по behaviors. А разница в чём?

У меня большая строгость и менее удобно, но взамен компонент получается более гибким.
Удобнее писать код прямо в компоненте, что большинство и делает, особенно поначалу, либо когда спешат. Но от этого компонент становится не гибким. Тут разница станет заметной, когда это будет 3rd-party компонент, когда захочешь поменять немного логику компонента, но нет другого варианта кроме как написать новый компонент. Как я уже писал, если код написан прямо в компоненте, его оттуда нельзя убрать, не переписывая компонент.

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