Включил синяка перед работой под кофе. Такое ощущение, что перед школой мультики смотрю) Хорошую вижимку делаешь, в расслабленой мультяшной форме мне заходит на все 100
[14:13 ] Пожалуй это сгодится для анимаций. Например легко сделать анимацию появления, но чтобы сделать какой-нибудь фейд-аут приходится либы для анимаций подключать, либо морочиться самому с тем чтоб фейд-аут отработал до того как компонент целиком не был убран из дома. Спасибо за видос, актуально)
Хуки форм выглядят интересно, но не уверен что их можно будет использовать в сложных формах где поля ввода могут зависеть от значений других поля ввода. Именно в таких формах особенно хочется какой-то оптимизации кода. Также непонятно что там с типизацией состояния. В тех же кастомных selectах можно реализовывать довольно удобные схемы когда value не является строкой, сохраняя при этом тип в onChange. При отправке на сервер данных в виде json, не form-data - это весьма удобно. Посмотрим. Вообще не понял какую задачу они предлагают решать через use(). Разруливание race condition, конечно, штука полезная, но не таким способом. Тяжелые запросы тупо заспамят сервер. Еще и кешировать промис нужно во внешнем компоненте. Выглядит не особо полезно. Разве что использование внутри if интересное, но у меня ощущение что use - не хук, а простая функция, из-за чего промис и требуется кешировать где-то. Изменения ref порадовали - наконец-то этот головняк с forwardRef решится! Я больше жду компилятор, если будет работать нормально, то можно будет сильно меньше кода писать и меньше думать о том о чем не очень-то хочется думать.
да вообще не понятно зачем нам хуки для форм когда есть React Hook Form, проще было бы интегрировать эту библиотеку, раз они для чего то добавили эти хуки
Мне нравится желание разработчиков добавить новые хуки. Только скорее всегда многие из них окажутся ситуативными поводами похвастаться для гиков. Для остальных разработчиков это будут фичи из разряда "можно, но не нужно"
Если какие-то хуки (т.е. use()) можно будет использовать в кондишинах, а какие-то нет - это же прямой путь к дичайшему говнокоду. Реакт все дальше и дальше прирастает костылями со всех сторон, и превращается из когда-то простой в использовании библиотеки с классной идеей - UI = f(state) - в какого-то франкельштейна...
Ограничение хуков на использование без условий обусловленно технически, для получения предыдущего состояния, контекст и промис сами являются идентификаторами, поэтому их можно использовать и без этого искусственного ограничения, однако ассинхронное использование все равно должно быть недоступно. Не сказать что часто, но бывают случаи когда контекст нужен не всегда, возможно с промисами нужно будет чаще. К тому же хуки сами по себе ломали принцип чистой функции.
@@_boolive_ Разработчики Реакта просто двигаются в какую-то неопределенную сторону. То есть, непонятно, решают они какие-то специфические задачи Фейсбука, или стараются решить какие-то задачи сообщества - и при этом они особо и не раскрывают своих планов. В итоге выглядит как какие-то попытки переизобрести уже работающие и хорошо отлаженные вещи типа REST и RPC, которые к тому же применимы в огромном кол-ве кейсов, а не просто для отрисовки фронтенда. Но пока получается так себе - "без внятного ТЗ результат на выходе - ХЗ..."
useOptimistic - хук с сомнительной полезностью. Кейс: стена с записями, листаю, оставляю лайки. На очередной записи ткнул лайк (читай - добавил в избранное), useOptimistic отработал и я вижу что поставил лайк, листаю дальше и тут оказывается, что по какой-то (любой) причине запрос на сервер не прошел или вернулась ошибка. Как итог - я уверен, что запись добавлена в избранное, однако как только я зайду в избранное - этой записи не будет. 🤷♂ Две стороны медали.. с точки зрения UX - гуд, но для DX - придется точно также обрабатывать кейс неудачным добавлением в избранное (как-то уведомить пользователя).
Немного не понял, в чем особенность useOptimistic. Выглядит как обычный useState. Почему нужно использовать именно новый хук? Или там в перерисовках дело?
Немного расстраивает тот факт, что для хука use как и для Suspense/Error Boundary нужно выносить логику обработки на уровень выше. Не совсем понимаю как архитектурно красиво писать код с этим. Как по мне логика const { data, error, isLoading } = useQuery(...) намного удобнее.
12:15 - ни один запрос не отменился и фраза "Проблемы решены из коробки" 😵💫 🤯 возникают вопросы... Ладно, делаем скидку, что решены только проблемы рендера последнего ответа, остальное - проблемы негров )
Интересно, как внутри работает use, чтобы дальше не продолжался рендер. Вероятнее всего yield стоит какой-нибудь. По ощущениям, очередной черный ящик, использование которого без понимания внутренностей реакта может привести к сюрпризам.
лучше не знать... use кидает exception а Suspense его ловит, можно обернуть use в try-catch и увидеть что он кидает ошибку и там будет ворнинг что не нужно оборачивать use в try-catch. Получается что лучше всего use выносить в самый верх компонента, иначе все что до него будет лишний раз исполнятся
еще, честно говоря, я не совсем понимаю в чем сакральный смысл запрета на использование async function компонентов, почему не добавят такую возможность и для клиентских компонентов
@@Владимир.П-е9о точно не знаю, наверное как именно ErrorBoundary работает, может ErrorBoundary должен заново кидает исключение если оно пришло из Suspense
Ты говоришь про старую эпоху двух компонентов Container + View, а какие сейчас видишь новые и эффективные подходы к решению вопроса по разделению бизнес логики и переиспользуемых UI компонентов?
абстракция, если ты хочешь один набор компонентов использовать в куче разных логик, такое себе решение, ибо бизнес логика не всегда совпадает, а часто в мелочах различие которое и не позволит
Один гитарист приходит в магазин, покупает любую гитару за свои деньги и идет делать музыку. Другой - бесконечно изучает, как ясень или клен влияет на звук, какая накладка на гриф лучше, как материал верхнего порожка способен выделить средние частоты. При этом не создавая никаких музыкальных произведений. Во фронтенд-разработке больше всего раздражает тенденция к тому, что все мы должны быть этим вторым гитаристом, чтобы успеть за прогрессом. Вместо того, чтобы просто делать сайты, приходится большую часть времени посвящать изучению инструментария. Самое фиговое, что это все будут спрашивать на собесах и делать выводы о разработчике - а использовал ли он новые хуки из реакт19-25-50, а работал ли с новой библиотекой компонентов с революционным подходом к теням на инпутах, и т.д. Подавляющее большинство веб-приложений - это несложный CRUD, и делать его можно на чем угодно. А все эти нововведения - это самовыражение безусловно крутых разрабов из реакт-команды, которым скучно делать сайты, поэтому они работают над тем, чтобы не заскучали прикладные разрабы. Но проблема в том, что я и не думал скучать, и хочу просто делать продукт и совершенствовать свой код - не применением новых либ, а применением новых подходов в парадигме и архитектуре. Я люблю изучать новое, но не из разряда "теперь вот эту функцию пишем вот так, а это прописываем сюда". В этом нет по факту ничего нового. Но мыслительного ресурса и времени это бесконечно пережеванное старое, выдаваемое за революционное новое, отжирает прилично. PS. Это не наезд на автора, канал люблю и смотрю постоянно. Просто высказался о наболевшем.
@@it-sin9k ага, было стабильным) верю а весь этот ssr хайп наверное только добавил стабильности, и react к этому не имеет никакого отношения, тупа случайно рекламируя next на своём сайте
По поводу ref cleanup это было можно делать и раньше. Если вешать callbackRef на элемент то при удалении элемента колбэк вызовется с null в качестве node и мы можем почистить event listeners на этом элементе к примеру. И по поводу use а также useContext они не зависят от порядка объявления а только от ближайшего провайдера. Чисто технически и useContext можно было в if пихнуть, но решили оставить warn из-за consistency что ли
Думаю clean up нужен больше для того, чтобы избежать использование внешних состояний, наверняка null все так же будет прилетать, иначе много чего поломается.
Если коммент наберет 1000 лайков буде обзор версии 18.3!
лайкайте этот коммент ребята!!😅
Включил синяка перед работой под кофе. Такое ощущение, что перед школой мультики смотрю)
Хорошую вижимку делаешь, в расслабленой мультяшной форме мне заходит на все 100
круто!) спасибо! всем мультики!
Что-то я где-то это уже видел... ах да, привет Next js
[14:13 ] Пожалуй это сгодится для анимаций. Например легко сделать анимацию появления, но чтобы сделать какой-нибудь фейд-аут приходится либы для анимаций подключать, либо морочиться самому с тем чтоб фейд-аут отработал до того как компонент целиком не был убран из дома.
Спасибо за видос, актуально)
Шикарно! просто и доступно как и во всех остальных видео, спасибо!
Спасибо большое за поддержку!)
Просто огонь , лучшее пояснение, которое я видел, спасибо!
Спасибо большое за поддержку!)
Хуки форм выглядят интересно, но не уверен что их можно будет использовать в сложных формах где поля ввода могут зависеть от значений других поля ввода. Именно в таких формах особенно хочется какой-то оптимизации кода. Также непонятно что там с типизацией состояния. В тех же кастомных selectах можно реализовывать довольно удобные схемы когда value не является строкой, сохраняя при этом тип в onChange. При отправке на сервер данных в виде json, не form-data - это весьма удобно. Посмотрим.
Вообще не понял какую задачу они предлагают решать через use(). Разруливание race condition, конечно, штука полезная, но не таким способом. Тяжелые запросы тупо заспамят сервер. Еще и кешировать промис нужно во внешнем компоненте. Выглядит не особо полезно. Разве что использование внутри if интересное, но у меня ощущение что use - не хук, а простая функция, из-за чего промис и требуется кешировать где-то.
Изменения ref порадовали - наконец-то этот головняк с forwardRef решится!
Я больше жду компилятор, если будет работать нормально, то можно будет сильно меньше кода писать и меньше думать о том о чем не очень-то хочется думать.
да вообще не понятно зачем нам хуки для форм когда есть React Hook Form, проще было бы интегрировать эту библиотеку, раз они для чего то добавили эти хуки
Мне нравится желание разработчиков добавить новые хуки. Только скорее всегда многие из них окажутся ситуативными поводами похвастаться для гиков. Для остальных разработчиков это будут фичи из разряда "можно, но не нужно"
Похвастаться для гиков и темы для обсудить на собеседованиях. "Какие хуки реакта вы знаете, но никогда не применяли в своих проектах?"
Прикольно, но про ref я бы упомянул бы еще тот факт, что мало того, что ref можно пропом передавать просто, так еще и HOC forward не нужен
Если какие-то хуки (т.е. use()) можно будет использовать в кондишинах, а какие-то нет - это же прямой путь к дичайшему говнокоду. Реакт все дальше и дальше прирастает костылями со всех сторон, и превращается из когда-то простой в использовании библиотеки с классной идеей - UI = f(state) - в какого-то франкельштейна...
Ограничение хуков на использование без условий обусловленно технически, для получения предыдущего состояния, контекст и промис сами являются идентификаторами, поэтому их можно использовать и без этого искусственного ограничения, однако ассинхронное использование все равно должно быть недоступно. Не сказать что часто, но бывают случаи когда контекст нужен не всегда, возможно с промисами нужно будет чаще. К тому же хуки сами по себе ломали принцип чистой функции.
с такими же мыслями воспринимаю все эти обновления. И какие-то неполноценные они.
@@_boolive_ Разработчики Реакта просто двигаются в какую-то неопределенную сторону. То есть, непонятно, решают они какие-то специфические задачи Фейсбука, или стараются решить какие-то задачи сообщества - и при этом они особо и не раскрывают своих планов. В итоге выглядит как какие-то попытки переизобрести уже работающие и хорошо отлаженные вещи типа REST и RPC, которые к тому же применимы в огромном кол-ве кейсов, а не просто для отрисовки фронтенда. Но пока получается так себе - "без внятного ТЗ результат на выходе - ХЗ..."
useOptimistic - хук с сомнительной полезностью. Кейс: стена с записями, листаю, оставляю лайки. На очередной записи ткнул лайк (читай - добавил в избранное), useOptimistic отработал и я вижу что поставил лайк, листаю дальше и тут оказывается, что по какой-то (любой) причине запрос на сервер не прошел или вернулась ошибка. Как итог - я уверен, что запись добавлена в избранное, однако как только я зайду в избранное - этой записи не будет. 🤷♂
Две стороны медали.. с точки зрения UX - гуд, но для DX - придется точно также обрабатывать кейс неудачным добавлением в избранное (как-то уведомить пользователя).
ага и потом опять скролить наверх и искать где ты там не проставил
Заходит мультяшный стиль
круто!) это упрощает нам выпуск роликов)
надо было называть
Немного не понял, в чем особенность useOptimistic. Выглядит как обычный useState. Почему нужно использовать именно новый хук? Или там в перерисовках дело?
думаю во внутрянке дело, высокий приоритет рендера, через startTransition и все такое
@it-sin9k, не хочешь приехать в Ульяновск на Улкемп в июле, с каким-нибудь докладом по реакту?
я к сожалению пока не выездной из Польши, жду получения документов и если выеду обратно въехать не смогу :(
❤❤❤🎉🎉🎉
Когда появится реакт компайлер сможем ли бы делать computed property как во vue?
хмм, не думаю. А зачем?
Немного расстраивает тот факт, что для хука use как и для Suspense/Error Boundary нужно выносить логику обработки на уровень выше.
Не совсем понимаю как архитектурно красиво писать код с этим.
Как по мне логика const { data, error, isLoading } = useQuery(...) намного удобнее.
согласен) по мне эта концепция не очень бьется.
Из полезного: обновление рефа, контекста. Всё остальное бесполезный хлам...
Стоп, а если внутри useActionState вызвать исключение ?
Для реальных проектов мне для форм нужна функция валидации
да, я так понимаю они тоже хотят либо нативную чтобы мы использовали, либо уже внутри хука допиливали валидацию
12:15 - ни один запрос не отменился и фраза "Проблемы решены из коробки" 😵💫 🤯 возникают вопросы... Ладно, делаем скидку, что решены только проблемы рендера последнего ответа, остальное - проблемы негров )
Интересно, как внутри работает use, чтобы дальше не продолжался рендер. Вероятнее всего yield стоит какой-нибудь. По ощущениям, очередной черный ящик, использование которого без понимания внутренностей реакта может привести к сюрпризам.
лучше не знать... use кидает exception а Suspense его ловит, можно обернуть use в try-catch и увидеть что он кидает ошибку и там будет ворнинг что не нужно оборачивать use в try-catch. Получается что лучше всего use выносить в самый верх компонента, иначе все что до него будет лишний раз исполнятся
еще, честно говоря, я не совсем понимаю в чем сакральный смысл запрета на использование async function компонентов, почему не добавят такую возможность и для клиентских компонентов
@@dimap6793 выходит если между suspense и use будет ErrorBoundary, то финт не сработает?)
@@Владимир.П-е9о точно не знаю, наверное как именно ErrorBoundary работает, может ErrorBoundary должен заново кидает исключение если оно пришло из Suspense
в данном примере что мешает вместо useOptimistic использовать useState ?
думаю оптимизации рендеров. Там вероятно под капотом используется еще transition хук для поднятия приоритета
Как юзал antd form так и продолжу. Лучшая форма
расскажешь
солгласен антд топчик
компайлера не будет на релизе =(
action и форма вместе в одном серверном компоненте работают? т.е. перед формой не нужно вставлять директиву use client?
Вы точно импортировали useFormStatus из react-dom?
точно нет )) походу из react-а пробовал
т.к. в react-dom работает на 100%
вот блин, я брал его из react o_O
Ты говоришь про старую эпоху двух компонентов Container + View, а какие сейчас видишь новые и эффективные подходы к решению вопроса по разделению бизнес логики и переиспользуемых UI компонентов?
абстракция, если ты хочешь один набор компонентов использовать в куче разных логик, такое себе решение, ибо бизнес логика не всегда совпадает, а часто в мелочах различие которое и не позволит
Чем дальше, тем больше React превращается в говно. А от ref норм
ruclips.net/video/XOA3HKXPSN0/видео.html
для очистки таймаутов и интервалов
Один гитарист приходит в магазин, покупает любую гитару за свои деньги и идет делать музыку. Другой - бесконечно изучает, как ясень или клен влияет на звук, какая накладка на гриф лучше, как материал верхнего порожка способен выделить средние частоты. При этом не создавая никаких музыкальных произведений.
Во фронтенд-разработке больше всего раздражает тенденция к тому, что все мы должны быть этим вторым гитаристом, чтобы успеть за прогрессом. Вместо того, чтобы просто делать сайты, приходится большую часть времени посвящать изучению инструментария. Самое фиговое, что это все будут спрашивать на собесах и делать выводы о разработчике - а использовал ли он новые хуки из реакт19-25-50, а работал ли с новой библиотекой компонентов с революционным подходом к теням на инпутах, и т.д.
Подавляющее большинство веб-приложений - это несложный CRUD, и делать его можно на чем угодно. А все эти нововведения - это самовыражение безусловно крутых разрабов из реакт-команды, которым скучно делать сайты, поэтому они работают над тем, чтобы не заскучали прикладные разрабы. Но проблема в том, что я и не думал скучать, и хочу просто делать продукт и совершенствовать свой код - не применением новых либ, а применением новых подходов в парадигме и архитектуре. Я люблю изучать новое, но не из разряда "теперь вот эту функцию пишем вот так, а это прописываем сюда". В этом нет по факту ничего нового. Но мыслительного ресурса и времени это бесконечно пережеванное старое, выдаваемое за революционное новое, отжирает прилично.
PS. Это не наезд на автора, канал люблю и смотрю постоянно. Просто высказался о наболевшем.
Причем на собесе от разраба будут хотеть чтобы он и useOptimistic использовал, и чтобы как там componentShouldUnmount работает знал.
Так учи ангуляр, кек. Всё что ты перечислил в основном относится к реакту
@@Roger-qj4wu да действительно, че это я.
так почти 5 лет не было же новых версий) все было максимально стабильным))
@@it-sin9k ага, было стабильным) верю
а весь этот ssr хайп наверное только добавил стабильности, и react к этому не имеет никакого отношения, тупа случайно рекламируя next на своём сайте
Круто передавать ref через props, люботытно, а как типизировать его теперь?
да по идее как и раньше RefObject или как там тип был
Как всегда, ты в моем топе😊
Compiler не войдёт в 19. Он отдельно будет
очень жаль :(
@@it-sin9kМожет это и хорошо, если он не будет прибит гвоздями к реакту
А что за новый компилятор
Спасибо
Месяц назад нужен был на подобии useOptimistic
Он всегда нужен
@@SmallWish не всегда, многие приложения сделаны без optimistic UI
Давай видео про варнинги! Интересно будет прикинуть возможность перехода среднего проекта с замысловатой логикой на 19ую версию
есть идея, такое видео записать, но надо сразу, чтобы 19-ая версия стабильная вышла)
По поводу ref cleanup это было можно делать и раньше. Если вешать callbackRef на элемент то при удалении элемента колбэк вызовется с null в качестве node и мы можем почистить event listeners на этом элементе к примеру. И по поводу use а также useContext они не зависят от порядка объявления а только от ближайшего провайдера. Чисто технически и useContext можно было в if пихнуть, но решили оставить warn из-за consistency что ли
Думаю clean up нужен больше для того, чтобы избежать использование внешних состояний, наверняка null все так же будет прилетать, иначе много чего поломается.
nice
А где коммент про варнинги?
Уже добавил)
пока не понятно.
для форм react hook form для оптимистик апдейт есть react-query (правда кода прибавляется существенно).
Props реактивные, а ref нет. Не вписывается в концепцию props, поэтому отдельно таскают