Как стать автором
Обновить

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

Время на прочтение18 мин
Количество просмотров3.9K
Всего голосов 3: ↑3 и ↓0+3
Комментарии2

Комментарии 2

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


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


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

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


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

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


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

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

Удивительно. Создали новое 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 компонент, когда захочешь поменять немного логику компонента, но нет другого варианта кроме как написать новый компонент. Как я уже писал, если код написан прямо в компоненте, его оттуда нельзя убрать, не переписывая компонент.

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

Публикации