Максимальный перфоманс с React Signals

Рет қаралды 12,802

АйТи Синяк

Күн бұрын

Пікірлер: 128

@ReturnMeVoid Ай бұрын

обращаю все благодарности и ругательства не только к тебе, но и к роману

@PromiSeDev Ай бұрын

Благодарю) А конкретнее про ругательства и благодарности можно?

@vasiliykrush2150 Ай бұрын

В Angular сигналы выглядят очень прилично и чувствуется, что это одно из основных направлений развития фреймворка. Но профит там достигается не такой как с сигналами для реакт: view компонента все равно целиком будет пересчитываться после изменении значения сигнала, если его значения использовалось во view. В итоге мы имеем чем-то похожий на react стиль написания компонентов (signal≈useState, effect≈useEffect) + реактивно декларативный подход (значения одних сущности зависят от значений других, минимум императивных действий).

@it-sin9k Ай бұрын

спасибо за подробный комментарий!)

@gerda-morozova Ай бұрын

Парни реально придумали Vue 3 в React и назвали это Signals) Было время, когда Vue копировал идеи React, но, доводил их до ума. Теперь кажется, будто тенденция идёт наоборот. Спасибо за видео!

@it-sin9k Ай бұрын

так это же не React команда копирует, это сообщество же)

@gerda-morozova Ай бұрын

@@it-sin9k Да, справедливый тейк. Я некорректно сказал. Просто показалось забавным как это всё выглядит

@PromiSeDev Ай бұрын

@@gerda-morozova Многие заметили сходство с Vue) Только вот в Vue это появилось позже, чем в Svelte.

@RockStation-zero Ай бұрын

@@gerda-morozovaтакже и с vite. Никто не думал что из vue коммунити выйдет сборщик который прибьëт тормознутый webpack и react проекты сейчас в большинстве на vite делают. Согласен, тенденция забавная)

@egorovsa Ай бұрын

Все давно было придумано в MobX (как вы упомянули на 5:25), но там было немного другой подход при этом не надо создавать доп ноду value в VDOM.

@PromiSeDev Ай бұрын

Доп нода там нужна, чтобы не ререндерить компонент целиком, а менять только места, где используются сигналы. Они создают очень быстрый и легковесный VDOM для отображения value)

@ЕгорЛазука-й1э Ай бұрын

Никогда бы не подумал, что увижу vue в react.

@ЕвгенийДжаст-н9й Ай бұрын

Ты увидел лишь проксирование (что в принципе и взято за основу в vue), а не vue в react. Тот же immer уже есть везде, rematch, rtk и его можно легко подключить к сырому redux

@gatos-su Ай бұрын

После реализации проекта на solidjs нет никакого желания возвращаться на реакт. Не нужно греть голову ререндерами, юсколбеками, юсмемо, мемо - которые ломается, если колбек не мемоизированный передал в пропсах. Всё работает максимально быстро и понятно. Испытываешь ментальный комфорт, когда знаешь, что обновление не вызовет каскадный ререндер всей страницы. Сигналы в том или ином виде уже есть во Вью, и можно вживую убедиться, какая разница в скорости работы приложения на примере Озона (Вью) и Яндекс Маркета (неповоротливый монстр написанный на Реакт).

@Zubbol Ай бұрын

расскажите пожалуйста, что за идущая в ногу со временем компания позволила вам использовать solidjs на проектах?)

@gatos-su Ай бұрын

@@Zubbol та же компания, которая разрешит вам использовать сигналы ;)

@marcinskavysh8690 Ай бұрын

Дайте угадаю - в резюме это обычно строчка называется фриланс) хахаххаахах

@gatos-su Ай бұрын

@@marcinskavysh8690 ну блин, с ребятами, которые пишут фронт, обслуживающий миллионы юзеров в день и минута простоя из-за ошибки стоит сотни миллионов, ищущими информацию о сигналах - тяжело поспорить ;)

@t1mee Ай бұрын

Вообще, смешно читать про беды с ререндером и то, как невыносимо людям их каждый день героически решать. Будто реально, каждый второй фигму на реакторе пишет и надо каждый ререндер дотошно дрочить) Мне вот что-то хватало обычных средств, в виде декомпозиции, а если какую-нибудь кнопочку-формочку колошматит, то на это справедливо хер забить можно было, т.к это буря в луже для перфоманса

@RockStation-zero Ай бұрын

Я думаю основная из причин почему именно сейчас хэйтят react - это из-за упëртости core команды внедрять сигналы, хотя это уже сделали все остальные популярные фреймворки. И оправдания какие-то странные. Когда люди используют сигналы в виде ref, то никто не думает о рендеринге, он просто есть на изменения. Когда используют computed, то да обозначают после каких ref изменений должен обновиться этот computed. Это логично, это понятно, это легко читается, дебажится. Когда вы же иначе делаете какую-то подкапотную схему, то это дико не интуитивно и есть риски в непонятной ситуации лепить какие-нибудь useCallback и писать комменты что эта фигня запускается после той фигни.

@games3194 Ай бұрын

Интересное видео, но я не пишу на js, а так посмотрел для будущего спасибо)

@katana_yaiba Ай бұрын

Насчет Vue: Evan писал то ли в гитхабе, то ли в Твиттере. Далее не дословно: "Если сигналы стандартизуют, то у Vue есть большой шанс внедрить их в пакеты реактивности". Сейчас же Vue построен на прокси, что и так довольно удобно и сильно походит на сигналы)

@khmilevoi Ай бұрын

Jotai - 1,1 миллиона скачиваний в неделю. Плюс есть пропоузал о добавлении сигналов в ECMAScript. Как по мне, реактивность - это будущее и чуть ли не единственно верный способ разработки интерфейсов.

@it-sin9k Ай бұрын

надеюсь все же, что ваше предсказание о реактивном программировании никогда не сбудится)

@PromiSeDev Ай бұрын

@@notimeforhero У меня был лайфхак на этот счет) Могу скинуть)

@kamilmodest Ай бұрын

Не знаю про реактивность на фронтенде, но смотрел на неё на C# и на Java. Всё в итоге скатывается в использование сложных операторов преобразования потока, которые потом хрен поймёшь или отрефакторишь. И в отличии от условных промисов с коллбэк хэллом, реактившину нельзя разложить красиво с помощью условного асинк/эвейт.

@eliassmith7949 Ай бұрын

@@it-sin9kvue - signals, svelte - runes (signals), solidjs - signals, angular - signals, причем у них нет проблем как у преакт сигналс с useSignals(); так и какой реальный аргумент есть против сигналов? Уже даже ангуляр работает быстрее чем реакт

@PromiSeDev Ай бұрын

@@eliassmith7949 Прикол еще в том, что сам preact внедрил в себя сигналы сильно глубже и там можно использовать сигналы как пропсы. Я похожую штуку сделал и для react. называется @vicimpa/rsp (React Signal Props). Очень удобно. Думаю и дальше продолжать что-то копать в эту сторону, ибо мне нравится React за его минимализм, но при этом удручает моментами громозкость кода.

@ОлегСелин-ш9ы Ай бұрын

Мне кажется, что команда react, как бараны, упёрлись в "свой путь". В проекте используем реактивный state-менеджер reatom. Возвращаться к разработке на голом react - боже упаси! В серверные компоненты и компилятор, как в серебряную пулю - не верю.

@danielzagumennyi5683 11 күн бұрын

А почему вы сравниваете реакт со стейт менеджером?

@Dimazzz_ik Ай бұрын

На сколько знаю, в планах команды по Angular это полный отказ Zone.js в пользу Signals. И уже проделано очень много работы по этому направлению. В том числе и в взаимодействие rxjs и Signals, например, экспериментальный toSignals(observable)

@imthebest8000 Ай бұрын

Это, просто, офигенно 👍

@ИмяФамилия-э4ф7в Ай бұрын

Я пока не понял, в чем преимущество. Не, когда у нас коунтер то да, прикольно. Но, обычно, стейт у нас какой-то массив объектов, который мапится, или, как в примере с инпутом, изменяемая строка, и т.п. Что, в таком случае, дадут нам сигналы, в чем выигрыш? Если я правильно понял, то сигналы дают возможность управлять рендерами/перерендерами в отдельных случаях. Ну так в реакте это есть, упомянутые useCallback и прочие memo. Шо так дополнительный код писать для оптимизации рендера, шо эдак. Так в чем смысл, тянуть доп. библиотеку и разбираться с новым подходом? 🤔

@ichestor509 Ай бұрын

не, тут разница в том что ты имеешь переменную которая только сама и рендерится, без сигнала рендерится всё, и опять же если дерево большое рано или поздно будет тяжело контрить все пропы и тд, как я понял на условный юз эффект + стейт будут рендеры всей компоненты, а с сигналами только переменных

@RockStation-zero Ай бұрын

Ключевая разница, что хуки всегда трекаются и перерендериваются. А сигналы работают через Proxy объекты, запуская всю цепочку зависимостей рефов. Им не нужен глобальный трекер.

@PromiSeDev Ай бұрын

@@RockStation-zero Ошибаешься. Сигналы реализованы не через Proxy.

@RockStation-zero Ай бұрын

@@PromiSeDev Во vue по крайней мере через Proxy, в разных фреймворках реализация может отличаться.

@ДенисПлавский-у6ь 26 күн бұрын

отвечаю как Ангулращик зачем это там: rxjs -недостаток глитч, redux -скорость. В сигналах нету не того не другого. Просто скорость и меньше кода писать

@alexeysvetlenko2217 Ай бұрын

Классно. Спасибо Саша.

@it-sin9k Ай бұрын

Привет) ты еще смотришь мои видео)) приятно))

@alexeysvetlenko2217 18 күн бұрын

Да конечно смотрю. Хоть с реактом уже больше года как не работаю.

@antoncigur2724 Ай бұрын

А кто знает хороший курс по Vue3 ( торрент), напишите пожалуйста

@andyjs666 Ай бұрын

Пробовал год-два назад затащить Signals в проект. Но библиотека, к моему сожалению сломала в NextJs HMR. Я полазил по Гитхабу, даже (по-моему) нашёл какой-то ишью. Короче, удалил, и вместо него стал использовать Valtio.

@grenadier4702 Ай бұрын

А зачем эта библиотека, если уже давно есть mobx?

@a7kerkh Ай бұрын

отвечаю, люди не смотрят как что устроены и воспринимают что-то хайповое за новое :/

@gatos-su Ай бұрын

Мобикс - это стейт интерфейса и его можно использовать, в том числе и с сигналами. react-mobx = это просто сахарок, который оборачивает компомнент в memo и подписывается на события обновления стора.

@grenadier4702 Ай бұрын

@@gatos-su что значит "стейт интерфейса"? То что сигналы можно использовать с mobx - без вопросов, правда зачем мешанина эта. Мой посыл в том, что mobx отлично заменяет сигналы и обе библиотеки, по сути, выполняют одну и ту же роль: реактивность + точечный ререндер const store = observable({ count: 0, setCount(value) { this.count += value } }) VS const count = signal(0); const setCount = value => count.value = value; По сути одно и то же получаем

@ReAgent003 Ай бұрын

привет! ты знаешь что нибудь про грядущее обновление в реакте, что мемоизация будет из коробки и useCallback, useMemo и memo больше не понадобятся? Когда выйдет обнова, действительно ли принесёт пользу (а если да, то как замерить) и можно ли будет разом удалить useCallback, useMemo и memo?

@ReAgent003 Ай бұрын

а, нашёл как ты говорил кратко про это в своем видосе "Выжимка первого дня React Conf: Краткий обзор". но фулл уже не доступен(

@ReAgent003 Ай бұрын

а, при этом это то же самое, что React Forget. довольно неудобно что используют два разных термина

@ReAgent003 Ай бұрын

в статье Нади (блог Developer Way) полугодовой давности написано (если кратко), что на простых примерах в песочнице Compiler работает хорошо и сам всё мемоизирует, но на реальных больших проектах работает только в 2 из 10 случаев

@it-sin9k Ай бұрын

Да, речь именно про React Forget. Видимо еще нужно подождать) они на конфе говорили, что тестируют его на Facebook проектах. И результаты показывали крайне внушительные. Когда то мы ждали так Fiber, потом ждали concurrent фичи, теперь это подождем)

@AlexanderBorshak Ай бұрын

Нет Реакта - нет лишних рендеров! (Шутка юмора.)

@foo44444 Ай бұрын

звучит как тост

@АлександрКасатов 5 күн бұрын

в каждой шутке - доля шутки)

@salvehn Ай бұрын

былоб интересно попробовать скрестить RJSF с сигналами, при больших формах с кастомными виджетами сигналы должны помочь

@PromiSeDev Ай бұрын

Го попробуем)

@xkillfilm Ай бұрын

Есть реализация на Svelte 5 сигналах ищите x0k/svelte-jsonschema-form. Я с большими формами пока не тестировал, но могу предположить что будет не сильно лучше rjsf т. к. много вычислений связанных с обработкой JSON схемы. Нужно переписывать ядро либы, а для этого сигналы не нужны, только время и желание)

@ДенисПлавский-у6ь 26 күн бұрын

ну как бы сигналы это будущее разработки веб. Как когда то было c query , умер, потом flux , redux архитектурами. Сейчас сигналы.Если их не юзать то как бы ты устареваешь потому что старые подходы только имеет недостатки. А в новым нету

@it-sin9k 12 күн бұрын

боюсь что разные люди видят будущее разработки разным. И только время покажет, кто был прав)

@ДенисПлавский-у6ь 12 күн бұрын

@@it-sin9k ну когда был jquery тоже говорили при появлении reactjs , зачем он нужен .А реакт был быстрей и код легко было сопортить. Где сейчас query? Если в другой технологии преимушества, то старая умирает. Так всегда было

@foo44444 Ай бұрын

в реакте из реактивности только название

@EgorMoscowNeverSleep Ай бұрын

Preact Сигналы достаточно примитивные с куцым и запутанным API (как и многие другие реализации сигналов и атомов). Другие недостатки: 1. В режиме "оптимального" рендеринга нельзя подставить React-компонент, который будет рендериться - т.к. всегда будет рендериться как текст. Соответственно, нельзя подставить React-компонент, который будет рендериться в случае ошибки в compute-сигнале. 2. Async computation нет. Соответственно нет и "состояний" сигнала (для async computation это будет "pending", "done", "error"). 3. Нормальной обработки Exception (через Error Boundaries хотя бы) при "оптимальном рендеринге" нет. 4. У сигналов есть только само значение, никакую "полезную нагрузку" прикрепить к ним нельзя. 5. Нет синхронизации сигналов с другими реактивными источниками (например: EventEmitter, EventTarget, Observable). 6. Нет синхронизации с реактивными слушателями (например: for-of, Array.fromAsync, static EventEmitter.once). 6. batch-режим должен быть включен по-умолчанию, а у этих сигналов нужно использовать отдельную функцию. 7. Для режима отладки нет имени (description) и версии. Я для себя сделал собственную реализацию сигналов поверх собственной реализации EventEmitter. Конечно она также не лишена недостатков, но все вышеперечисленные пункты в ней реализованы.

@PromiSeDev Ай бұрын

1) Можно и я так часто делаю. 2) Его несложно сделать, и есть пакеты, которые уже предоставляют обвязку над промисами. 3) Если у тебя внутри реактивных примитивов присутствуют Exception, ты делаешь что-то не так. 4) На то они и примитивы, чтобы хранить только значение. Полезная нагрузка и есть само значение. 5) Это тоже очень легко делается, так как api сигналов примитивно 6) Тут мне нужны пояснения 7) (про batch) это не корректно. Существуют сценарии при которых нужно синхронно измененить часть состояния, дабы получить его и изменить что-то еще. 8) про режим отладки. В режиме отладки на точках остановки ты видишь все идентификаторы, в том числе и сигналов. Дебажить это не проблема @vic_dev напиши мне в тг, я с радостью взгляну на твою реализацию сигналов.

@egoreast Ай бұрын

👍

@Ramosok Ай бұрын

Огнище! КЛАССС!!!

@ukrainetoday960 Ай бұрын

Самые лучшие React Signals - это Svelte

@ЕвгенийДжаст-н9й Ай бұрын

Это лишь подход, который немного противоречит подходу react (вызвать что бы обновить), и теперь имеем 2 подхода, которые нужно будет использовать вместе, так как подход реакт никуда не девается, и сигналами он полностью не заменяется. Тот же RTK или Redux с Immer, это удобно, так как избавляет от больших конструкций со спредами, а сигналы ничего не меняют. Это все плохое влияние вьюшников с их proxy и templates :D

@PromiSeDev Ай бұрын

В сигналах, к слову, нет Proxy)

@RussianFrontend Ай бұрын

Что удобного в иммутабельности?)

@ЕвгенийДжаст-н9й Ай бұрын

@@RussianFrontend ну там больше не удобобство, а выглядит более компактно, но только в кейсах с редаксом и глубокими вложенностями в стейте

@alexanderkiselev402 Ай бұрын

Redux - это гребаный ад. Для простого счетчика нужно написать кучу кода состоящего из состояния, экшена, селектора и тому подобного шлакокода, который в большом проекте превращается в сильную головную боль. Библиотеки типа jotai или recoil сводят всё управление состоянием к одной функции, которую легко читать, менять и рефакторить. Спасибо разрабам за них!)

@dm_din Ай бұрын

Пока все нормальные фреймворки переходят на актуальные и эффективные концепции, реактоводы продолжают есть кактус и рискуют оказаться в позиции пользователей JQuery

@kamilmodest Ай бұрын

Снова и снова слышу хвальбы с торону RSC, но я их не понимаю. Для меня это выглядит как добавление сложной магии во взаимодействие между сервером и клиентом. Я из мира бэкенда, может я что-то упускаю, но мне всё же кажется явное лучше неявного и мне хочется явно видеть где у меня отправка запроса на сервер. И "use client"/"user server" проще жизнь не делает, как мне кажется бэкенд мир уже проходил через этап, когда RPC притворялся вызовом локальных функций, приводило только к конфузам и дополнительным сложностям

@StanislavTovch Ай бұрын

На многих библиотекках можно нормальный и производительный UI создать. Просто плохому танцору, как говорится)

@foo44444 Ай бұрын

хеrnя

@Zubbol Ай бұрын

прекрасная штука) уже год всем про неё рассказываю, но внедрить получилось только в одном проекте, а интереса в итоге ноль

@it-sin9k Ай бұрын

а что вас заинтересовало больше всего?

@Zubbol Ай бұрын

@@it-sin9k Возможность раз и навсегда забыть про повторные рендеры из-за изменения состояния, будь то локальное или внешнее. Без мемо и прочих мемоизаций это выглядит магией) если использовать сигналы хотя бы как альтернативу базовому useState, то уже можно кратно выиграть во всех аспектах уровня производительность/бойлерплейт

@PromiSeDev Ай бұрын

Не я один такой, получается)

@Zubbol Ай бұрын

@@it-sin9k в первую очередь то, что даже если использовать сигналы всего лишь вместо дефолтного useState, то рост производительности будет кратным, при этом о различных способах мемоизации(как и говорилось в видео) можно забыть. Показалось непростительным проходить мимо, с учётом таких вводных)

@Vv-mm6zo Ай бұрын

@@Zubbol а можно это в цифрах/видео как сравнение: "то рост производительности будет кратным"? Потому как звучит круто, а на деле может оказаться разница между 1ms и 10ms, и то и то не заметить

@АлександрБолотов-г4е Ай бұрын

Спасибо, как всегда чётко и понятно. Интересно было бы затащить такое в реальный проект, где на странице сложная логика и куча юзстейтов, юзэффектов, запросы и прочее-прочее. С другой стороны новый реакт в проде магическим орбразом оптимизирует ререндеры, и поэтому использование сигналов, возможно, игра ради игры

@allmight8407 Ай бұрын

Каждый раз когда после ангуляра и вью попадается реакт хочется выть именно из-за отсутствия удобной реактивности

@it-sin9k Ай бұрын

должен же быть хоть один островок без реактивщины)

@allmight8407 Ай бұрын

@ согласен, но этот «островок» является материком, так как за ним 80% рынка, от чего еще больней 🫣

@cdeblog Ай бұрын

@@it-sin9k особенно иронично, что фраемворк без реактивности называется реакт 😂

@olegdunkan Ай бұрын

Вроде, команда React не очень расположена к сигналам kzbin.info/www/bejne/n3TOgZR7adOrl9k

@it-sin9k Ай бұрын

да) я этому очень рад)

@olegdunkan Ай бұрын

@ в angular они имеют место быть, в react, как мне кажется, с точки производительности rendering-а все гораздо лучше. А с появлением компилятора вопросы, пишем, оптимизации, а имеем ввиду memoization многие закроются автоматически, хотя наверное не все.

@nctay Ай бұрын

Я так и не понял зачем менять атомарные стейт менеджеры на сигналы.В итоге для большинства случаев нужно использовать хуки трансформирующие сигнал в стейт.

@PromiSeDev Ай бұрын

Ну по сути сигналы - это и есть атомарные стейты. Но суть их в том, что сами сигналы уже являются атомарными микрокомпонентами, в которых, при помощи computed, можно рендерить и JSX) Помимо всего прочего, сигналы предоставляют апи без трансформаций их в стейты, напрямую сообщая компоненту о необходимости ререндера.

@cdeblog Ай бұрын

Реакт просто куча каких-то костылей и каждый раз накидывают сверху ещё и ещё 🤦😂

@it-sin9k Ай бұрын

а какие еще костыли там есть?

@МаксимСинькевич-в2я Ай бұрын

1ый😎

@it-sin9k Ай бұрын

красава!)

@jyjyjyj3 Ай бұрын

Я всё больше убеждаюсь, что фреймворк в половине случаев вообще не нужен. React отлично справляется, когда нужно быстро создать простой интерфейс, но как только задачи выходят за рамки верстки и базовых кнопок, начинаются сложности. Например, сравните реализацию бесконечного скролла на чистом JavaScript и в React. Разница очевидна: в случае React приходится преодолевать ограничения виртуального DOM, тогда как с использованием ванильного JavaScript таких проблем нет. В этом смысле мне больше всего нравится Svelte, который предоставляет удобный каркас для построения интерфейсов, но при этом активно поощряет использование ванильного кода. Это позволяет добиться лучшего баланса между удобством разработки и контролем над кодом

@notimeforhero Ай бұрын

Зато в оставшейся половине случаев в случае экспоненциального роста проекта получаешь монстра, которого очень тяжело поддерживать, а тем более пилить новые фичи. В итоге получается что лучше взять заранее полновесный фреймворк и перестраховаться, нежели переписывать всё при внезапном росте приложения. Имел, к сожалению, печальный опыт поддержки проектов на ванилле, а также написание велосипедов для Preact (вроде SSR или Swiper) вместо использования готового NextJS.

@guihalin8685 Ай бұрын

@@notimeforhero В общем, как обычно: есть два стула, а дальше сами знаете...

@foo44444 Ай бұрын

без фреймворков никуда, просто нормальный еще не вышел, дождемся, вот увидите

@rusfungame Ай бұрын

Фронтендеры все оборачивают в memo и думают что что-то оптимизируют. Смешно до жути.

@grenadier4702 Ай бұрын

Ну все уж не надо. Зависит от ситуации

@oWeRQ666 Ай бұрын

@@grenadier4702Для хока memo должны совпасть очень многие факторы, в большинстве случаев он не работает, проще меморизировать jsx

@notimeforhero Ай бұрын

А причём тут вообще memo?) В видео о нём речь не идёт, а сигналы работают по другому принципу. Это скорее useRef на HTMLElement с подпиской на прокси-объект.