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

Question

[alex4answ]

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

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

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

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

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

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

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

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

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

Comments

[ddd329]

Полностью тебя поддерживаю. Сам не понимаю зачем или почему.
Может они что-то покурили и их понесло...

[Kovalsky]

"Добрый день, я не понимаю что происходит." - это надо сохранить как шаблон на случай переговоров прямо максимальной важности

[Lorem Ipsum]

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

- полностью согласен и сам задаюсь этим вопросом

Answer 1

[dmitry-toster]

Были классы, были HOC

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

компоненты разделены на Container/Component или Умный и Глупый

В чем проблема? Вы тоже самое можете организовать и с хуками

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

Как правило все сторонние подключаемые библиотеки уже содержат в себе хуки из коробки, а те что еще нет, будут поддерживать в следующих версиях. Тоже не вижу здесь проблем.

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

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

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

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

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

Основные 2 причины: отказ от HOC и эмуляция методов жизненного цикла у функциональных компонентов.

Answer 2

[Сергей Сунцев]

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

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

Как говорится, все в ваших руках. Если приложение очень костыльное, то и классы тут не помогут.

Comments

[alex4answ]

Сергей Сунцев, звучит логично, чтож, просто из коробки по тем же гайдам redux, классы как-то удобнее и проще, ну я вас понял.

[Николай Савельев]

Это всё слова, рекламные слоганы. На практике получается неповоротливый неподдерживаемый монстр

[Developer]

Расскажи, как дебажить весь этот асинхронный ад?

[Сергей Сунцев]

AgentSmith, Я вам сочувствую, что у вас получаются монстры.
Но при хорошей модульной структуре, не очень важно какими компонентами вы пользуетесь.
Если у вас классовый компонент на 1000 строк и функциональный на столько же строк, то проблема не в них, а у вас.

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

Answer 3

[n1ksON]

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

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

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

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

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

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

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