Хороший доклад. Показывает что хороший программист (инженер) должен думать, а не просто механически писать код. Жаль только , что думать получается, когда есть или большой опыт или обширные знания. А если джуна подгоняют, да и сам он слабо знает основы - будет боль. PS: хороший показательный пример на реакте.
Реакт чем хорош: самый простой путь является самым правильным. Потому что эта парадигма заложена при разработке библиотеки. Код с "наворотами" как правило даст хуже результат, нежели "красиво" разделенный на компоненты. Этому легко следовать с нуля (без необходимости постоянно обращаться к исходникам), но довольно-таки муторно при изменении функционала. Банально лень все переписывать. Большое желание навесить новые "обязанности" на уже существующие компоненты
ruclips.net/video/ze4Qve1azA0/видео.html "если это будет контекст в контексте - все равно все поломается". что это значит? по этой логике, если у нас в приложении есть вложенный контекст (а он как правило есть в большинстве случаев), то они уже не будут правильно ререндерится? или я не понял чего-то?
Возможно я не по той ссылке нажал, может было где-то написано что это для "новичков". Смотрел с facepalm-ом на перемотке. У тебя компонент имеет состояние N, так вынеси это в отдельный компонент Clicker, пусть он будет statefull, ререндериться будет только он и его дочерние компоненты, а не весь App. Декомпозируй код - в этом весь смысл WebComponents...
@@SylvanasCry Последний пример. Сделали глобальный контекст. Предложения решения, делите на мини-контексты, но делайте так. Использьзуйте редакс, но лучше не используйте редакс. Используйте математику, которая не работает в этом примере. Ну кароче оставайтесь с приложением, которое постоянно обновляется. Как вариант, по скольку shallow compare не работает, а спред оператором происходит не глубокое копирование. Можно было написать hoc, который берет значения из контекста, и сует их через компонент, где уже будет работать shallow compare. Т.е. обновляется только hoc, но дальше рендер не идет
А в чем суть финала доклада? "Как мы решили проблему с субтитрами? - Мы выкинули реакт, проблему решила математика" - а как проблему решила математика?
@@АртемТерещенко-ц4э Ну как бы в том, что у элементов будет новый хендлер при каждом ре-рендере родительского компонента. Значит, будет ре-рендер такого элемента. Если это одна кнопка, ну, ок.. А если список, где у каждого элемента какой-то onClick/onMouseEnter?.. Для хендлеров есть useCallback (если сам хендлер зависит от состояния) и useGetCallback (и другие) из пакета react-cached-callback
@@sc0or Мемоизировать ивент хендлеры уместно только если ты их передаешь как props другим большим компонентам. В остальных случаях лишний рендер лучше чем проверка мемоизации.
У меня подергиваются оба "глаза" при произношение "редюкс", что там говорит Google => redux[ˌrēˈdəks], или вот еще такое же слово duck[dək], видимо надо "дюк"
Не нужно было думать про Турцию, в этом причина.
ЗЫ. Что за приложение ручка - рисовалка по экрану?
Epic Pen, сразу себе поставил, когда увидел на докладе)
Хороший доклад. Показывает что хороший программист (инженер) должен думать, а не просто механически писать код. Жаль только , что думать получается, когда есть или большой опыт или обширные знания. А если джуна подгоняют, да и сам он слабо знает основы - будет боль. PS: хороший показательный пример на реакте.
Реакт чем хорош: самый простой путь является самым правильным. Потому что эта парадигма заложена при разработке библиотеки. Код с "наворотами" как правило даст хуже результат, нежели "красиво" разделенный на компоненты. Этому легко следовать с нуля (без необходимости постоянно обращаться к исходникам), но довольно-таки муторно при изменении функционала. Банально лень все переписывать. Большое желание навесить новые "обязанности" на уже существующие компоненты
ruclips.net/video/ze4Qve1azA0/видео.html
"если это будет контекст в контексте - все равно все поломается". что это значит? по этой логике, если у нас в приложении есть вложенный контекст (а он как правило есть в большинстве случаев), то они уже не будут правильно ререндерится? или я не понял чего-то?
Орнул, стебать реактеров на реакт конференции это прям в голос.
Не ори, ночь на дворе.
Возможно я не по той ссылке нажал, может было где-то написано что это для "новичков". Смотрел с facepalm-ом на перемотке. У тебя компонент имеет состояние N, так вынеси это в отдельный компонент Clicker, пусть он будет statefull, ререндериться будет только он и его дочерние компоненты, а не весь App. Декомпозируй код - в этом весь смысл WebComponents...
Какой-то сумбурный доклад. А итоговое решение без как такого решения
@@SylvanasCry Последний пример. Сделали глобальный контекст. Предложения решения, делите на мини-контексты, но делайте так. Использьзуйте редакс, но лучше не используйте редакс. Используйте математику, которая не работает в этом примере. Ну кароче оставайтесь с приложением, которое постоянно обновляется.
Как вариант, по скольку shallow compare не работает, а спред оператором происходит не глубокое копирование. Можно было написать hoc, который берет значения из контекста, и сует их через компонент, где уже будет работать shallow compare. Т.е. обновляется только hoc, но дальше рендер не идет
Следить за лишними рендерами очень важно. благодарю Елену
спс за доклад. чет удивился что решение таким оказалось))
Ваша математика довольно распространёный подход рендера бесконечных списков элементов реализован в ReactVirtualized и множестве ему подобных библиотек
Блин я бы слушал её вечно 😘😘😘
А в чем суть финала доклада? "Как мы решили проблему с субтитрами? - Мы выкинули реакт, проблему решила математика" - а как проблему решила математика?
Кайфонул от доклада. Спасибо!
Что за «математика» такая, которую Лена вспоминает каждый раз когда вспоминает ошибки использования React?
O(n)
она под солью?
супер,я в восторге!:)
Умная женщина, не смотря на лямки "POHUY", ей до проектов дело все же есть
Ок, буду тренировать в себе Лену :))))
Спасибо)
А это приемлимо: рассказывать об оптимизации и использовать inline handlers в обработчиках UI событий везде?
В чем проблема?
@@АртемТерещенко-ц4э Ну как бы в том, что у элементов будет новый хендлер при каждом ре-рендере родительского компонента. Значит, будет ре-рендер такого элемента. Если это одна кнопка, ну, ок.. А если список, где у каждого элемента какой-то onClick/onMouseEnter?.. Для хендлеров есть useCallback (если сам хендлер зависит от состояния) и useGetCallback (и другие) из пакета react-cached-callback
@@sc0or Мемоизировать ивент хендлеры уместно только если ты их передаешь как props другим большим компонентам. В остальных случаях лишний рендер лучше чем проверка мемоизации.
@@АртемТерещенко-ц4э если твоя мемоизация замемоизирует хотя бы 1 рендер из 10 - он выгоден . Смотри ит синяка
Зачем паясничать то?
Нормально у неё там на лямках написано "похую")
это похуюди
С Реактом и не такую лямку приходится тянуть )))
У меня подергиваются оба "глаза" при произношение "редюкс", что там говорит Google => redux[ˌrēˈdəks], или вот еще такое же слово duck[dək], видимо надо "дюк"
занудство, как оно есть
@@jelooJusta Я думаю девушка просто троллит до конца))
Крутой доклад, спасибо)
Огнище!
О_о
А че Array.from({length:10},(_,idx)=>idx) для слабоков
🔥
худи бесподобная на Елене =D
Блин, только заметил ее подтяжи )
редюкс)))
Ля какая
Нах... это нужно?)))
Реакт такий ))
Нах!
Отправьте ее лучше на кухню)
После того, как ты пойдешь в армию :)
Спасибо)