В чем смысл использовать хуки?

Добрый день, я не понимаю что происходит.

Были классы, были HOC, компоненты разделены на Container/Component или Умный и Глупый.
Были свои зоны ответственности, ничего не перемешано, но тут появились хуки.

И если жить с хуками только React еще можно, но когда проект не демонстрационный, а реальный, то подключено еще кучу различных библиотек, у каждой второй есть хуки, в итоге все перемешано.

Далее философия Redux, "не диспатчить actions напрямую", все через actions creator и тп и тд, сейчас нам просто предоставляется dispatch из useDispatch()

Теперь компонент прочно связан с редаксом, и отвечает за все сразу.

Как это тестировать?
Придется создавать для теста каждого компонента обертку из провайдера?

Раньше можно было взять компонент, передать props и быть довольным.

В итоге, я не понимаю куда все идет, почему уходят с классов (удобных, понятных, структурированных) на функциональные компоненты с хуками?

На демонстрационных примерах все понятно и очевидно - компоненты проще и читабельнее на хуках, но реальные проекты это какое-тоо месиво и фарш
  • Вопрос задан
  • 1214 просмотров
Решения вопроса 1
@dmitry-toster
Были классы, были HOC

Они и сейчас есть. Касательно HOC: в виду того, что мы не можем подключить компонент напрямую к стору, приходится делать доп.обертку mapStateToProps. Тем самым над компонентом нарастает еще один компонент который связан со складом. Потом еще одна обертка withStore, withRouter и тд. В дебаггере начинаешь уже видеть большую вложенность компонентов и по мере роста приложения это уже становится антипаттерном. Это все плохо работает с точки зрения минификации и производительности из-за больших деревьев вложенности.
компоненты разделены на Container/Component или Умный и Глупый

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

Как правило все сторонние подключаемые библиотеки уже содержат в себе хуки из коробки, а те что еще нет, будут поддерживать в следующих версиях. Тоже не вижу здесь проблем.
Далее философия Redux, "не диспатчить actions напрямую", все через actions creator и тп и тд, сейчас нам просто предоставляется dispatch из useDispatch()

Эта философия сохраняется и при использование хуков. Вы через useDispatch также диспатчите нужные экшены
Раньше можно было взять компонент, передать props и быть довольным.

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

Основные 2 причины: отказ от HOC и эмуляция методов жизненного цикла у функциональных компонентов.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
GreyCrew
@GreyCrew
Full-stack developer
Просто больше возможностей, вы можете строить более гибкие приложение, более точно подстраивать архитектуру, более точно отстреливать себе ногу (голову, печень).

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

Как говорится, все в ваших руках. Если приложение очень костыльное, то и классы тут не помогут.
Ответ написан
@n1ksON
юниор
Скажу честно, опыт написания классовых компонентов никогда не имел. Всегда писал только на функциональных и хуками пользуюсь активно.
Код функциональных компонент куда проще, меньше и понятнее, имхо. Хуки - очень полезные инструмент. Нужно иметь разделять state. Что-то идёт в redux, что-то хранится непосредственно в state самой компоненты. Также всё зависит от подхода к организации структуры в проекте.
useState, useRef и useEffect - вообще юзаю в каждом проекте, не представляю как без этого трио можно обойтись. Использование остальных уже от задач зависит.

Придется создавать для теста каждого компонента обертку из провайдера?

Да, но давайте не будем о грустном)

Раньше можно было взять компонент, передать props и быть довольным.

А что сейчас мешает?

На демонстрационных примерах все понятно и очевидно - компоненты проще и читабельнее на хуках, но реальные проекты это какое-тоо месиво и фарш

Если грамотная структура проекта, отделена логика, то всё чётко и понятно. Да, обычно, самая большая боль - это структура. Триллион папок с файлами. Но не уже ли на классах в реальных проектах по-другому?
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы