Ну наконец-то об этом начали говорить! Большое спасибо! По факту когда разбираюсь с багами в легаси часто начинаю именно с того, что пишу тест(ы), заменяю useEffect hell на "чистые инструкции" и код становится уже намного более читаемым и поддерживаемым. Удачи каналам в развитии!

@it-sin9k

4 ай бұрын

спасибо!) да) я тоже уже много таких useEffect hell выпиливал) думаю надо еще закрепить эту тему)

В доках реакта есть целый раздел объясняющий почему тебе скорее всего не нужен useEffect

@boldureans

4 ай бұрын

Мой ПР с переводом этой темы весит уже пол года.

@user-yp3rz4ij2v

4 ай бұрын

​@@boldureansможно ссылочку?

@boldureans

4 ай бұрын

@@user-yp3rz4ij2v yt блокирует ссылки. Можно посмотреть в репе

@bukanaka

4 ай бұрын

Да, ссылочку бы @@boldureans

@Fodintsov

4 ай бұрын

@@boldureans Написано 4 ответа, а по факту вижу 2. Подозреваю, что ссылка скрыта. Сам поискал - не нашел, где у докреакта гит. ( Может, расскажешь, где искать, без ссылки? Или в телегу ссылку брось, пожалуйста @fodinsoft

Согласно документации одно из предназначений useEffect синхронизация состояния компонента с внешним миром. Если мы по какой-то причине синхронизируем два состояния Реакта между собой это сигнал о том что-то не так. Нельзя сказать что состояния запрещено синхронизировать между собой, код будет работать, но вероятность ошибок и неожиданного поведения повышается. Что и показано в видео. Можно ориентироваться на два подхода: -> все что можно вычислить из состояния надо вычислить и не использовать для этого отдельное состояние. Мы избавимся от синхронизации состояния в useEffect, как следствия избежим дополнительного ре-рендера с перерисовкой на каждое изменение состояния от которого зависит useEffect. -> То что зависит от действия пользователя должно находиться в обработчике, а не в useEffect. Плодить дополнительные состояния ради того бы оставить useEffect не лучший вариант. Состояний должно быть необходимый минимум.

@alexmerser7455

4 ай бұрын

Хоть кто-то об этом написал)

@alexmerser7455

4 ай бұрын

не все в курсе про новую документацию реакта :D

@CJIu3eHb

4 ай бұрын

@@alexmerser7455 Ситуация с useEffect усугубляется тем, что раньше, кмк, педалировалась тема, что все побочки надо делать в useEffect. Т.е. были прямые ассоциации запрос->useEffect. А задумываться, первоначальная ли подгрузка или EventHandler, как-то было недосуг. Теперь же опыт использования решили систематизировать и по мотивам основных косяков написали гайд, как не надо использовать useEffect (спасибо, что в комментах упомянули, почитал). Там несколько раз упоминается "error-prone", что наводит на мысль, что сами по себе функциональные компоненты с хуками для мало-мальски сложной логики действительно костыльны, раз уж так много случаев неправильного применения всего лишь одного хука. Особенно доставил пункт "Adjusting some state when a prop changes". Тут рушится еще один застарелый стереотип, что надо исходить из того, что обычно все действия по обновлению стейта происходят после отрисовки (ну, кроме использования useLayoutEffect). А тут такой ловкий костыль по скоростному передергиванию рендера. Возможно, конечно, это мои личные проблемы с этими двумя стереотипами (вся асинхронщина в useEffect и все изменения происходят при следующем рендере после отрисовки), но на пустом месте такие гайды не появляются.

О да! Тоже заметил, что для меня это стало красным флагом - если в зависимостях есть какой-то стейт и в самом useEffect тоже меняется стейт. То есть автор такого кода, использует useEffect как подписку на один стейт чтобы менять второй стейт, но если так, то при изменении первого стейта явно меняй второй стейт тоже. Видео класс о наболевшем, спасибо ))

@it-sin9k

4 ай бұрын

Собрат по боли!)

Очень информативно! Спасибо, пойду пересмотрю свой код)

как всегда сжато и информативно!!! круто!

Спасибо. Очень информативно, я пока учусь так что мне это сразу объяснили. Круто.

Всегда крутые и актуальные ролики, спасибо.

интересный взгляд, спасибо за ролик )

Как ты прям в точку))) у меня была реализация ровно такая как ты показал) с useEffect переделал на твой конечный вариант) очень доволен, спасибо.

@it-sin9k

4 ай бұрын

Уже значит не зря пилил видос!)

Классная тема, спасибо, что рассказал, очень полезно)

Спасибо большое за полезный контент)

Хорошее видео, буду подмечать за собой такие кейсы

Вкратце о видео: 1. Использован useEffect не по назначению 2. Сделан пример без useEffect 3. ..? 4. profit Ожидал увидеть пример реального применения useEffect vs его альтернатив

@snobou12

4 ай бұрын

В точку, видос по типу "я не умею использовать useEffect, выпиливаем."

@it-sin9k

4 ай бұрын

Хорошо) добавлю в список сделать видео, когда его нужно использовать)

@hibiride

4 ай бұрын

Так про это видос и есть, что люди юзэфект лепят куда придется. Но заголовок кликбейтный, я тож повелся😂

@JoSmith0

4 ай бұрын

Нужен видос про правильное использование useEffect

Это не баг. Все работает так как и должно. Автор хотел донести, что не обязательно использовать для этой задачи useEffect. Но это просто два разных подхода и каждый из них имеет права на жизнь

@user-yw9wx4lv2w

4 ай бұрын

тогда ничего не баг) ведь все работает как должно - как описано в коде)

@golden_smiles

4 ай бұрын

@@user-yw9wx4lv2w Баг по опредению это когда не работает как надо. Здесь все работает как надо, просто надо различать события ввода пользователя в инпут и установки стейта программным способом. Как это сделать - вопрос второй, но бага никакого нет.

Стараюсь избегать использование useEffect в целом. Спасибо за видео!

применение эффекта вне контекста useEffect - очень плохая практика. самый банальный кейс - пользователь начал печатать, но пока suggestions грузились(допустим у пользователя медленный интернет), он решил закрыл окно с инпутом, компонент размаунтится, но загрузка данных продолжится. про concurrent rendering даже говорить смысла нет при таком подходе. так же это будет сбивать с толку других разработчиков, т.к. в реакте считается правильным все эффекты располагать в useEffect. в примере из видео я бы предложил использовать машину состояний. код получится хоть и побольше, но зато понятный и легко расширяемый.

@guitareter

4 ай бұрын

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

@it-sin9k

4 ай бұрын

то что вы описываете это история про race condition и неоконченные запросы. Я говорил в видео, что эту часть опущу в рамках этого видео. Но отменить запрос при таком написании кода абсолютно не сложно. Думаю более полную картину опишу в каком-нибудь будущем видео :)

@golden_smiles

4 ай бұрын

@@guitareter Вот поэтому юзеффект и нужен, чистить за собой. Да, по умолчанию он не чистит, но в этом коде никто не чистит никогда. Хрен бы знал о чем тут видео, если честно.

@mrynoplanetashka8988

4 ай бұрын

​@@guitareter , все эффекты должны находится в useEffect/useLayoutEffect. если расположить эффект в обработчике события, то не получится решить проблемы: - race conditions - cleanup on unmount - concurrent features - useEffect имеет особое поведение в react strinctmode - etc... для отмены запроса в useEffect ничего не мешает использовать AbortController, что и является хорошей практикой (не написание запросов в useEffect, а аборт ненужных запросов). проблема решения предложенного в видео не в том, что в нем нет клинапа и т.д., а в том, что при таком решении проблемы описанные выше будут не решаемы(возможно решаемы с ужасными костылями)

Спасибо, полезно!

В документации реакта есть статья об этом, как перестать использовать useEffect неправильно

Спасибо!

спасибо, интересный пример

Хороший контент , как для Джуна было интересно )

«На душе закралось впечатление» Бгг

Интересна тема видео по профайлингу реакта

Красавчик

Имба🔥

Всё зависит от ситуации, я вот на днях мучался с react-hook-form и валидацией, значение ошибки возвращалось как "шаг назад", т.е. предыдущее значение в useState. Почему попадало в useState - отдельная тема. И как я не пытался писать условие, вызывать trigger, clearError из коробки формы, всё-равно поведение было некорректным. Хотя, если юзать дедовский способ setTimeout 0 то работало, естественно в прод такое даже ревью не пройдёт. И тут я решил завязаться через useEffect: 1) стало работать так, как и ожидалось. 2) по сколько ошибку можно было очистить 3 способами (поменять дату в календаре, отфильтровать по кнопке или руками снять чекбоксы), то мне стало ещё проще, не было необходимости в этих 3х случаях добавлять функцию проверки, тк useEffect это уже делал, на сколько хорошее решение - вопрос спорный, но рабочее и краткое. P.S. я сам считаю, что useEffect зло, но что поделать)

@popuguytheparrot_

4 ай бұрын

какой useState с rhf? Все должно храниться внутри rhf

@artyomtaranenko2267

4 ай бұрын

@@popuguytheparrot_ сложно объяснить, там кастомная ошибка. которая приходит с бэка и выводится вне формы

Класс! Ну ведь реально!…

Скажи пожалуйста, а что будет, когда твой асинхронный loadSuggesions завершит работу, а App к этому моменту размонтируется?

@it-sin9k

4 ай бұрын

будет ошибка в консоли, о том что я пытаюсь сделать setState после того как компонент уже удален из дерева. Но как я и говорил в виде, здесь не учтено много всего не учтено как debounce, race condition и так далее)

@Zamaraw

4 ай бұрын

Прикольно не учитывать набор глобальных, концептуальных проблем, при этом максимально концентрироваться на вырожденном кейсе из-за того что ты не учитываешь остальной набор проблем. Это очень современный тренд. В реальном автокомплите отображением списка у тебя рулит вообще не массив элементов и я сейчас даже не про дебоунсы, а про click outside и прочую логику, которая нужна для реального ux и входит в типичный набор задач. К тоже, добавь пробел и удали - и будет тот же странный список саджешенов… Плюс ко всему как пользователь ты ожидаешь, что по клику в инпут увидишь саджешены для текущего ввода - понабирай адреса в картах. В итоге в видео разобран кейс с миллионом допущений, ради того чтобы он случился, а не потому что он есть в реальности.

Классное видео, спасибо) а паттерн Четких Инструкций вы сами придумали или это уже существующий подход в разработке?

@zmmr013

4 ай бұрын

Это паттерн из 90х. От чётких людей. 👍

@it-sin9k

4 ай бұрын

сам придумал) я честно говоря любитель придумывать велосипеды)

@Disorrder

4 ай бұрын

@@it-sin9k и как же ты людей собеседуешь))) И главное, куда?

@it-sin9k

4 ай бұрын

@@Disorrder компания называется ControlUp :)

В Xstate-react вся логига и сайд эффекты вынесены в стейт-машину, конечный автомат. Очень прикольная штука.

@badcoder1337

4 ай бұрын

Крутой концепт, но в прод это потащит только идиот. Сюда же effector, nanostores и прочие либы от уникумов считающих себя умнее Абрамова и Уэстстрейта

@fedordostoevskiy4209

4 ай бұрын

@@badcoder1337 , про те согласен, даже не смотрел, а эта стейт-машина Очень хорошо поддерживается, даже UI свой есть крутой, основатель Statly , кстати крутой тип в react мире. Можно смело использовать, только тяжёлая, по-моему, и не сразу вьезжаешь после redux, saga... Моё мнение только.)

Я решил все проблемы проще, выпилил react и теперь с vue как будто легко парю в небесах

@user-uw9xp8en3v

4 ай бұрын

И чем же Vue легче React?

@c01nd01r

4 ай бұрын

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

@user-ce6wu8wt3o

4 ай бұрын

Климов мы знаем это ты, нас не провести фейковым аккаунтом

@user-uw9xp8en3v

4 ай бұрын

@@user-ce6wu8wt3o как бы Климову React больше нравится

Ха, вчера только написал похожий код) только по вводе в инпут погружались значения в другое поле, потому бага не было, но твой пример крут!

Ты лучший 👌🏻

Лайк подписка за годный контент

Причина, почему на собеседованичх используют useEffect очевидна. использование сайд эффектов, особенно фетчинга вне useEffect является красным флагом. так же прошу обратить внимание, что на противоложной стороне useEffect hell лежит callback hell, когд кучу однотимных cb можно заменить парой useEffect. Хорошая практика, это когда пишешь не меньше useEffect или больше useEffect, а когда данный подход уместен здесь и сейчас

@it-sin9k

4 ай бұрын

> использование сайд эффектов, особенно фетчинга вне useEffect является красным флагом в какой момент и почему это стало для вас красным флагом. Было бы интересно послушать)

@lrsvolk

4 ай бұрын

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

@golden_smiles

4 ай бұрын

@@lrsvolk Если писать код как его пишут на ютубе, жизнь сразу становится проще. Можно забыть о разделении консернов, слоях абстракции, обработке ошибок, архитектурах и паттернах, код становится чище и понятнее, можно сразу из компонента писать запросы в базу и в продакшен.

@hiddenlul556

4 ай бұрын

так всегда было красным флагом, в реакте рендеринг компонент асинхронный и нет гарантии что ваша фунция с запросом выполнится в нужный момент времени как раз для этого и есть useEffect@@it-sin9k p.s хотя я сам пару месяцев назад делал как раз похожий компонент и часть логики для подгрузки вынез из useEffect в handler :xD

@coderam1678

4 ай бұрын

@@lrsvolk согласен. Приведенный подход в видео -- это скорее путь из одного ада в другой.

Я лет 5 назад перешёл с Vue.js на React но мне до сих пор не хватает простоты и лаконичности вью, когда у тебя есть watchers для каждого состояния вместо списка зависимостей, который ещё и растёт при каждом чтении какого-либо пропса, из-за чего для реализации чего-то похоженго на watcher приходится городить тонну проверок на то какие значения изменились а какие нет

@c01nd01r

4 ай бұрын

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

Спасибо большое за видео! Но хочу задать вопрос: в следствии написания логики работы suggestions в обработчике инпута у нас появилась излишнее зацепление компонентов. Не лучше ли все же оставить логику эффектам, но сделать suggestions более гибким? Например это позволит нам инкапсулировать логику выдачи подсказок в компонент Suggestions, передав значение для поиска

@kirills4631

4 ай бұрын

А объясните, пожалуста, про зацепление - как в видео перенос управления стейтом саджестов из хука в хендлер на него влияет?

@hyposlasher

4 ай бұрын

Каждый раз когда кто-то употребляет слово инкапсуляция, в 99% случаев это каргокультизм

@user-gh3jr7qr3t

4 ай бұрын

Долго думал над твоим комментарием. Ответ - нет, не лучше. 1. Неявное поведение кода, которое сначала надо будет найти. 2. Если у тебя suggestions компонент один, но логика запросов немного отличается, то нужно будет городить if внутри effecta в suggestions. 3. Большиство таких кейсов с эффектами пораждает собой "мигание экрана", что не очень хорошо сказывается на UX. А про лишнее зацепление - это нормально, когда компоненты работают вместе. Плюс здесь сцепки нет никакой, потому что мы всего лишь управляем данными компонента suggestions, т.е suggestions компонент никакого отношения к инпуту не имеет, а всего лишь получается данные "откуда-то сверху"

@it-sin9k

4 ай бұрын

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

@MultiMrBlock

4 ай бұрын

@@kirills4631 если мы захотим вынести логику выдачи саджестов отдельно, то в реализации как на видео это будет сделать дороже

А с таким подходом можно избавиться от всех эффектов или есть ситуации, где не обойтись? Подход интересный, видео топ, спасибо

@it-sin9k

4 ай бұрын

от всех не избавишься) но можно очень сильно сократить популяцию) сделаю еще видео про эту тему)

@user-nd5zd5kc5k

4 ай бұрын

@@it-sin9kспасибо за ответ)

Осталось все сделать по красоте через async await и будет гуд

Я бы это назвал не "четкие инструкции", а локализация обработки события, так как мы выяснили что нам надо загружать саджешены не при любом изменении значения инпута, а только при изменении с помощью ввода

@it-sin9k

4 ай бұрын

я скорее пытался идею передать, чем о конкретной реализации шла речь. Т.е. идея заключалась все что функции описано должно произойти, и никаких автоматических реакций не должно происходить после этого)

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

@golden_smiles

4 ай бұрын

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

последнее время выпиливаю не парочку useEffect, а целыми пачками) особенно когда залазю в легаси, вижу там невероятное количество ререндеринга cписибо за ролик)

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

Но почему не пойти еще дальше, и не вынести всю эту логику из компонента? Как потом тестировать всю эту [бизнес-]логику, что размазана тонким слоем по компонентам в хуках и хендлерах событий? Придумали ведь давно уже централизованный стейт в Redux (или MobX), придумали даже обработку сложных последовательностей событий через Redux Saga - которая, кстати, хорошо покрывается тестами. Зачем мешать бизнес-логику и логику отображения в сплошную кашу хуков?..

@CJIu3eHb

4 ай бұрын

Ой, жесть. Как раз наваял такой useEffect hell. Начиналось все с инпута поиска и фильтров и я ради интереса решил не клепать на стандартном редаксе, а попробовать TanStack Query. Вроде все относительно простенько должно было быть. Ну разве что автоподгрузка на костылях из-за фильтров (родную я поздно заметил, да и не увязать было ее, она для простейших случаев). А потом у фильтров стала усложняться логика, потом autosuggest. И в результате полный ппц, все обмазано хуками и useEffect, кроме меня никто не захочет в этом ковыряться (в некотором смысле, это плюс :). Это еще хорошо, что пока не планируется расширение функционала, а если что-то серьезное - то, боюсь, придется все переписать на redux. Т.е. с одной стороны, хотелось держать логику компонента поближе к нему самому (вынося в хуки), а не тащить куда-то состояние в общую кучу, если для других компонентов оно не нужно. А с другой - с редаксом было бы проще в понимании, просто кидай экшены в компоненте, а уж будут там танки или саги - это уже другой вопрос.

@it-sin9k

4 ай бұрын

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

@AlexanderBorshak

4 ай бұрын

@@it-sin9k > что есть бизнес логика в данный момент? Логика, что не относится напрямую к отображению (за которое и отвечает компонент Реакта), нет? Просто сейчас мы добавили один [сетевой] реквест прямо в хук или в хендлер. Через пару дней - еще один, в другой хук или хендлер. Потом создали еще пару асинхронных функций внутри хуков или хендлеров. И по итогу так почти во всех компонентах по всему проекту. И как тестировать такую лапшу - вообще непонятно, поскольку ни визуальную часть компонента нормально не протестировать, ведь там внутри все функции асинхронны и на сеть завязаны (а мокать абсолютно все в компоненте уже на 300-500 строк довольно геморно), ни нашу логику хуков / хендлеров не протестировать, так как она равномерным слоем размазана по компонентам, и переплетена с отображением...

@AlexanderBorshak

4 ай бұрын

@@CJIu3eHb +1

@it-sin9k

4 ай бұрын

@@AlexanderBorshak Все верно) легко скатиться до лапши) У меня есть своя архитектура которой я придерживаюсь) и она вроде решает проблемы со сложными компонентами) Планирую поэтому сделать ближайший курс)

I'll intentinally switch from Russian to English channel. Thanks Bro!

@it-sin9k

4 ай бұрын

Enjoy!

«Нет кода, нет бага».

А как на счёт useEffect с асинхронным запросом, на результат которого надо бы как-то отреагировать потом? Такой же подход можно применить? Вешать соответствующий колбэк на резолв того промиса? Хм.🤔

@it-sin9k

4 ай бұрын

так в примере с видео, так же запрос, на который надо отреагировать. В чем разница?

@denisv8640

4 ай бұрын

@@it-sin9k Вот и так подумал, но на всякий случай спросил. Мало ли там нюансы будут какие ;-). Спасибо.

О как я люблю в коде разные кавычки:) Если бы все писали нормальные двойные кавычки мир так же стал бы чище.

@es-gr7qr

4 ай бұрын

если бы писали божественные одинарные кавычки, то мир стал бы ещё чище :)

@zhenia14

4 ай бұрын

@@es-gr7qr еслинта на вас не хватает, и прекамит хуков, я бы высек вас на код ревью, нежно.

Тут больше ошибка в том что строка в автокомплите это с одной стороны строка для поиска, а с другой выбоанное значение, и это как то не учтено

В данном примере все просто и лаконично но когда компонент большой с сложной логикой а нужно добавить всего небольшую доработку разработчики не хотят рефакторить весь компонент а добавляют эфект ведь он решает конкретную задачу. Как мне кажется посыл тут в том что нужно не бояться рефакторить весь компонент иначе он обрастет подобным кодом и станет сложно вносить новые доработки. Но где найти баланс между небольшой задачей и полным рефакторингом компонента из за этой маленькой задачи?

@it-sin9k

4 ай бұрын

вопрос хороший) баланс в моих глазах следующий. Тебе нужно сейчас потратить время чтобы написать код и твоей команде в будущем надо будет потратить какое-то время на его суппорт или доработку. Это две переменные. При одном решение тебе сейчас надо потратить x времени, а в будущем твоей команде надо будет переписать 3х времени. В таком случае я поищу скорей всего решение в стиле, сейчас надо потратить 3х, а потом х. Всегда в будущем должно быть проще девелопить чем в настоящем. Но бывает нет времени и мы оставляем первое решение

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

@it-sin9k

4 ай бұрын

конечно все зависит от ТЗ) я скорее полагался на популярное поведение автокомплитов, когда если кликнул на один из вариантов, то он и подставился и все варианты исчезли)

@Kildor_nsk

4 ай бұрын

​@@it-sin9k​, я об этом же, да. Иногда это может быть ожидаемым поведением. Кстати, в этом случае без эффекта можно ли такое реализовать? Надо подумать.

@it-sin9k

4 ай бұрын

@@Kildor_nsk конечно) при клике на suggestion нужно просто опять запускать метод подгрузки suggestions и будет тоже самое)

@Kildor_nsk

4 ай бұрын

​@@it-sin9k, ну действительно) А главное, будет очевидно что это поведение ожидаемо и задумано разработчиком.

Единственное правило, которое позволит избежать багов: делать ровно один ререндер на одно действие. Иногда для этого нужен useEffect или даже useRef. Кейс из видео гораздо лучше смотрится, если это не куча стейтов, а один стейт немутабельного объекта, поля которого и есть ваши значения

Не совсем понял в чем же тут заключается баг. Все вполне логично выглядит, на скрине 3:14, когда мы выбираем suggestion и делаем setValue, юзЭффект реагирует на вэлью, что и следовало ожидать. Решение без юзэффекта это просто вариативность решения такой задачи

@user-iu5nk8pr5n

4 ай бұрын

KISS

написал комментарий, идея интересная и правильная. React, UseEffect, it.

Просьба осветить логику работы с debounce ) Заранее благодарю

@it-sin9k

4 ай бұрын

Во вторник будет новое видео про это!)

@igormalykhin5528

4 ай бұрын

Большое спасибо и огромная благодарность за канал!! @@it-sin9k

Тут в любом случае надо использовать какой-то флаг isLoading, запрещающий кликать на suggestion, так как во втором примере тоже гонка

А почему бы не использовать useEffect без привязки к какому либо свойству? типа просто оставить [ ] ??

@it-sin9k

4 ай бұрын

у меня не было цели отказаться вообще от любого использования useEffect) только от отказаться пытаюсь, там где это не имеет смысла)

это всё хорошо, но как только мы захотим введённое значение контролировать через пропсы, нам снова придётся использовать useEffect

@it-sin9k

4 ай бұрын

не могли бы вы привести пример?)

Жизнь подкидывает на рефакторинг компоненты, где >30 useEffect'ов, и это правда очень больно (и непонятно, зачем люди решили пойти по такому сложному пути!)

@it-sin9k

4 ай бұрын

Да) я такие вещи периодически встречаю) крайне наболевшая тема)

Не понимаю почему под видео столько восторженных комментариев. Ок, мы избавились от useEffect, круто, наверное. Допустим для дебоунса у нас есть хук `useDebounce` (который внутри таки будет содержать useEffect). Но что с race condition? - Вынести в отдельный хук, который опять таки внутри будет содержать useEffect? Btw, этот метод снова потребует флаг `disableSuggestions`. - Добавить ref/стейт-переменную, который будет содержать номер "актуального" запроса? Чего мы добьемся избавившись от useEffect в компоненте App? Как обрабатывать состояние гонки в коде с "четкими инструкциями"? Имхо, в этом примере этот подход с "четкими инструкциями" не работает.

@it-sin9k

4 ай бұрын

смотря о чем речь) например не обязательно пользоваться useDebounce для дебаунса, хуки не панацея же) Я планирую развивать этот пример, чтобы показать картину чуть шире, как я ее вижу)

@nexus7172

4 ай бұрын

@@it-sin9k меня больше race condition интересует, как с ним справляться?

@it-sin9k

4 ай бұрын

я запишу отдельное видео)

И в довесок ко всему, мы получили код который работает быстрее

Лайкос

Исключительно ради равновесия мнений перечислю плюсы которые я вижу в варианте с useEffect 😁: - Слово "effect" подразумевает взаимодействие с внешним миров. Поэтому ожидаемо увидеть fetch в useEffect, но неожиданно в onChange - В варианте с useEffect несколько проще решить race condition, потому что там есть cleanup - Практичные примеры часто чуть грязнее чем хотелось бы. Если многие люди тяготею в такой задаче к useEffect, значит это проще для понимания В любом случае единственный верный вариант это использование стейт менеджера 😁

@guitareter

4 ай бұрын

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

всегда делал и делаю без useEffect даже странно его в таких случаях использовать

в общем долой фреймворки, только ванила )

Та самая лекция на курсе, которую включают самым отсталым в группе:

Может так и должно быть? "Англоязыйчный канал"

@it-sin9k

4 ай бұрын

косякнули немного))

А я наоборот бы и не стал юзэффект тут юзать изначально и наверное бы начал думать о нем, только если бы что-то пошло не так)

Не знаю зачем я это пишу. Мне почти 36. Почти три года изучаю frontend самостоятельно. Начал с HTML -> CSS -> JavaScript -> react. Два года назад создал пару сайтов на HTML , CSS, JavaScript Ещё не разу не отправлял резюме. Ощущение что JavaScript и react безгроничны. Но верю что у меня получится стать программистом !

@it-sin9k

4 ай бұрын

отличный старт!) сейчас самое время начинать отправлять резюме!) для этого не нужно знать все)

@user-gl5xb2fe6b

4 ай бұрын

@@it-sin9k спасибо за слова поддержки! 🤝🏻

сталкивался с таким проектом где подобным образом была организована работа довольно таки больших форм. было больна

Видимо у меня ещё не случился Реакт головного мозга, потому-что мне и в голову не приходило использовать useEffect в подобных случаях... видимо сказывается большой опыт программирования на других языках, и небольшой опыт в реакте.

@it-sin9k

4 ай бұрын

да) люди часто злоупотребляют хуками)

давно заметил что в определённый момент возникает useEffect hell. Нужно уходить от реакт :)

А зачем вообще отслеживать изменение компонента, если onChange и так отслеживает input на изменения?

@it-sin9k

4 ай бұрын

почитайте комментарии) люди некоторые объясняют своим мотивы)

Посмотрел видос, вспомнил что у меня как раз есть useEffect который нужно убрать)

@it-sin9k

4 ай бұрын

годится!)

Действительно, кажется очевидным, но ошибка частая) А почему бы вам не постить открытые вакансии на фронтендеров в вашу компанию у себя в телеге?)

@it-sin9k

4 ай бұрын

Это опасная дорожка) допустим я запощу) у нас будет собес и я вам откажу. Потому что у нас высокие критерии найма) Вы обидитесь на это?)

@_GyG_

4 ай бұрын

@@it-sin9k возможно вы правы и большинство обидется и отпишется от вас) но я бы наоборот еще более углубленно начал смотреть ваши ролики и изучать темы, по которым у меня были пробелы на собесе

полностью согласен, не надо юзефект, если бы можно было я б его вообще не использовал

Насколько я знаю, побочные эффекты нужно писать, либо в функциях обработчиках или в useEffect. А не вместе)

@it-sin9k

4 ай бұрын

почему?)

@lionstar3189

4 ай бұрын

@@it-sin9k В документации реакта так написано. Правда, я не помню где именно)

@it-sin9k

4 ай бұрын

@@lionstar3189 хорошо) пусть будет так. Что есть у нас побочный эффект. Это непосредственно загрузка suggestions. У меня и вынесен в отдельный метод loadSuggestions. Можно вынести эту всю логику в отдельную функцию тоже. Но это сильно ничего не изменит :)

Воистину

0:29 "Англоязыйчный канал". опечатка

@it-sin9k

4 ай бұрын

точняк! спасибо)) но уже не сможем поправить)

Сам перешёл с useEffect на useMemo (в том числе и memo для компонента в отдельных случаях). Только когда требуется дополнительный рендер достаю и применяю useEffect. (как Джин из бутылки или окно Пандоры для performance вашей страницы/компонента).

А разве страница не подвиснет если onchange зависнет?

@it-sin9k

4 ай бұрын

нет) это же асинхронная функция)

@MrChemist5

4 ай бұрын

​@@it-sin9k а ты же не писал в сигнатуре onChange что она асинхронная 🤔

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

@it-sin9k

4 ай бұрын

следующее видео продолжение этого) уже активно монтируем)

почему не использовать useRef ?

@it-sin9k

4 ай бұрын

где?)

Если UseRef заюзать, это роли не меняет?

@it-sin9k

4 ай бұрын

что именно туда положим?)

@Grozny446

4 ай бұрын

​@@it-sin9kв первый инпут свой реф, во второй свой реф и т.д. а в сабмит е.preventdefault

@it-sin9k

4 ай бұрын

надо пример кода) пока непонятно) типа инпут не контролируемый?

@Grozny446

4 ай бұрын

@@it-sin9k const ref1 = useRef(); const ref2 = useRef(); function onSubmit(e) { e.preventDefault() console.log({text: ref1.current.value, number: ref2.current.value}) } ; text number press me

Привет, а зачем нужно было создавать новый канал? можно же сделать звуковую дорожку на англ языке, как это делает mrBeast

@it-sin9k

13 күн бұрын

не знал о такой функциональности. Но в любом случае отличаются же не только дорожки но и видео ряд. Можно рекламы в разные каналы разные вставлять. Тяжело убедить американского рекламодателя, если у тебя 50% из СНГ будет аудитории. А что делать с видео, которые давно озвучены только на РУ. Это если начинать с ноля и сразу с мыслью покрытия двух языков, тогда имеет смысл

Хорошо, напиши ту же логику с использованием useDebounce

@it-sin9k

4 ай бұрын

Да) я думаю про это сделать отдельный видос)

@nicholasmychka3101

4 ай бұрын

ну тогда і request cancellation +)

@user-xd6sc7cr3x

4 ай бұрын

@@it-sin9k И давай только не с кастомным, а с библиотечным хуком.

@it-sin9k

4 ай бұрын

@@user-xd6sc7cr3x честно говоря не очень понимаю зачем тут вообще нужен хук) debounce это же обычная функция)

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

@it-sin9k

4 ай бұрын

нет посыла, отказаться от него вовсе. Но использовать его только точечно, где это действительно оправданно :)

Как вернусь на фронт, выпилю парочку useEffect

@it-sin9k

4 ай бұрын

Ждем возвращение с нетерпением!)

Не надо такими сложными вопросами кандидатов мучать. Им нужно задать что-то попроще то, что они знают и приближено к реальности: поиск в графе в глубину и в ширину, радикс-сортировка. Ну в крайнем случае стадии уборки мусора в виртуальной машине Javascript. 🙂

@it-sin9k

4 ай бұрын

это не совсем вопрос) у нас 2-ой степ - это коддинг) мы даем задание кандидату и созванием после обсудить что получилось) и там как раз таки часто обсуждаем, почему решил вынести похожую логику в useEffect. не то чтобы это сильно влияет на найм, но проверяем открыт ли кандидат к альтернативным вариантам) Один товарищ сказал, что альтернатива ему не нравится и он так не хочет писать код) А как раз на проекте пишем альтернативным способом)

Можно было не переименовывать колбек в "четкие инструкции" :) Вообще юзать реакт хуки для обработки событий это кринж, нужно дизайнить компоненты так чтобы не приходилось размазывать обработку действий юзера по хукам

0:30 - англоязыЙчный

Не совсем согласен. В данном конкретном месте не важно, как ты решишь задачу, потому что есть один инпут и одна функция. Можно и так, и сяк. Когда инпутов или функций становится больше, без useEffect не обойтись. В коде самое главное - консистентность. Чтобы был один паттерн и не было никаких неожиданностей. Поэтому даже когда имеется только один источник истины, я не против использования useEffect. И как по мне, иметь флаг showSuggestions или open (но никак не disabled) - это обязательно для такого компонента. Не нужно опираться на список, чтобы отобразить его или нет. Пускай он висит в памяти, а за отображение отвечает флаг. Это не костыль ни в коем случае!

поидее надо было изначально так делать а не перекидывать это на useEffect либо тригер юзефекту отдельный делать.

Слышал как-то такое выражение "реакт головного мозга", мне кажется оно подходит для тех, кто бездумно использует useEffect. Я также делал, когда начинал изучать реакт, а потом перешел на Angular.

@alexlmaxl4966

4 ай бұрын

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

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

@it-sin9k

4 ай бұрын

так я же не из головы написал неправильно) а потому что многие люди пишут так) вот и рассмотрел такое написание кода)

выпили)

мне показалась не бога😅

Я хоть и новичок. Но мне бы в голову вообще не пришла мысль использовать для этой задачи useEffect

@it-sin9k

4 ай бұрын

К сожалению, не новички так часто делают))

@user-cl8hi9jw3b

4 ай бұрын

у меня есть коллега новичок, он тоже редко useEffect использует, во многом потому что банально не знает как он работает и боится накосячить

К сожалению такие ошибки не только новички делают 😢

@it-sin9k

4 ай бұрын

я собеседую только сеньоров) и эту проблему вижу постоянно)

@kasyak94

4 ай бұрын

@@it-sin9k странно это, особенно сейчас, когда все в новой документации есть, раньше чтобы понять такие ошибки либо самому разобраться , либо прочитать сторонние источники. Классные видосы. 💪🔥🙏