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

[@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]

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

[@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ь]

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

[@alexeysvetlenko2217]

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

[@it-sin9k]

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

[@alexeysvetlenko2217]

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

[@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]

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

[@АлександрКасатов]

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

[@salvehn]

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

[@PromiSeDev]

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

[@xkillfilm]

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

[@ДенисПлавский-у6ь]

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

[@it-sin9k]

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

[@ДенисПлавский-у6ь]

@@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 с подпиской на прокси-объект.