Большое спасибо за видео, это лучший канал на мой взгляд! Было бы здорово посмотреть про redux toolkit, rtk query, и какие угодно темы по react, react native
@@it-sin9k спасибо жду с нетерпением. несомненно от Вас это будет интересно. особенно совренменные тенденции и в связке с нынче модным функциональным программированием.
За вывод в конце поставил бы дополнительный лайк. Сколько раз сталкивался с тем, что чем проще правило, тем больше вероятность, что оно будет соблюдаться. А то начинают мудрить, разные условия выдумывать "если так, то надо делать вот этак"... смотришь на это и понимаешь, что бред, никто не будет заморачивается. И так не только в программировании. Вообще по жизни это правило тоже работает
Вивчаю React + Redux і наштовхнувся на цей канал. Подобається, що все дуже схематично, розжовано і зрозуміло навіть початківцю у доволі складних темах. Однозначно підписка, один з тих скарбів, що я знайшов на тему фронта) Було б ще круто, якщо б бахнув пару інтенсивів чи просто підбірку відео з розробкою якогось нового пет-проекту Успіхів у розвитку каналу!)
Насчёт селектора getCourseExpirationDate: мы не знаем, как устроен задействованный внутри него селектор getCourse, который выбирает курс по id. Вполне возможно, что там производится поиск по массиву. Поэтому, если мы предполагаем наличие очень длинных массивов (как в getTotalPrice), то мемоизация нужна и здесь.
4:35 А почему тут не стоит? Создания двух инстансов классов (Data и Intl) вряд ли совсем бесплатное. И если данные не менялись, то мне кажется этого лучше не делать
Мысль про оборачивание всех селекторов в reselect как соглашения внутри команды в целом верная, т.к. это упрощает чтение и отладку кода. Однако если у вас на проекте 20 фуллстек-разработчиков, и все могут править любой код (т.е. нет никакого разделения ответственности), то у вас в процессах что-то пошло не так. Вместо того, чтобы быстро и качественно реализовывать фичи в знакомой предметной области (когда есть понимание бизнес-процессов и их технической реализации), вы будете постоянно с нуля отлаживать эту лапшу из селекторов и Redux, т.к. один из 20 ваших "коллег" неделю назад добавил туда новый экшен/редьюсер/эпик, и теперь все идет по совершенно другому флоу. Узнаете вы об этом конечно же, когда вы придет бага на условно ваш функцинал 🙂 Чтобы понять всю "магию" под капотом Redux и reselect, достаточно пару раз внимательно изучить исходники и послушать очень подробные и простые разборы от АйТи Синяк. Как только вы это поняли, в дальнейшем вас ждет экстенсивное накидывание в Redux-стор еще больше селекторов и экшенов, отчего вы не будете расти профессионально, а лишь зарываться в повторном дебаге кода, который совсем недавно вы с горем пополам раздебажили... По крайней мере таким был мой путь разработчика маркетплейса от крупнейшей в РФ IT-компании, который одновременно разрабатывало более 50 фронтендеров без разделения ответственности и с одним глобальным стором :-) Если для покрытия кода достаточно 5 человек, то с ними договориться намного проще, чем с 20, а самого кода становится на порядки меньше. Следовательно, уменьшается вероятность того, что вы будете видеть код впервые. Следовательно, вы (и еще 4 коллег) будете знать, как он работает. Следовательно, можно не использовать мемоизацию селекторов, там где она действительно не нужна. Но лучше вообще не использовать Redux и reselect, а рассмотреть MobX, где есть реактивность и честные вычисляемые свойства, которые будут И повторно вычисляться И вызывать ререндер ТОЛЬКО при изменении зависимых свойств, а не повторно вычисляться при ЛЮБОМ изменении стейта, НО вызывать ререндер только если новое вычисленное значение отличается от старого (как это сделано в reselect) 🙂 При этом вместо десятка файлов для Redux, вся логика будет лежать внутри одного-двух файлов, что тоже значительно упрощает чтение и отладку.
Вопрос отличный, похожая дискусия была и про React.memo. Думаю аргументы будут примерно те же. Вот я видео про это записал: ruclips.net/video/uEeZ2TUkOCE/видео.html
Отличное видео. Я как раз много времени тратил на то, чтобы думать и проверять стоит ли конкретный селектор мемоизировать и думал "А не пойдет ли эта мемоизация мне в убыток?". Но этим видео автор переубедил что лучше выбрать подход постоянного оборачивания т.к. это сэкономит много времени и бизнесу и разработчикам, и главное - лучше ошибиться и сделать лишнюю мемоизацию, чем ошибиться и сделать лишний ререндер. Все дело в цене ошибки в случае разных подходов. Было бы еще круто, если бы здесь было упомянуто о том, что реселект по дефолтну имеет кэш 1го уровня и что мемоизация будет работать некорректно если использовать один инстанс селектора в разных компонентах
чекав, чекав і пропустив ;) так, все правильно -- краще обгорнути, ніж не обгорнути. до речі. реселект ще стимуліє до написання більш простих селекторів та подальшу їх композицію (до речі, мемоізацією при цьому можна керувати окремо від композиції) -- що є класною практикою
Согласен :) Нажимайте колокольчик, чтобы не пропустить новое видео! Или спрашивайте в комментариях) я напишу, если такое видео уже существует или планируется)
Привет, возможно помнишь как я писал про свою либу react-afc. Я её доделал и даже протестировал (поверхностно с помощью React Devtools) скорость отрисовки обычного и компонента из либы. Получилось что в простых компонентах почти не уступает, а в более сложных (с useCallback, useRef и т.д.) даже в разы обгоняет обычный компонент. Но суть не в этом. Как у опытного специалиста, хотел бы спросить как можно хоть немного продвинуть пакет в массы (ведь без фидбэка никуда). Статью на каком-нибудь сайте написать, или ещё чего может? P.S. видео топ, жду ещё :)
да, лучше всего написать статью на хабре и потом ходить в телеграмм каналы и предлагать им опубликовать твою статью :) главное найти того, кто захочет ее установить, пусть это будет для начала 1-3 проекта, но на них ты сможешь оттестировать свою либу и уже в более широкие массы с протестированным продуктом легче пойти :)
@it-sin9k вы упускаете важный момент заключающийся в том что мемоизация селектора выполняет две роли: первая хорошо освещена - стабильный возвращаемый результат и снижение числа рендеров, а о второй нет ни слова во всех роликах по этой теме: снижение нагрузки на процессор и память при вычислении результата . Все селекторы которые в данный момент находятся в смонтированном компоненте выполнятся при любом изменении стейта, даже если результат компоненту не интересен(об этом было в прошлом ролике) Поэтому не могу согласиться с тем что во втором случае createSelector не нужен. говоря так мы забываем о второй его роли, то есть все что выполняется внутри, теоретически может начать выполняться сотни раз в секунду, а в нём есть вот что: вызов другой функции неизвестной сложности, создание объекта даты и ее модификация, создание объекта форматирования и вызов самого форматирования. Утечка памяти гарантированная
Спасибо за подробный комментарий :) "ни слова во всех роликах по этой теме: снижение нагрузки на процессор и память при вычислении результата " (с) в третьем примере как раз рассказываю про это. Что это экономит и вычислительные ресурсы "не могу согласиться с тем что во втором случае createSelector не нужен" (с) Как раз таки для этого я и записывал видео, про то что мемоизация не бесплатная. И createSelectors так же кушает ресурсы соразмерные вычислению дат. И тут как раз спорный вопрос, что дешевле, вычислять как раз дату или же сравнивать значения в createSelectors. При этом нужно хранить еще копию вычисленного значения. Что требует памяти дополнительной. В таких спорных ситуациях, как по мне можно и не оборачивать, результат будет тем же
Неплохо было бы записать полное видео по использованию redux с хуками, redux с mapstatetoprops, redux toolkit, и rtk query в ещё одном видео
Всегда полезно залезть под капот редаксу и посмотреть, как там все крутится и работает! Спасибо!
Большое спасибо за видео, это лучший канал на мой взгляд! Было бы здорово посмотреть про redux toolkit, rtk query, и какие угодно темы по react, react native
Спасибо за такую высокую оценку! Постараюсь до всего дойти) нужно время на это)
@@it-sin9k надеюсь и на мобикс хватит времени или поочередно.
@@romanmed9035 мобикс точно стоит в очереди, с ним у меня был реальный опыт более 2 лет) так что есть что рассказать)
@@it-sin9k спасибо жду с нетерпением. несомненно от Вас это будет интересно. особенно совренменные тенденции и в связке с нынче модным функциональным программированием.
@@it-sin9k привет, хотелось бы небольшой ролик почему использование useLayoutEffect в NextJS выдает предупреждения.
Просто лучший канал о фронтенде. Саша, огромное спасибо!
Спасибо! Очень приятно :)
За вывод в конце поставил бы дополнительный лайк. Сколько раз сталкивался с тем, что чем проще правило, тем больше вероятность, что оно будет соблюдаться. А то начинают мудрить, разные условия выдумывать "если так, то надо делать вот этак"... смотришь на это и понимаешь, что бред, никто не будет заморачивается. И так не только в программировании. Вообще по жизни это правило тоже работает
Полностью согласен :)
Отличное видео) Спасибо за ваши разборы, особенно понравилось про попапы и селекторы, теория + наглядные примеры и кейсы это супер формат!
Супер!!! Особенно хорошо про "важность" почесывания ЧСВ на review :-)
Просто очень жизненно))) сам не раз чесал себе ЧСВ))
Вивчаю React + Redux і наштовхнувся на цей канал. Подобається, що все дуже схематично, розжовано і зрозуміло навіть початківцю у доволі складних темах. Однозначно підписка, один з тих скарбів, що я знайшов на тему фронта)
Було б ще круто, якщо б бахнув пару інтенсивів чи просто підбірку відео з розробкою якогось нового пет-проекту
Успіхів у розвитку каналу!)
Спасибо!
спасибо!
"Unlike most global objects, Intl is not a constructor. You cannot use it with the new operator or invoke the Intl object as a function." © mdn
Насчёт селектора getCourseExpirationDate: мы не знаем, как устроен задействованный внутри него селектор getCourse, который выбирает курс по id. Вполне возможно, что там производится поиск по массиву. Поэтому, если мы предполагаем наличие очень длинных массивов (как в getTotalPrice), то мемоизация нужна и здесь.
Все верно :)
Спасибо!
4:35 А почему тут не стоит? Создания двух инстансов классов (Data и Intl) вряд ли совсем бесплатное. И если данные не менялись, то мне кажется этого лучше не делать
У меня другая стратегия - переезд на react-query ))
Мысль про оборачивание всех селекторов в reselect как соглашения внутри команды в целом верная, т.к. это упрощает чтение и отладку кода.
Однако если у вас на проекте 20 фуллстек-разработчиков, и все могут править любой код (т.е. нет никакого разделения ответственности), то у вас в процессах что-то пошло не так.
Вместо того, чтобы быстро и качественно реализовывать фичи в знакомой предметной области (когда есть понимание бизнес-процессов и их технической реализации), вы будете постоянно с нуля отлаживать эту лапшу из селекторов и Redux, т.к. один из 20 ваших "коллег" неделю назад добавил туда новый экшен/редьюсер/эпик, и теперь все идет по совершенно другому флоу. Узнаете вы об этом конечно же, когда вы придет бага на условно ваш функцинал 🙂
Чтобы понять всю "магию" под капотом Redux и reselect, достаточно пару раз внимательно изучить исходники и послушать очень подробные и простые разборы от АйТи Синяк. Как только вы это поняли, в дальнейшем вас ждет экстенсивное накидывание в Redux-стор еще больше селекторов и экшенов, отчего вы не будете расти профессионально, а лишь зарываться в повторном дебаге кода, который совсем недавно вы с горем пополам раздебажили... По крайней мере таким был мой путь разработчика маркетплейса от крупнейшей в РФ IT-компании, который одновременно разрабатывало более 50 фронтендеров без разделения ответственности и с одним глобальным стором :-)
Если для покрытия кода достаточно 5 человек, то с ними договориться намного проще, чем с 20, а самого кода становится на порядки меньше. Следовательно, уменьшается вероятность того, что вы будете видеть код впервые. Следовательно, вы (и еще 4 коллег) будете знать, как он работает. Следовательно, можно не использовать мемоизацию селекторов, там где она действительно не нужна.
Но лучше вообще не использовать Redux и reselect, а рассмотреть MobX, где есть реактивность и честные вычисляемые свойства, которые будут И повторно вычисляться И вызывать ререндер ТОЛЬКО при изменении зависимых свойств, а не повторно вычисляться при ЛЮБОМ изменении стейта, НО вызывать ререндер только если новое вычисленное значение отличается от старого (как это сделано в reselect) 🙂 При этом вместо десятка файлов для Redux, вся логика будет лежать внутри одного-двух файлов, что тоже значительно упрощает чтение и отладку.
А почему мемоизация в Redux не включена по-дефолту?
Вопрос отличный, похожая дискусия была и про React.memo. Думаю аргументы будут примерно те же. Вот я видео про это записал:
ruclips.net/video/uEeZ2TUkOCE/видео.html
декабрь 2022 синяк всё ещё думает, что что-то сравнивается по ссылке, а что-то по значению...
А как?
Поделитесь, интересно же
@@pavelshev4473 подпишусь на тред) Тоже интересно
@@pavelshev4473 тоже жду с нетерпением, развития этого треда)
@@it-sin9k начни пока сам копать, вот тебе и тема для интересного ролика, вдруг он решил потроллить
Опа)
reselect в 2022 ахахахахаха
а что не так?
@@Илья-с1л6э в современных проектах нет этого рудимента
@@popuguytheparrot_ эм... ну пока в современных проектах есть редакс,там будет reselect
@@Илья-с1л6э пока в прослойке между стулом и клавиатурой будет мусор, тоже самое будет в проекте
@@popuguytheparrot_ понятно. Просто пустословие
полезное видео
Отличное видео.
Я как раз много времени тратил на то, чтобы думать и проверять стоит ли конкретный селектор мемоизировать и думал "А не пойдет ли эта мемоизация мне в убыток?". Но этим видео автор переубедил что лучше выбрать подход постоянного оборачивания т.к. это сэкономит много времени и бизнесу и разработчикам, и главное - лучше ошибиться и сделать лишнюю мемоизацию, чем ошибиться и сделать лишний ререндер. Все дело в цене ошибки в случае разных подходов.
Было бы еще круто, если бы здесь было упомянуто о том, что реселект по дефолтну имеет кэш 1го уровня и что мемоизация будет работать некорректно если использовать один инстанс селектора в разных компонентах
Спасибо
чекав, чекав і пропустив ;)
так, все правильно -- краще обгорнути, ніж не обгорнути.
до речі. реселект ще стимуліє до написання більш простих селекторів та подальшу їх композицію (до речі, мемоізацією при цьому можна керувати окремо від композиції) -- що є класною практикою
Согласен :)
Нажимайте колокольчик, чтобы не пропустить новое видео! Или спрашивайте в комментариях) я напишу, если такое видео уже существует или планируется)
Привет, возможно помнишь как я писал про свою либу react-afc. Я её доделал и даже протестировал (поверхностно с помощью React Devtools) скорость отрисовки обычного и компонента из либы. Получилось что в простых компонентах почти не уступает, а в более сложных (с useCallback, useRef и т.д.) даже в разы обгоняет обычный компонент.
Но суть не в этом.
Как у опытного специалиста, хотел бы спросить как можно хоть немного продвинуть пакет в массы (ведь без фидбэка никуда). Статью на каком-нибудь сайте написать, или ещё чего может?
P.S. видео топ, жду ещё :)
да, лучше всего написать статью на хабре и потом ходить в телеграмм каналы и предлагать им опубликовать твою статью :)
главное найти того, кто захочет ее установить, пусть это будет для начала 1-3 проекта, но на них ты сможешь оттестировать свою либу и уже в более широкие массы с протестированным продуктом легче пойти :)
Лайк и подписка однозначно!!! Тема лишних рендеров из-за неправильных селекторов очень тонкая, но раскрыта восхитительно.
спасибо! я очень старался)
очередное отличное видео! хотелось бы по возможности побольше, особенно про внутренности react-а
Вы заказывайте более конкретные темы, я как вдохновения наберусь, возьму еще тему)
@it-sin9k вы упускаете важный момент заключающийся в том что мемоизация селектора выполняет две роли: первая хорошо освещена - стабильный возвращаемый результат и снижение числа рендеров, а о второй нет ни слова во всех роликах по этой теме: снижение нагрузки на процессор и память при вычислении результата .
Все селекторы которые в данный момент находятся в смонтированном компоненте выполнятся при любом изменении стейта, даже если результат компоненту не интересен(об этом было в прошлом ролике)
Поэтому не могу согласиться с тем что во втором случае createSelector не нужен. говоря так мы забываем о второй его роли, то есть все что выполняется внутри, теоретически может начать выполняться сотни раз в секунду, а в нём есть вот что: вызов другой функции неизвестной сложности, создание объекта даты и ее модификация, создание объекта форматирования и вызов самого форматирования. Утечка памяти гарантированная
Спасибо за подробный комментарий :)
"ни слова во всех роликах по этой теме: снижение нагрузки на процессор и память при вычислении результата " (с)
в третьем примере как раз рассказываю про это. Что это экономит и вычислительные ресурсы
"не могу согласиться с тем что во втором случае createSelector не нужен" (с)
Как раз таки для этого я и записывал видео, про то что мемоизация не бесплатная. И createSelectors так же кушает ресурсы соразмерные вычислению дат. И тут как раз спорный вопрос, что дешевле, вычислять как раз дату или же сравнивать значения в createSelectors. При этом нужно хранить еще копию вычисленного значения. Что требует памяти дополнительной. В таких спорных ситуациях, как по мне можно и не оборачивать, результат будет тем же
и эта наша дискуссия, лишний раз подтверждает, что стоит просто оборачивать все подряд и не думать об этом всем)
@@it-sin9k что недо джуны и делают. а потом что будет не важно.
Контент как всегда топ! Желаю кучу подписчиков 😎
Спасибо!