Возможно ли с помощью hooks создать полноценную замену классовым компонентам?

Question

[Fengol]

До недавнего момента думал что hooks позволяют полностью отказаться от классовых компонентов и по своей сути, являются их "убийцей". А кроме того, создание собственных хуков обещает упростить работу с переиспользуемым кодом. Я был счастлив живя с этой мыслью, пока не потребовалось вынести логику сервиса в кастомный хук. Дело в том, что этот сервис, по совместительству является отдельной библиотекой, которая в лучших традициях в своей основе использует событийную модель, то есть нуждается в подписке\отписке, а кроме того имеет свой жизненный цикл с обязательным destroy. Подписаться можно, но как отписаться, когда нет альтернативы componentWillUnmount? Функция которая возвращается из useEffect либо срабатывает каждое обновление, а кроме того вызов destroy постоянно сбрасывает состояние сервиса. Неужели опять обман со стороны реакта? Неуже ли опять круть только для helloworld приложений на готовых ui библиотеках? Вся суть этих переиспользований кодов за счет хуков и должна ведь лечь в основу помощи при создании собственных сложных компонентов. А тут опять засада?

Answer 1

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

useEffect(() => {
  // component did mount code here
  return () => {
    // component will unmount code here
  };
}, []);

Почитать.

Comments

[Fengol]

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

[Fengol]

И хочется добавить что обман facebook зашел уже так далеко, что является лакмусом для наивности его сообщества. Как вы думаете, может здравомыслящий разработчик после оффициальных рекомендаций в ползу функциональных компонентов + хуки, пользоваться классовыми компонентами? Можно ли назвать спасением в контексте решения сложных проблем то, что таковым является лишь для уровня приложений разрабатываемых на учебных курсах? Как по мне, обман зашел такдалеко, что от него уже воротит.

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

Fengol,
1. Если бы вы открывали документацию, то знали бы, что метод componentWillUpdate вообще не рекомендован к использованию и пока присутствует в API лишь для обратной совместимости. Но специально для вас:

useEffect(() => {
  return () => {
    // component will update or unmount code here
  };
});

2. Если бы вы читали документацию React, а не оперировали своими домыслами, то знали бы, что Hooks Api - это вовсе не замена классовым компонентам и что команда React не рекомендует переписывать старый код, а лишь предлагает попробовать Hooks API в новом.

Как вы думаете, может здравомыслящий разработчик после оффициальных рекомендаций в ползу функциональных компонентов + хуки, пользоваться классовыми компонентами?

Внимательно перечитайте пункт 2.

Можно ли назвать спасением в контексте решения сложных проблем то, что таковым является лишь для уровня приложений разрабатываемых на учебных курсах?

Глупость высосанная из пальца. Hooks API писали, чтобы решить лишь одну проблему, если интересно какую, то рекомендую почитать документацию.

Как по мне, обман зашел такдалеко, что от него уже воротит.

Тут могу лишь посоветовать обратиться к врачу. Без обид.

[Korifa]

Антон Спирин,
не могу понять что не так может подскажите?
компонент рекрсивно перерисовывается если добавить в хук вторым аргументом переменную state, а без переменной не сохраняется в локалстораге

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

Korifa, а что вы хотите туда сохранить? Вторым аргументом тут должен быть пустой массив.

[Korifa]

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

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

Korifa, ясно. Попробуйте разбить задачу на два эффекта.

[Korifa]

Антон Спирин,
Здравствуйте
получилось когда добавил
window.addEventLeristen
а в ретурн window.removeEventListener
Правда почему-то в локалстораге сохраняется пустой массив, то есть старое значение, хотя я добавил данные и сохранил их в стейт.
Может еще подскажите насчёт картинок:
сохранил их в паблик папку, главная страница работает, а если перейти на другу, с другим url и вызвать там этот компонент то картинки не отображаются, можно это как-то исправить?

[Fengol]

Антон Спирин, прикольно!не заставляют переписывать старое, а рекомендуют писать новое. Этопо вашему не тоже самое что просто сказать забейте на классы - пишите с хуками?

Не знал что запретили componentWillUpdate! Тогда скажите, как же теперь узнавать об изменениях роута? Нетогда когда путь полностью поменялся, а тогда когда только его параметры изменились. Единственный способ это сделать определеить при update. Кроме того, как узнать об обновлении, если в случае с хуками, определент только один эффект не реагирует? Создать ещё один? Ну тогда при каждом изменении дома будет вызываться второй эффект и тем самым невилируется эффект оптимизации полученной от первый. Кроме того тело компонента тоже будет каждый раз вызываться? Это значит что каждый раз будет переинициализация всего. А это ещё хуже чем то, что раньше называли антипатерны при передачи объектов и стрелочных функций непосредственно в шаблоне. Тпеперь вообще все обнавляется. Кроме того хуки возввращают массивы, которые очень круто оптимизируются движком v8, но только в случае когда массив содержит значения одного типа. А реакт опять все наоборот делает.Ида, об этом они не пишут, об этомсамомусоображать необходимо. Где я не прав?

Видите накартинке вышеопределен хендлер?Ведь он будет каждый раз при обновлении заного определеяться, а это если вы помните, считается антипаттерном реакта. Даже если я сохдам ещё эффект и укажу ему что необходимо обновлятся только при смене параметров роутера, то хендлеры и другие объекты все равно при обновлении будут пересоздаватся.

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

Fengol,

прикольно!не заставляют переписывать старое, а рекомендуют писать новое. Этопо вашему не тоже самое что просто сказать забейте на классы - пишите с хуками?

Не то же самое. Это лишь рекомендация. Создателям React важен опыт применения хуков и отклик сообщества. Пока отклик во многом положительный. Они правда очень удобны.
В новых проектах использую и классы и хуки. Есть ряд кейсов где классы по мне читаимей и удобней.

Тогда скажите, как же теперь узнавать об изменениях когда роут изменяется?

componentDidUpdate, useEffect.

как узнать об обновлении если один эффект не реагирует?

Понять причину почему он не реагирует и исправить.

Создать ещё один? Ну тогда при каждом изменении дома будет вызываться второй эффект и тем самым невилирует первый. Кроме того тело компонента тоже будет каждый раз вызываться?

Простите тут я вас вообще не понял. Не надо писать эффектов, которые будут вызваться каждый render, если в этом нет необходимости. Главное, что вызов эффекта не подразумевает перерисовку компонента, если вы не изменяете в нем состояние.

Это значит что каждый раз будет переинициализация всего.

Чего всего? У вас как у разработчика в распоряжении множество приемов как свести вычисления к минимуму.
Неспособность конкретного разработчика справляться с подобными задачами, не делает Hooks API плохим.

А это ещё хуже чем то, что раньше называли антипатерны при передачи объектов и стрелочных функций непосредственно в шаблоне.

Тут стоит попробовать подумать почему инициализацию стрелочных функций в render так называли, в каких конкретно кейсах и чем они отличаются от случая с хуками. Понятное дело, что хуки подразумевают дополнительные расходы, но они минимальны.

Где я не прав?

Везде.

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

Fengol,

Видите накартинке вышеопределен хендлер?Ведь он будет каждый раз при обновлении заного определеяться, а это если вы помните, считается антипаттерном реакта. Даже если я сохдам ещё эффект и укажу ему что необходимо обновлятся только при смене параметров роутера, то хендлеры и другие объекты все равно при обновлении будут пересоздаватся.

По поводу антипаттернов написал выше. Без понимания что и почему, это слово применять не корректно.
Хандлер можно обернуть в вызов useCallback. Это предотвратит ненужные обновления дочернего древа.
Сложную логику не связанную с компонентом можно вынести. Дополнительные расходы на инициализацию анонимной функции минимальны.
Ну и для нестандартных задач вы всегда можете использовать классы. Доступ к this в хандлерах и к предыдущему состоянию - порой очень удобен. Хотя и первое и второе легко решается и с хуками.

[Fengol]

Антон Спирин, простите, оказалось чторазговор с вами равноценен пустой трате времени. Все что вы написали не имеет никакого отношения к том что озвучил я. Я об одном, вы о другом. И я давно вывел себе за правило не разговоривать с чуваками, которых я понимаю, а они не могутпонять меня.

Это лишь рекомендация. Врачи рекомендуют вести здоровый образ жизни. Это не тоже самое что -вести не здоровый образ жизни жутко плохо? Вы реально как служба поддерки, которая вообще ничего не понимает и говорит лишь реторическими фразами из доков. Вы не преподователь?

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

Fengol, в отсутствии аргументов переходите на личности? На самом деле, действительно трудновато порой понять человека, которому в силу предвзятого отношения, навязывание своих субъективных оценочных суждений и доказательство надуманной абстрактной правоты, важнее поиска истины и ответов.

Аргументы в подобных случаях, к сожалению, не всегда работают.

Повторюсь, если вы что-то не поняли из предыдущего комментария:
1. Антипаттерном называли совершенно другой кейс. Попробуйте сделать небольшое исследование и узнать почему. Глупо принимать что-то за истину не попытавшись понять причины.

2. Для вызова эффекта по получению и изменению маршрута/параметров/search достаточно одного хука, который будет вызываться только при инициализации и изменении переданных свойств:

const { search, pathname } = location;
const { slug } = match.params;

useEffect(() => {
  // do something
}, [pathname, search, slug]);

3. Накладные расходы для повторной инициализации колбеков, которые обычно даже не вызываются - минимальны, да и тут целое поле для оптимизаций.

4. Для контроля перерисовки древа существует множество инструментов и приемов. Хотя бы React.memo, connect, композиция и тд.

5. Хуками вас никто пользоваться не заставляет, а классы никуда из React не уходят.

6. Аналогия со здоровым образом жизни некорректна.

7. Вижу добавили правку насчет массивов и оптимизации. Вы серьезно? Единственный хук useState возвращает массив из двух элементов. О какой оптимизации тут может идти речь? Смотрю в ход пошли откровенно надуманные проблемы.