Комментарии 24
Очередная рекламная статья с высосаной из пальца проблемой. Ну да, есть у хуков пара ограничений — к слову говоря, конкретно их вызов на корневом уровне функций реальной проблемой становился лишь пару раз, — ну так, как говорится, не нравится — не используй.
Проблема с сравнением по ссылке тоже яйца выеденного не стоит: автор же сам разлагает config на url, skip и take, так в чём проблема их в массив зависимостей и засунуть? Вода сплошная для того, чтобы статья внушительнее выглядела.
Короче, маркетинговый буллшит. Переводчики, вы хоть что-нибудь более полезное отбирайте для перевода, это уже совсем треш ведь.
Я полностью согласен с автором статьи. Хуки — это зло. Особенно для начинающих разработчиков.
К сожалению, реальность такова, что код будут писать не синьоры-помидоры, а неокрепшие джуниоры, которые не знают всех тонкостей циклов рендеринга или не могут за ними уследить.
Я работал над проектов в котором хуки сыграли злую роль, из-за этих пропавших зависимостей и из-за того, что нет контроля над мемоизацией, а архитектурных навыков у начинающих разработчиков мало, встречались компоненты с 5-8 useEffect, 2-3 useState в одном компоненте, который перерендеривался по 20 раз. Включив подсветку обновлений в React devtolls (которую убрали в одном из обновлений sic!, потом вернули), приложение было похоже на новогоднюю гирлянду.
А самое главное, исправлять это очень сложно. Нужно смотреть за каждым пропсом, который приходит из другого такого же большого компонента и исправлять там.
Хуки выглядят просто, а на деле — очень опасные и коварные стейт-машины.
Я видел немаленьких размеров UI на реакте, который полностью на 100% перерисовывал себя во всех без исключениях ситуациях (даже если по нему просто мышкой поводить, срабатывали onmousemove). Хуков там было использовано 0 — в те времена о них только еще объявили.
Вы пишете так, как будто в этом хуки виноваты.
Именно так я и пишу. Этот инструмент более требователен к учидчивости, пониманию внутренних концептов, нежели Реакт без хуков.
С хуками проще сделать неподдерживаемое приложение.
Из опыта нескольких SPA с хуками/без и нескольких разработчиков разного уровня.
С хуками проще сделать неподдерживаемое приложение.
Это пустая риторика. Да, хуки представляют меньше «архитектурных границ». Нет, наличие любого количества архитектурных границ не мешает писать говнокод. Есть ли статистическая зависимость одного от другого? Не знаю, и не думаю, что кто-то проводил хорошие исследования на этот счёт. Всё, что я тут вижу — это голословные утверждения, которые «интуитивно» похожи на правду, и которые часто выдаются за реальное положение вещей через тезисы в духе «общеизвестно, что на C++ говнокодить проще, чем на яве» (или наоборот, в зависимости от того, что нравится и не нравится человеку, это высказывающему).
Меж тем, мой личный опыт говорит мне о том, что говнокодят всегда и везде, вне зависимости от выбранных инструментов. Например, уже несколько лет я сталкиваюсь с говноприложениями на react+redux, в то время как публичный дискурс мне постоянно утверждает, что редакс — это enterprise-grade, куча рамок, и минимизация возможностей «неокрепших джуниоров» чего-нибудь напортачить. А потом меня зовут на очередной нерасширяемый или погребенный под проблемами производительности проект и просят что-то сделать (что обычно превращается в классическое «все переписать»).
Все верно, в редаксе как раз очень мало архитектурных границ.
Вот, redux-toolkit, надеюсь, может чуть улучшить ситуацию.
Мой опыт подсказывает обратное. С хуками проще сделать неподдерживаемое приложение и труднее его потом чинить. И чем больше архитектурных границ, тем сложнее напортачить джуниору.
Ну не разрешайте использовать useEffect людям, которые не умеют с ним работать, в чем проблема?
Хоть кто-то правду написал!
Поводу о чём? Не нравятся хуки работайте с классами, как будто Вам запретили из использовать.
Правду можно открыть, когда есть тайна или секрет, или ложь. Что-то из этого было связано с хуками? Вы не способны прочитать документацию? Не знаете как посмотреть исходники?
Возврат исполняемой функции из хука
Зачем?
Ну вот, кто-то начинает триггерить фазу "освобождение от иллюзий" по хукам. По поводу "В текущем ландшафте JavaScript нет ничего подобного" — хук useEffect как паттерн это стандартная асинхронщина через event loop:
let prevMyProp = null;
function Component({ myProp }) {
setTimeout(() => {
if (prevMyProp === myProp) return;
1 + 1;
prevMyProp = myProp;
}, Component.didRenderTimeout) // по большей части 0
// то же самое хуком
React.useEffect(() => {
1 + 1;
}, [myProp])
return <div />
}Это превращает чистые синхронные функции в смесь синхронного и асинхронного кода с сайд-эффектами. В классовом подходе, несмотря на необходимость дубляжа в CDM / CDU, это вынесено в явные методы жизненного цикла и понимается проще, хотя комбинируется чуть сложнее.
о которых можно узнать из этого замечательного поста.
По моему здесь упущена ссылка на ресурс.
за вычетом двух проблем — порядок хуков и их количество должно соблюдаться и передача объектов в массив зависимостей — все остальное — это by design и в общем-то плюс.
Первая проблема нерешаема вообще но вобщем-то терпима и ничего страшного за собой не несет;
Вторая проблема решается (или подталкивает к решению) через оптимизацию зависимостей и понимание того откуда приходят эти зависимости, и решиться окончательно когда завезут поддержку tuple и record — массивы и объекты которые сравниваются по значению а не по референсу;
При этом хуки несут:
1) инкапсуляцию логики; теперь любую сложную логику можно хранить в одном месте и видеть порядок выполнения;
2) более простую типизацию, хуки принимают и отдают (как правило) легко типизируемые структуры данных;
3) более простую логическую модель. Не нужно знать о конкретных компонентах и их lifecycle, достаточно знать на самом деле что есть хуки для хранения состояния (useState, и useRef) и для вызова эффектов (useEffect/useLayoutEffect). Все остальное — композиция этих двух типов хуков;
4) легковесность. Хуки прекрасно выносятся в пакеты и живут потом в react/react-native проектах;
5) оптимизация и дебаг. Если у вас тысяча и один рендер вызываются на каждый чих то гораздо проще локализовать источник проблемы и оптимизировать хук чем продираться через древо компонентов.
Являются ли хуки серебряной пулей? нет конечно, ни один из инструментов/паттернов не является. Да, асинхронные операции чуть более боль чем хотелось бы и массив зависимостей может выстрелить в ногу при невнимательности.
К тому же хуки абсолютно опционально, и если бы комьюнити (ну или у вас в конкретном проекте) решили что классы это то что вам нужно — никто не запрещает продолжать пользоваться ими.
const state = {};
Это то, что в мире реакта называют «магией», потому что они не поняли, как это работает. И эта одна строчка на самом деле всё, что вам нужно, чтобы работать с данными в общепринятом подходе. Вы можете импортировать его в компоненты, вы можете изменять его как угодно и все изменения будут автоматически отражены в визуальной части. Именно поэтому про работу с данными во Vue и не пишут статей на хабре. Что о них писать, если они просто работают, надёжно и интуитивно.
Почему я разочаровался в хуках