Самый скользкий механизм в Redux
ฝัง
- เผยแพร่เมื่อ 22 ก.ค. 2024
- Redux вроде как изучили вдоль и поперек, но от этого он не стал идеальным. В данном видео мы детально разберем самый неприятный механизм в Redux, которым многие стреляют себе в ногу
KATA - это новый подход к обучению программистов
Ката Академи: clck.ru/32jBHq
Исходники - github.com/facebook/react/blo...
Поддержать Айти Синяка можно здесь:
TH-cam: / @it-sin9k
boosty: boosty.to/sin9k
Patreon: / itsin9k
00:00 Анонс темы
00:26 Оплата обучения после трудоустройства
01:26 useSelector подписывается на store
03:00 Суть проблемы
04:43 Изучаем исходники
08:51 Хрупкость механизма
10:30 Пример проблемы
11:55 Подписывайтесь!
Подписаться на канал: / @it-sin9k
Twitter: / it_sin9k
________________
Канал о Фронтенде, который хочется порекомендовать (telegram):
t.me/frontendnoteschannel
-------------------------
Данный канал создан для инициирования бесед на различные темы IT сферы (социальные / технические), а также для тех кому короткая видео выжимка статьи, выступления на конференции или же просто личных мыслей, являются более удобным форматом
Урааа, новый видос от Синяка
Только начал разбирать эту проблему , как у тебя выходит видео!) Спасибо, очень круто все рассказал.
Вовремя я!)
Отлично разжевал!!! Спасибо большое))
Отличное видео с разбором тонкостей Redux. Я тоже как-то заметил в профилировщике, что без второго аргумента рендеров больше, нежели с подставленным shallowEqual из Ramda или Lodash.
супер!) очень интерактивно и доступно, спасибо!)
Просто прекрасно!
Это очень полезная информация, спасибо! Были такие ошибка
Спасибо за информацию. Разжевал отличноооо!!
Отлично разжевал! )) Спасибо за детали!
Выход каждого твоего видео, это как праздник) Спасибо!!!
Спасибо!)
Перед просмотром одеваешься нарядно?
@@papa_paskualle да)) как догадался?))
Очень качественный контент, впрочем как всегда на высоте. Благодарю за ценную информацию, ждём нового пушечного контента
Спасибо!)
Реально отлично, благодарю
Спасибо!
Отлично разжевал! Спасибо!
Спасибо. Отлично объяснил
Действительно отлично разжевал! Спасибо! Только вхожу в react/redux и твои видео очень помогают писать код сразу правильно!
Рад быть полезным :)
Спасибо, полезное видео
Поздравляю, сперва взяли иммутабельность, а потом героически её победили.
Опыт показывает, какое решение не бери, все равно будет где то жопа торчать) поэтому такого рода скользкие механизмы вполне себе естественны при любом решении)
Отличнооо разжевал =D
Ждем Реселект)))
По реселекту все уже опубликовано)
Спасибо за годный контент
Отлично разжевал!!! Спасибо))))
Крутое видео! Спасибо большое! мне кажется для большего понимания нужно было отметить что перерендриваться будут только те компоненты со сломанном селектором. Так люди могут подумать что сломанные селекторы будут заставлять перерендриваться абсолютно все компоненты. Или я что-то не так понял))
Спасибо!
Отлично разжевал! Мое почтение
Очень качественно разжевал все, респект👍
Как всегда круто, спасибо!
Планируете ли ролики по исследованию производительности приложения,
например через Profiler (в React Developer Tools) или welldone-software/why-did-you-render ?
Есть мысли такие, не знаю как доберусь, но мысли есть)
хороший видос, спасибо
Спасибо!
Благодарю!
Спасибо, даже знаю где у меня в проекте есть такая ошибка!👍
Чувак от души, отлично всё разжевал🤣🤣🤣, успехов тебе
Хорошо что подобные кейсы на данный момент описаны в документации редакса. Более того, там есть несколько решений данной проблемы в отдельных случаях. И обьясняется как правильно использовать селекторы, а как не стоит
Лайк!!! Отлично разжевал!!!
офигенно, я просто всегда юзал reselect и создавал какие то сложные селекторы с помощью функции createSelector(), а оно вон че, но это как промисы, хоть мы и часто пользуемся async await - надо знать как оно работает под капотом, спс!
Рад быть полезным!
Отлично разжевал 👍
Спасибо за позновательный контент!
Что думаешь о проблеме tearing в отношении разных библиотек с внешним состоянием, например, mobx?
честно говоря, я только сейчас гуглил, что такое tearing. Поэтому пока ничего сказать не могу :(
Отлично
Долгое время работал на друх стейт менеджерах, пришлось перейти на редакс... Огромное спасибо, что ты делаешь такие замечательные ролики! Без тебя, моя жизнь была бы в разы сложнее!
Отличительно разжевал!
Отлично разжевал!
Спасибо, чрезвычайно полезная информация, много использую редакс! А если селекторы составлять таким образом, что они просто возвращают action.payload, а какие-то изменения производить извне? Так не будет перерендеров?
Спасибо :)
Если вы никак не работаете над данными внутри селектора, то лишних рендеров не будет
Кайф, лишний раз убеждаешься насколько важно понимать, как работают инструмены)
Блин все круто, но как будто на самом интересно и остановился, хотелось бы услышать про reselect
Так есть же финальное видео про reselect
th-cam.com/video/qWzxwzcjttk/w-d-xo.html
Спасибо! В очередной раз убедился что нативный js лучше всяких популярных либ и фреймворков :)
Отлично разжевал 😉
Разобрано и объяснено отлично, но на мой взгляд это не хрупкость редакса, т.к. ссылки и значения это базовая концепция, которую необходимо знать каждому разрабу.
Отлично разжевал)
а если до реселекта не добрались то можно использовать shallowEqual для поверхностного сравнения, который так любезно нам предоставляет react-redux
хороший комментарий)
отлично разжевал))
Было бы круто услышать твое мнение про MobX и его сравнение с Redux
Да, планируется такой плейлист :)
Кайф
Как жеж хорошо что не надо работать с редаксом больше мне😅
Что используете?)
Отлично разжевал) но текст призыва к комментарию нужно сделать длиннее, из серии "Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?" Чтобы за счет ленивых жоп продвигался контент алгоритмом - он вроде коммент из двух слов не засчитывает
Интересный момент) я хз честно говоря как работает алгоритм)
Уточка
@@it-sin9k Я тоже хз, но на тех каналах, где ребята шарят - они просят оставлять комменты длиной не менее 4-5 слов для продвижения
@@demiurgen13 О как) буду иметь ввиду на будущее) спасибо!)
так подробно разбирать джуновскую проблему... ну не знаю, насколько это целесообразно
сложно сказать какого уровня эта проблема. Но за 8 компаний, где местами были одни синьоры помидоры, я видел такого рода "ломаные" селекторы неоднократно
Хороший ролик, спасибо. Возможно это больше не проблема редакса, а реакта и подхода иммутабельности. Хотя их уже и не разделить 😄
Получается что по своей сути Hook useSelector работает так же как и HOC connect. При любом изменении стора все подписчики оповещаются, но будет ли перерисован компонент или нет решает функция сравнения состояний
Абсолютно верно :)
Нет. Connect по дефолту использует shallow сравнение в отличие от сравнения по ссылке в useSelector. Поэтому в каком-то смысле useSelector это шаг назад в вопросе оптимизации ререндеров
@@kusov4748 ну не совсем так. mapStateToProps всегда возвращал объект, а внутри него уже был cars, currentUser и т.д. Т.е. список машин все равно проверялся по ссылке , а не проверялись машины внутри него. Поэтому идея осталась прежней
@@it-sin9k посмотрите доку redux. Там об этом пишут
@@kusov4748 никто и не спорит, что там об этом пишут) вот бы все еще доку читали и правильно понимали все моменты)
Эх... а на курсах яндекса по реакту про это не слово (
Это уже более продвинутый контент все же)
Чет даже не знал, что фильтр возвращает новую ссылку массива... эт сколько ж перфоманса упала из-за этого....
Что если сравнивать объекты через Json.stringify, а не shallowEqual?
не думаю, что приведение объекта в строку дешевая операция
Мне кажется, что тут проблема номер ноль именно в том, что люди непонятно зачем суют в глобальное состояние то, что там не должно быть.
Мне кажется это часто зависит от моды) Одно время пихали прям все подряд в стор, вспомнить тот же redux-form, который каждый чих в стор складывал. И все работало и большинство людей все устраивало. Потом началась новая мода, класть туда, только то что нужно. При этом на моих нескольких проектах были споры на эту тему между разрабами, кто то хотел как раньше все через Redux, а кто то был уже адэптем класть, только то что нужно :)
@@it-sin9k но там вопрос больше в предсказуемости, чем в производительности.
Вообще особого смысла в глобальном сторе нету, до того момента, когда приложение живёт само по себе и лишь иногда, по необходимости, общается с сервером.
Подход в Ангуляр с сервисами и RxJS на много чище и понятнее.
@@it-sin9k хотя, конечно, при SSR, наверное, с глобальным состоянием лучше.
Другой вопрос, что SSR суют туда, где он не нужен...
Тема важная. Вопрос, если передать функцию сравнения типо isEqual из lodash это спасет?
Да, это спасет. Я думаю в текущей ситуации даже функция shallowEqual спасет. Так как в самом массиве ссылки на машины одни и те же. Ну и конечно shallowEqual куда дешевле, чем глубокое сравнение
Мне одному не понятно почему шаблонизатор react-js пытается изображать из себя - ...контроллер? ))) Что бы проблемы react`а закончились ...нужно перестать превращать его в контроллер. Имеет смысл написать для него - оболочку (архитектуру), которая бы управляла состояниями и шаблона и в целом делегировала полномочия.
та-а-а-к ;)
По-перше, бездоганна візуалізація -- от би я так міг малювати!
По-друге, трохи обережно з термінами. Дуже часто терміни "store" та "state" використано один замість іншого. Це не дуже впливає на загальну суть, але на рівні коду різниця ключова. Посилання на "store" ніколи не змінюється, на відміну від посилання на "state", яке в ідеалі змінюється при кожному диспатчі.
По-третє, власне useSelector та рендери -- це не про Redux, а про React та байдінг редаксу до React (react-redux), то ж тут трохи не зрозуміло в чому саму крихкість редаксу. Але це вже трохи буквоїдство
Комментарии все абсолютно верные)
Когда я пишу сценарии к видео, очень сложно варьировать между совсем правильными четкими формулировками и известными всем словами. Вот иногда так и получается)
Согласен на 100%
Подход с иммутабельностью позволяет экономить на сравнениях состояний, иначе каждый раз приходилось бы делать deepEqual.
А если используются какие-то преобразования, типа filter, то обязательно нужно делать кэширование, с reselect или useMemo.
Вообще, мне кажется, большая часть проблем производительности связана не с самими библиотеками, а с тем, на сколько правильно декомпозируются компоненты.
А какая разница плачу я от дохода или работодатель? Результат один и тот же.
Не совсем так. Есть вероятность, что вы прошли бы курсы за какие-то деньги и никуда не устроились, деньги бы просто сгорели. Тут вам дают бесплатно понять, ваше это или нет. После обучения, на какую зарплату бы вы пошли, хз. Кто то на 40к, кто-то на 50к, кто то найдет вообще стажировку бесплатную на 3 месяца. С этой стороны вам помогут устроиться сразу на максимально возможную вилку. Без их помощи маловероятно, что вы бы устроились, сразу на такую зарплату, таким образом они забирают те деньги, которые вы бы и так не получали, а вы по факту не платили за обучение.
у меня на собесах разрабы часто валятся на таких вещах, хотя позиционируют себя как сеньёры помидоры)
Теперь будут лучше подготовлены) я слышал много отзывов, что по моим видосам готовятся к собесам))
у тебя на собесах - только Ты читаешь с бумажки ))) Удобно ))) Господин Team Leader )))))))))))))))))))))))))) Хотелось бы посмотреть на твой код )
@@starwalker.odessa я честно говоря даже не знаю, что действительно эффективно спрашивать на собесах) все крайне субъективно)
@@starwalker.odessa это скорее тем, кто вместо прочтения доки полностью, читает быстрый старт и считает что хорошо знает библиотеку
@@it-sin9k Я подскажу - гонять разраба (которые не раз горел в танках) по всем темам нет смысла. Я предлагаю программистам - готовиться в рамках заранее составленных тем, которые касаются проекта на который их набирают. Мне, за 15 лет в этом дурдоме, нет смысла запоминать весь этот trash, потому как сообщество каждые 2 года кардинально переодеваются в концепциях. И даже если я прав в том или ином вопросе - составляющие долгостроя от этого не поменяются. Нет смысла ждать заучку который зазубрил manual, мне важно только - сможет ли он достаточно подготовится перед началом проекта, на который его рассматривают.
удивительно, при всем уважении, автор залезает в исходники и действительно глубоко старается разобраться что под капотом react и redux, и вот тут ты ждешь что у автора серьезный подход, но затем автор начинает рассказывать то чего не существует в официальной спецификации о передачах по значению и ссылке..Не знаю как Вас зовут, но интересует честный ответ(я понимаю что хомячки просто млеют от вашего ума и захейтят меня тут,к тому же этот комент вы удалите или не заметите) вопрос- Вам самому как? Вам ,которому важен доскональный подход, неудосужиться залезть в спеку и развенчать мифы!! почему у вас руки не дошли до спеки ecmascript и увидеть что там все передается по ссылке , но никогда по значению? надеюсь на понимание и честный ответ самому себе и возможно работу над ошибками, с той же педантичностью) (еще раз аппеляция к мама.ру, learn.js не подходит, только оф спецификация js)
ps надеюсь буду услышан
Добрый день :)
У вас какой-то негативный опыт общения в комментариях) не думаю, что на вас нападут "блеющие хомячки" или я удалю комментарий) наверное за всю историю канала я удалил 1-2 комментариям, где люди очень грубо обзывались
По поводу передача по ссылке и по значению. У меня уже был тред на эту тему, достаточно длинный получился) Я размышляю об этом может отдельное видео сделать) Но я вообще не отношусь к этому как к большой проблеме. Нас так учат еще с универов и на работе и в интернете продолжают повторять эту мантру. Идея в том, что так проще людям донести мысль, а задача моих роликов как раз донести некую конкретную идею, а не все нюансы всего
У меня были и другие интересные обсуждения, например то, что когда достаю значение из объекта по ключу это быстрее, чем перебирать массив через find. А тред растянулся на много сообщений, что вообще то на С под капотом движка тоже циклом ищет значение, поэтому все что я говорю это не правда
Честно говоря я не знаю исходники движков) и спецификацию не знаю толком) и никогда не говорил, что я в этом разбираюсь) и мне приятно, что вы ждете от меня таких знаний) но их просто нет) если хотите поделиться с подписчиками своим опытом буду очень рад предоставить площадку и ресурсы для создания видео)
Redux toolkit тоже таким страдает ?
конечно :)
это тулкитная "проблема". Если делать через connect, такой шняги нет.
ну здрасте, конечно есть :)
@@it-sin9k немного не так выразился. В коннектах люди обычно вменяемые редьюсеры пишут, согласно старым паттернам. А тулкиты народ юзает как в примерах написано. А там про второй параметр как-то редко пишут. На выходе имеем что имеем.
@@kronatankristof8804 Как по мне мало что изменилось) кто плохо писал, то так же и пишет, а кто старался тот и по прежнему старается)
Опять редакс 😢
Закончим с ним будем дальше рассматривать стейт менеджеры)
не существует никаких сравнений по ссылке и по значению, только по ссылке. вот это "загуглите" - как раз то, почему в джс постоянно из уст в уста передаются мифы и тупые глупости.
Если просветите как это работает, буду очень признателен))
@@it-sin9k в джсе все передается по референсу на референс. это можете прочитать где-нибудь на 2ality и некоторые блоги содержат сообщения разработчика джс брендона эйха. передача объекта и примитивного значения происходит одинаково. существуют данные в памяти или создаются, var a = "abc" - это несколько выражений, где "abc" и "a" являются оба ссылками на данные-объект типа строка в рантайме. когда мы передаем объект, то мы делаем то же самое. передаем ссылку на объект. а его структура - это лишь одно из проперти объекта в представлении рантайма. мы изменяем именно это поле, сама ссылка на объект сохраняется. у примитивных значения другой поведение. когда мы используем какие-либо операторы, например сложение, то мы получаем выражения, которые в сумме возвращают нам новое примитивное значение. остальное только явными примерами я бы показал лично, но вряд ли нам это нужно. почитайте про флаг --allow-natives-syntax, д8, jsvu, %DebugPrint %DebugPrintPtr и станет намного яснее.
звучит все разумно :)
Вопрос только в следующем
var a = 'abc'
var b = 'abc'
это 2 разных объекта типа строка, и когда мы сравниваем 2 разных объекта через ===. И это сравнение возвращает true. Как это описать как не сравнение по значению?
@@it-sin9k нет, как раз и а, и б - в этом случае - это ссылки на объект типа строка в памяти. поэтому, когда мв сравниваем а с б, то мы сравниваем 0х04fa37be === 0x04fa37be и получаем тру. просто поведение объектов налл/андефайнд/число/строка и так далее - иное, нежели у обычного объекта. то естт, это такие объекты, которые отдают свое значение, а не структуру.
То есть, в случае общего выражения var a = "abc" выражение "abc" создает константную строку в хипе. иммутабельную. потом выражение в ответ отдает нам референс на эту строку. она уже есть, правильно? и, если она иммутабельна и константна, то зачем нам копия этой строки? не за чем. поэтому var b = "abc" - он находит уже эту строку в памяти и просто отдает тот же адрес) и связывает его с б. а потом при строгом сравнении сравниваем два одинаковых адреса
> и, если она иммутабельна и константна, то зачем нам копия этой строки? не за чем. поэтому var b = "abc" - он находит уже эту строку в памяти и просто отдает тот же адрес) и связывает его с б. а потом при строгом сравнении сравниваем два одинаковых адреса
т.е. идея в том, что при создании одинаковой строки, оно находит, что такая строка уже создана и использует ту же ячейку в памяти? Звучит как достаточно дорогая операция для огромного проекте. А есть подтверждение где то такому поведению?
Господа, а вам не кажется что вся эта шляпа от того, что кто-то внедрил моду на функциональное программирование? К примеру если React программу реализовать на классах + FLUX (подписка только на однопоточное событие, которое нас интересуют (предшественник redux)) ...да, приложение становится сложнее, ...но работает куда проще чем вся эта современная петрушка с функциональщиной и redux.
вечный холивар... так и до работы с чистым js/html дойти. будет ли быстрее работать? скорее всего - да. но вот скорость разработки...
@@_always_21 Я ничего не говорил про чистый js... тут и на не чистом мало кто нормально программирует. Достаточно найти одно нормальное решение и пользоваться им. event dispatcher store + react === good! ...не вижу проблем отписываться от handler`ов в destructor`е... чем городить все эти hoooooooook`и.
java - вообще не болеет подобными детскими проблемами. Так может лучше писать на java? И переводить его в JavaScript через Web Assemble? ...а не придурошный type script и прочие декорации )
Дякую, за зрозуміло донесену інформацію! Не знаю твого відношення до тієї країни, де я живу, але люди об’єднані одним горем (реактом) заслуговують на спілкування в однакових умовах
Спасибо! Я не понял, что имелось ввиду под фразой "заслуговують на спілкування в однакових умовах". Можете пояснить пожалуйста?
@@it-sin9k Я мав на увазі що попри обставини в світі, я можу дивитися ваше відео і розуміти його як наче ми з однієї країни
@@gitraccoon да, я рад, что мы по прежнему можем коммуницировать на одном языке :) Я честно говоря, вообще во всем мире ввел бы единый язык))) так бы все друг друга чуть лучше бы понимали)
вообще это тупо, зачем мне думать об этом обновлении, почему стм на своем уровне не умеет решить, какой селектор конкретно нужно тригернуть. Ну и в итоге даже если в селекторе не фильтр, а просто новый обьект, ссылка уже не равно, в любом случае тригер, юзать везде реселект выйдет тоже такое себе, нужно без него сделать тест на перфоманс, с ним и уже думать нужен или нет, гемор еще тот
Это видео не про решение ваших проблем, а скорее про более глубокое понимание инструментов, как они работают :)
Отлично разжевал! Спасибо!
Отлично разжевал!
Отлично разжевал 😉
Отлично разжевал! Спасибо!