Почему удалять StrictMode плохая идея?

[@perejro9916]

Огромное спасибо. Теперь удаляю с пониманием)

[@it-sin9k]

ааххаха) хорошо сказано)

[@Xeon83]

А я с удовольствием. Костыль архитектуры библиотеки, это стоит называть именно так!

[@vitek8137]

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

[@роматарасов-о8л]

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

[@it-sin9k]

Спасибо! Эту тему я сам долго игнорировал) и наконец то пришлось с ней столкнуться)

[@IT-Svyatoslav]

Синяк, низкий тебе и помощникам поклон! Ооочень полезная информация. Ставлю 👍 и жду нового подробного контента😊. Многие кого я знаю, пользуются твоим открывающим подводные камни материалом

[@it-sin9k]

Спасибо большое! Я рад, что мои видео помогают прокачиваться!)

[@pollstetchem]

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

[@oWeRQ666]

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

[@Flamel001100]

2:09 - только Strict Mode ~выключен~ включен?

[@aleksprimetv]

Удалил года три назад с проекта СтриктМод, думал это видео заставит меня вернуть его, не заставило xD

[@it-sin9k]

Попытка не пытка))

[@ПавелОстаточников]

Видео полезное, многие просто не включают стрикт мод и не вникают что это и для чего

[@n_dudin]

Для вникания надо читать доки и практиковать(но не проектах).

[@Virass]

Я еще слишком молод для такого 😅 Поживу еще немного в свое удовольствие))

[@Илья-э7ю9в]

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

[@NEWESTERS]

Так это же не хак, а вполне себе straightforward решение) А ещё более семантичным решением будет использовать AbortController

[@Илья-э7ю9в]

@user-me5zb5qi9b Да. Я там есть)

[@alexs7931]

а почему у вас такие ники user-pi и user-me? уже не первый раз вижу в комментах видосов разных ютуберов, словно сгенерированы.

[@Илья-э7ю9в]

@@alexs7931Сложно сказать) Раньше было нормально. Потом стало так. Уже давненько. Меня особо не напрягает

[@romandeveloper7720]

Парни. Возможно, при маунте компонента вообще не надо писать в useEffect запрос. Либо в рендер функции самописный хук а-ля реакта квери, или же можно вообще в react-router-dom loader свойство в createBrowserRouter сделать, оно и перед маунтом сработает, либо шину какую-то свою написать. И логичнее будет, что так данные перед маунтом зафетчатся, а не после. В кейсах с СТМами. А если на стейтах обычных реактовских - то хук самописный в рендер функции и всё.

[@it-sin9k]

Тут надо дождаться анонса 19-ой версии React. Они там кажется подготовили хук отдельный для запросов, вместо useEffect :)

[@romandeveloper7720]

@@it-sin9k ого-го)

[@romanmed9035]

смотрел выпуски как развлечения. а вот в этом выпуске уже интересное увидел.

[@romandeveloper7720]

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

[@kl3yto733]

весьма любопытно, спасибо!

[@andrew-966hdf47]

Спасибо за видео! Очень бы хотелось услышать от тебя большой доклад о работе RSC.

[@it-sin9k]

В планах есть такое видео)

[@andrew-966hdf47]

@@it-sin9k это отлично! С меня донат ;)

[@ramilgaripov3447]

Никогда не удалял StrictMode :)

[@it-sin9k]

Вот это респект!)

[@TheTexPro]

спасибо большое!

[@WebBestMaster]

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

[@drunk_craft]

Пойду верну Strict Mode в проект)

[@it-sin9k]

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

[@ПавелОстаточников]

В rtk-query есть кэширование и одинаковый запрос не будет отправлен. По прерыванию при размонтировании: мы в return добавили прерывание запроса, а не игнорирование ответа. Чтобы если запрос не нужен, то ресурсы даже не тратились на него, и опять же в rtk-query это легко сделать.

[@Ramosok]

Почти) правильно угадал) я с этим сталкивался

[@СергейКоролев-о6й1я]

В первые вижу такую крутую подачу

[@ДалерКамолов-г5т]

Здравствуйте, вопрос не по теме, но хотелось бы узнать ваше мнение. Нормально будет ли использовать в handlechange - ах инпута не useState а ref?

[@it-sin9k]

смотря для какой цели) почему возник такой запрос?

[@ДалерКамолов-г5т]

@@it-sin9k вот смотрю на многие сайты, яндекс и вк там когда в инпуте что-то вводиш, не происходит перерендер. Вот как они это сделали?)

[@Ramosok]

Оч круто!

[@paljm345]

1:38 - стрикт мод ВЫКЛЮЧЕН 2:08 - стрикт мод ВЫКЛЮЧЕН Ээээ, что?!?! 2:08 - м.б. включен??

[@it-sin9k]

Да) оговорочка вышла)

[@МаксимВоробьёв-ч4к]

Крутое видео

[@golden_smiles]

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

[@it-sin9k]

на чем переписал?)

[@hydrock9738]

Спасибо

[@portusdelphini]

Фиговая фишка, когда есть операции модификации данных на бэке

[@it-sin9k]

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

[@n_dudin]

function useSafeState(initialState) { const mounted = useRef(false); const [state, update] = useState(initialState); const setState = useCallback((value: SetStateAction) => { if (mounted.current) update(value); }, []); useEffect(() => { mounted.current = true; return () => { mounted.current = false; } }, []); return [state, setState]; }

[@BearVodkaAndValenki]

Удалял strict mode раньше и впредь буду.

[@ЕвгенийАл-л3е]

Ещё есть момент, что можно получить ошибки за счёт разницы в поведении дев и прод режимов

[@K2_PS]

Нет не удалось)

[@snatvb]

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

[@it-sin9k]

а как оно замедляет разработку?

[@ВалерийСмирнов-у9ш]

Делает невозможным отследить маунт и анмаунт компонента

[@snatvb]

@@it-sin9k например коммент ниже, иногда у тебя это может быть провайдер, который в целом никогда такого поведения не ожидает и тебе приходится писать костыли ради дев кода. Бывает люди находят ошибки, которых нет и пытаются их понять - что съедает время, как и ошибки внутри библиотек, на которые они не могут повлиять напрямую, но оно никогда не отломается на проде покрыть все кейсы мира везде - это очень дорогое удовольствие

[@it-sin9k]

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

[@snatvb]

@@it-sin9k тогда жду с нетерпением фидбэка)

[@ИгорьБарбашов-т7ц]

Да, warning по поводу попытки обновления state у уже размонтированного компонента напрягает. Но вот эти все флаги типа ignore - тоже, на мой взгляд, то еще решение. С большой степенью вероятности при монтировании компонента будет отправлено не 1, а 5 запросов - это что, значит пять флагов? И даже если не 5, а все-таки один, который отслеживает размонтирован ли компонент, то в каждом useEffect такую кострукцию городить... нужна какая-то абстракция на уровне сервиса, котрая это отслеживает.

[@ramilgaripov3447]

Легковесная обертка над fetch, кратно улучшает читабельность кода ;) Т.е да, флаги, если они нужны, будут под капотом хука useFetch, но внутри компонента будет все красиво.

[@thecatlucky]

Да, удалось ответить. Т.к. сам разбирался в StrictMode)

[@it-sin9k]

Круто! красавчик!)

[@kri4evskiy]

Хотел спросить в телеге, но подумал, что лучше тут) Что должно быть в иерархии выше? Провайдер над Стриктом или наоборот? { ... }

[@it-sin9k]

В идеале StrictMode над провайдером

[@ArtyomSamsonchik]

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

[@motolife4900]

боюсь strict mode)))