новичкам трудно понять зачем нужен useDeferredValue если можно написать debounce. Разница в том, useDeferredValue будет задерживать значения в зависимости от возможностей железа пользователя. На быстром будет срабатывать быстро а на слабом медленнее подстраиваясь под рендер каждого девайса. Т.е не нужен хардкод таймаута.
С другой стороны, uDV будет нагружать машину пользователя, тратить киловатты (эффект масштаба) на пустые обсчеты и тем самым увеличивая углеродный след. Как бы нам зелёные звиздюлей не дали за такую оптимизацию 😂
Автор, ты так и не сделал одно очень важное замечание: Поскольку реакт отбрасывает те рендеры, которые он не успевает, если новые изменения происходят до окончания рендера, то мы увидим следующий рендер только когда поток изменений будет содержать достаточно большую паузу, чтоб ререндер успел успешно завершиться. Эта особенность делает данный подход неприемлемым как раз в тех случаях, о которых ты упомянул, а именно на 3:33. Если поток данных будет продолжаться непрерывно, то может возникнуть ситуация, что на рендер не будет хватать времени вообще никогда. И пользователь вообще не будет видеть обновлений. Правильным решением было бы делать ререндеры по мере их фактической возможности один за другим и не отменять рендеры при появлении новых изменений. При этом данные под каждый рендер-колл брать на момент получения заявки на этот рендер-колл. Как было: каждое изменение порождало свой рендер-колл, и блочило движок до окончания ререндера Как сейчас: каждое изменение порождает новый рендер-колл асинхронно, и если ререндер уже производится, то отменяет устаревший ререндер Как нужно: каждое изменение инвалидирует состояние, что является триггером для создания нового рендер-колла рендер-коллы выполняются в отдельном потоке один за другим, не блоча движок, и нет механизма отмены старого "устаревшего" рендер-колла.
Они как то рассказывали, что тестировали варианты использования соседних потоков для разгружения основного, но насколько я помню, это слишком медленно работало и отказались
Отличия от debounce: 1. Юзер увидит конечную картинку раньше, т.к. useDeferredValue начинает её рендерить сразу, а не после таймаута. 2. Не будет фризов в инпуте с какой бы скоростью юзер не печатал. С debounce юзер может попадать в просак между срабатыванием таймера и окончанием рендера. 3. Потенциально больше жрёт процессор.
И по сути вопроса. В чем наша проблема? Есть какая-то синхронная задача, которая тормозит рендер. Напрашивается логичное решение - сделать ее асинхронной; а если надо - то и обернуть внутри все в дебаунс или тротлинг, и затем уже изнутри асинхронной задачи обновлять стейт реакта, чтобы вызвать ререндер. Но создатели реакта почему-то не топятся показать всем идиоматичными примерами как надо делать в том или ином случае (включая наш), а спешат добавить новый костыль, который - как оказывается из данного видео - еще и ломает поведение уже знакомых API реакта. Браво, еще!..
Пасип, некогда даже новые фичи посмотреть, не то что их попробовать и уж тем более сразу пускать в прод. Однако какие бы и сколь сложные интерфейсы я не делал, всегда тем не менее обходился дебаунсером. Но смысл я уловил. Дебаунсер ты хардкодиш тайминги, а тут энжин сам смотрит может ли он схавать поток или нет. Однако...
Получается основное преимущество, что зависит от мощности железа, а не от захардкоженной цифровой в setTimeot. Но как же все быть, если летит бесконечный поток данных в сокете?
useDeferredValue хуже чем любая реализация сигналов. Нафиг он нужен, не очень понятно. По капотом этот хук использует Promise.reject, чтобы сигнализировать об асинхронном процессе + лишний рендер для каждого изменения. При использовании сигналов, будет только один рендер. Update: Написал комментарий не посмотрев видео, думал будет речь про связку useDeferredValue + use, а тут про SlowList. Безусловно, для SlowList useDeferredValue полезен.
Update: Написал комментарий не посмотрев видео, думал будет речь про связку useDeferredValue + use, а тут про SlowList. Безусловно, для SlowList useDeferredValue полезен.
Как то сомнительно выглядит. Все время такие проблемы решались с debounce. А что теперь? Нагружаем процессор бесполезными вычислениями и тратим заряд батареи на устройствах только ради того, что бы чуть более точно подобрать задержку debounce
Вообще фича полезная для отображения данных, приходящих с сервера. Если рендер в основном задерживают асинхронные запросы, то там высокой нагрузки не будет. Но вот с такими кейсами, как тяжёлые вычисления на фронте, она действительно может привести к лишней трате заряда
@@Lear-fe6se А что принципиально поменяется если с сервера будут данные приходить, а не из инпута? С сервером по идее вообще проблем не должно быть, вряд ли вы будете присылать обновления с сервера с настолько высокой частотой, что интерфейс не будет успевать рендериться.
@@Chuv111 нет, я другую ситуацию представляю: Данные получаем из инпута, но рендер у нас медленный не потому, что нужно отрисовать таблицу с миллионом строк, а потому что нужно отправить запрос на сервер и дождаться ответа. В таком случае useDefferedValue не нагрузит клиентское устройство, но отзывчивость повысится в сравнении с debounce. Да, нагрузка на сервер может увеличиться. Но это не так критично, как для клиента. Плюс отправленные запросы можно отменять
@@it-sin9k Я пытаюсь понять в каких случаях useDeferredValue будет лучшим выбором. Так то фича выглядит интересно, но пример в видео выбран не очень удачно. Единственный плюс, который мне приходит в голову, это то что не надо свой хук для debounce писать и придумывать значение задержки. Про минусы я уже написал
![อิสราเอลโดนอิหร่านถล่มหนักกว่าที่คุย : [คุยผ่าโลก worldtalk]](http://i.ytimg.com/vi/R8gIN-MQhWw/mqdefault.jpg)
новичкам трудно понять зачем нужен useDeferredValue если можно написать debounce. Разница в том, useDeferredValue будет задерживать значения в зависимости от возможностей железа пользователя. На быстром будет срабатывать быстро а на слабом медленнее подстраиваясь под рендер каждого девайса. Т.е не нужен хардкод таймаута.
Хорошо сказано!)
С другой стороны, uDV будет нагружать машину пользователя, тратить киловатты (эффект масштаба) на пустые обсчеты и тем самым увеличивая углеродный след. Как бы нам зелёные звиздюлей не дали за такую оптимизацию 😂
спасибо за выпуск, очень интересно было послушать, как можно использовать useDeferredValue и что твориться под копотом
Автор, ты так и не сделал одно очень важное замечание:
Поскольку реакт отбрасывает те рендеры, которые он не успевает, если новые изменения происходят до окончания рендера, то мы увидим следующий рендер только когда поток изменений будет содержать достаточно большую паузу, чтоб ререндер успел успешно завершиться.
Эта особенность делает данный подход неприемлемым как раз в тех случаях, о которых ты упомянул, а именно на 3:33. Если поток данных будет продолжаться непрерывно, то может возникнуть ситуация, что на рендер не будет хватать времени вообще никогда. И пользователь вообще не будет видеть обновлений.
Правильным решением было бы делать ререндеры по мере их фактической возможности один за другим и не отменять рендеры при появлении новых изменений. При этом данные под каждый рендер-колл брать на момент получения заявки на этот рендер-колл.
Как было:
каждое изменение порождало свой рендер-колл, и блочило движок до окончания ререндера
Как сейчас:
каждое изменение порождает новый рендер-колл асинхронно, и если ререндер уже производится, то отменяет устаревший ререндер
Как нужно:
каждое изменение инвалидирует состояние, что является триггером для создания нового рендер-колла
рендер-коллы выполняются в отдельном потоке один за другим, не блоча движок, и нет механизма отмены старого "устаревшего" рендер-колла.
Они как то рассказывали, что тестировали варианты использования соседних потоков для разгружения основного, но насколько я помню, это слишком медленно работало и отказались
супер ролик! Синяк как всегда на высоте!
Шикарный выпуск!!! Помог аккуратно решить проблему)
Автору искренняя благодарность за ролики. На собесе благодаря Вашему ролику про react key отличился знанием.
Пожалуйста, продолжайте в том же духе
хех) очень рад, что видео оказались полезными) не раз слышал, что люди по ним готовятся к собеседовниям) значит все не зря)
Спасибо, теперь буду знать, что можно не костылить дебаунсом
спасибо дорогой
Отличия от debounce:
1. Юзер увидит конечную картинку раньше, т.к. useDeferredValue начинает её рендерить сразу, а не после таймаута.
2. Не будет фризов в инпуте с какой бы скоростью юзер не печатал. С debounce юзер может попадать в просак между срабатыванием таймера и окончанием рендера.
3. Потенциально больше жрёт процессор.
Супер! Спасибо за контент. Полезно!
Шо, опять?.. )))
(За видео - лайк! Коммент скорее к разработчикам реакта.)
И по сути вопроса. В чем наша проблема? Есть какая-то синхронная задача, которая тормозит рендер. Напрашивается логичное решение - сделать ее асинхронной; а если надо - то и обернуть внутри все в дебаунс или тротлинг, и затем уже изнутри асинхронной задачи обновлять стейт реакта, чтобы вызвать ререндер. Но создатели реакта почему-то не топятся показать всем идиоматичными примерами как надо делать в том или ином случае (включая наш), а спешат добавить новый костыль, который - как оказывается из данного видео - еще и ломает поведение уже знакомых API реакта. Браво, еще!..
Спасибо Синяк! Как всегда круто и доступно объяснил!
Спасибо за слова поддержки!)
❤как всегда очень круто!
Привет Саш, спасибо за видео!
Спасибо, было полезно)
Спасибо, любопытная штука.
Отлично 🔥
благодарю!
Это очень круто!
useDeferredValue полезен в связке с (будущим) хуком use, для реализации асинхронного состояния. Но, опять же, реализация на сигналах будет лучше.
Пасип, некогда даже новые фичи посмотреть, не то что их попробовать и уж тем более сразу пускать в прод. Однако какие бы и сколь сложные интерфейсы я не делал, всегда тем не менее обходился дебаунсером. Но смысл я уловил. Дебаунсер ты хардкодиш тайминги, а тут энжин сам смотрит может ли он схавать поток или нет. Однако...
с ума сойти! спасибо
Получается основное преимущество, что зависит от мощности железа, а не от захардкоженной цифровой в setTimeot. Но как же все быть, если летит бесконечный поток данных в сокете?
как и с debounce это будет ждать момента, когда хоть на момент поток данных прервется
Точно предыдущий результат "выбрасывается на помойку"? Планировщик реакта как раз имеет механизм переиспользовать предыдущую работу
useDeferredValue хуже чем любая реализация сигналов. Нафиг он нужен, не очень понятно.
По капотом этот хук использует Promise.reject, чтобы сигнализировать об асинхронном процессе + лишний рендер для каждого изменения. При использовании сигналов, будет только один рендер.
Update: Написал комментарий не посмотрев видео, думал будет речь про связку useDeferredValue + use, а тут про SlowList.
Безусловно, для SlowList useDeferredValue полезен.
о каких именно сигналах в рамках React идет речь?
почему при использовании сигналов будет только один рендер? Будет так же рендер на каждое изменение инпута. Но рендер будет более атомарным
@@it-sin9k я для себя сделал собственную реализацию. А так, погуглите. Любая реализация сигналов у которой есть хук useSignal подойдёт.
Update: Написал комментарий не посмотрев видео, думал будет речь про связку useDeferredValue + use, а тут про SlowList.
Безусловно, для SlowList useDeferredValue полезен.
Как то сомнительно выглядит. Все время такие проблемы решались с debounce. А что теперь? Нагружаем процессор бесполезными вычислениями и тратим заряд батареи на устройствах только ради того, что бы чуть более точно подобрать задержку debounce
Вообще фича полезная для отображения данных, приходящих с сервера. Если рендер в основном задерживают асинхронные запросы, то там высокой нагрузки не будет.
Но вот с такими кейсами, как тяжёлые вычисления на фронте, она действительно может привести к лишней трате заряда
если вы хотите использовать debounce это же не проблема) выбирайте инструмент, который вам нравится :)
@@Lear-fe6se А что принципиально поменяется если с сервера будут данные приходить, а не из инпута? С сервером по идее вообще проблем не должно быть, вряд ли вы будете присылать обновления с сервера с настолько высокой частотой, что интерфейс не будет успевать рендериться.
@@Chuv111 нет, я другую ситуацию представляю:
Данные получаем из инпута, но рендер у нас медленный не потому, что нужно отрисовать таблицу с миллионом строк, а потому что нужно отправить запрос на сервер и дождаться ответа.
В таком случае useDefferedValue не нагрузит клиентское устройство, но отзывчивость повысится в сравнении с debounce. Да, нагрузка на сервер может увеличиться. Но это не так критично, как для клиента. Плюс отправленные запросы можно отменять
@@it-sin9k Я пытаюсь понять в каких случаях useDeferredValue будет лучшим выбором. Так то фича выглядит интересно, но пример в видео выбран не очень удачно. Единственный плюс, который мне приходит в голову, это то что не надо свой хук для debounce писать и придумывать значение задержки. Про минусы я уже написал
1ый😎
Мля, я второй
По итогу весь maintread забит реактовскими бесполезными вычислениями с 0 результатом. Ммм, вкуснятина
Так они и до этого были бесполезными, только из ещё больше было
@@corvus278 До этого юзали debounce с фиксированой задержкой, и никаких лишних вычислений не было
@@corvus278 там в промежутке хоть что-то выводилось в процессе ввода
использование debounce никто не отменял :)