Нулевой километр (Хекслет)

Всем привет, вы на канале Hexlet и сегодня нами замечательный гость Артем Арутюнян.
Артём, я знаю, что ты давно разрабатываешь разные сервисы, в IT давно. Тебя я впервые увидел на конференции, где ты уже не помню на какую тему ты выступал, по -моему, про контрактное программирование. Вообще, расскажи, с чем ты еще известен, и вообще, ты также известен, как artalar расскажи, почему ты artalar, откуда у тебя все это

Да, artalar очень просто, Артём Александрович Арутюнян обрезал. Но я стараюсь этим ником везде подписываться, так что там всякие телеграммы, твиттеры, какие -то ещё соцсети, Заходите, особенно заходите в artalog Это блог моей разработческой жизни, которая содержит много чего интересного, особенно по фронт -энду, в основном разные бывают хардкорные интересные контенты, бывают всякие.

Флуд тоже, чатик нас прикреплен, веселый, интересный. В общем, подписывайтесь, заходите, будет интересно. Началось это все с того, что очень много я занимался этим самым фронтендом. Вообще, я с 2012 года работаю в IT -шке и работаю очень много кем. Специалистом технической поддержки, специалистом мониторинга большой такой серверной штуковины, серверной комнаты на, по -моему, 400 миллионов она на тот момент стоила.

в общем, размером с этаж детского садика. Такая была серверная комната. Потом работал в другом мониторинге, поддерживал где -то что -то 700 разных железок по всей России, всяких… короче, администрации занимался. Вот. Потом работал продукт -оунером, делал одно мобильное приложение для очень крупного банка.

Потом работал техническим писателем. И потом уже в 2017 году начал на JavaScript писать. И вот весь этот бэкграунд, он... Прикол в том, что еще состоял и до 2017 года, и после 2017 года в очень больших крупных компаниях. То есть я занимался разработкой каких -то... На всю страну систем. И при этом иногда попадались маленькие стартапы. И вот это

Kirill Mokevnin (02:47.15)
Жуткое желание сделать маленькую, быструю, легкую, эффективную штуку, но соблюсти Enterprise качество, как -то во мне соединилось и в итоге породило много всяких интересных и технических решений. И опыт у меня такой, вроде бы, интересный. Из этого все выливается и канал, и Open Source, который я делаю, и вот какой -то подкаст, в котором сейчас что -то интересное, надеюсь, расскажу.

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

Да, тут сразу стоит оговориться, что знаете, сказать, что такое машина? Ну, это средство передвижения. Но как бы бывают BMW, бывают там запорожцы, бывают, соответственно, формулы 1 машинки. И вроде бы всё одно и то же, но очень сильно отличается. И под разные задачи, может быть, надо разные выбирать. В целом, с теоретической точки зрения состояние это какой -то...

Это согласованные данные. На хабре у меня есть статья, что такое состояние как раз называется, про архитектуру реактивного программирования. И там я это прям в детали, подробно разбираю. Но в целом состояние это согласованные данные какие -то. То есть это не просто набор абсолютно случайных, разрозненных данных в виде битов и байтов или еще чего -то. А это конкретные как

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

Kirill Mokevnin (05:03.79)
пользователь сделал что -то, мы это и обработали, и отобразили ему другую информацию, и на бэк -энд отправили, и там, может быть, что -то сохранили в локальное состояние, и вот все это вместе, чтобы подружить все эти разные источники данных, чтобы они были согласованы, чтобы этим было удобно с точки зрения разработчика управлять, нужны стейт -менеджеры. А почему их столько разных вообще? В чем... Зачем, зачем столько разных? Вот ты сказал,

БМВ, есть «Жигули». Всё -таки кажется, что здесь… Это аналогия плохо работает, потому что мы ни за что не платим или платим за что -то. И вообще, с чем сталкиваются люди, что требуется такой широкий выбор. Ну давай я отвечу, зачем нужны людям стейт -менеджеры, и потом зачем нужно писать самому стейт -менеджер.

Зачем нужны люди? State Manager — как раз -таки упрощение каких -то ключевых паттернов работы. В основном, State Manager — это -то штука реактивная. Что такое реактивность? Это возможность описать какие -то данные, на которые будут в нескольких разных источниках, на их изменения реагировать. Значит, нас там, интерфейс, например.

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

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

Kirill Mokevnin (07:19.278)
И плюс иногда стейт менеджеры в себя включают дополнительные какие -то фичи, например, там улучшение логирования, потому что если мы него кучу кода своего логики какой -то запихиваем, почему бы и не логировать с его помощью всю эту логику и получать более какой -то легкий способ дебага. Ну плюс он может делать какие -нибудь проверки, что там вот самый наглядный пример — это как в Redux GIFToolah весь...

Точнее, не в Диффт -Ох, просто в редакции весь стейт оборачивается в проксю, проверяет, что вы в этот стейт не пишете ничего, то есть мутабельно ничего в нем не меняете. Это дополнительная медаллвара, которую можно, например, при разработке подключить, и она вот этим вот занимается. Соответственно, набор вот этих всех фич отдельных, он там складывает современный стейт -менеджер. Но стейт -менеджер может быть намного проще, сейчас да, очень... Даже не сейчас, последние цать лет очень

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

Его можно затачивать под очень разные задачи. А, соответственно, так как написать одно решение, которое под все задачи подходит, очень сложно, то разные люди пишут разные решения, которые лучше подходят для конкретно их задач. И вот так вот мы в этом рынке оказались. Ну, кстати, ты сказал про управление данными, и, наверное, первое, что приходит в голову, не только мне, надеюсь,

это работа с реактивностью через RxJazz и вообще работа с данными как с потоками и это получается так вот то, что пропагандирует Rx и насколько я знаю есть некая альтернатива сейчас, которую ты тоже поддерживаешь, за которую ты топишь так всё -таки в чём же разница с этим? Angular вроде тоже от обзёров в том виде, чтобы раньше потихоньку отходить куда вообще идём?

Kirill Mokevnin (09:45.07)
У нас есть, получается, два лагеря в комьюнити. Это лагерь функционально -реактивного программирования и лагерь, назовем его пока, что объектно -ориентированного реактивного программирования, кажется так, ООРП. Соответственно, ФРП говорит о том, что у нас все есть поток. Вот тут бы я слово сигнал, мне кажется, лучше подходит. есть

Давайте так. То есть у нас мы оперируем концептуально, когда ментальную модель в голове строим, говорим о том, что нас есть поток, это какой -то таймлайн, то есть вот если мы абстрагируемся, посмотрим на все наше приложение со стороны в разрезе какого -то участка времени, мы увидим, что на этом участке происходят какие -то иногда события. И соответственно, чтобы нам какую -то логику описать, нам нужно на эти события какие -то как -то реагировать. То есть мы...

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

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

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

Kirill Mokevnin (11:53.038)
И они оба реализуют просто... как бы реализуются поверх паттерна Subscriber. вот я лично так и называю, что это и то, и то это реактивное программирование. Потому что оба лагеря говорят, что у них реактивное программирование. Ну, как бы логично, что если там миллионы людей говорят, что у них реактивное программирование, миллионы других людей говорят, что у них реактивное программирование, значит и то, и то реактивное программирование, как бы.

А если подумать, что объединяет этот тот лагерь, это pattern -subscriber, который заключается в том, что мы связи между нашим кодом организуем не с помощью непосредственно кода, то есть модули какие -то связываем, что говорим, что когда у нас что -то произошло, сходи туда и измени там данные. А мы наоборот пишем, что вот у нас что -то произошло, типа сделай broadcast, уведоми об этом всех.

а каждый конкретный, кому это надо, уже описывает в коде, текстиком, как бы, написана логика, что нужно данные оттуда -то получить. То есть реактивность, про это, архитектура реактивного программирования на Hubless статье, там это описано более детально. Кстати, вот про подписчиков и вот это всё. Это, мне напомню, вообще очень старый такой фреймворк Backbone, где в модели генерировались события, на которые другие подписывались.

когда реагировали на изменение этих данных, и кажется, такой адок, и мы не зря ушли от этого в сторону чего -то более централизованного типа редакса. И всё -таки какой лагерь лучше вообще? К чему мы вообще все идём? Давай немножко в историю углубимся. Да, давай как -то тогда по всей этой истории пройдёмся. У нас, ну да, вот предположим, был сначала Backbone.

Там библиотека такая классная была еще SGS, прямо S .JS, есть все название и просто R .S. можно сказать. И они имели довольно удобный интерфейс по описанию каких -то observables. И практически этот же самый интерфейс сейчас, 10 лет спустя, даже больше используется в новом пропосале сигналов, который станет частью стандартного джейлскрипта. Но вот как мы к этому пришли, сейчас...

Kirill Mokevnin (14:10.894)
давайте в конце поговорим, а сначала предысторию. Таймлайнчик. Да, был Backbone, и с ним заключалась проблема в том, что да, это очень мощный паттерн, это реактивность, обсервабль, но он очень низкоуровневый, он очень мощный, но очень низкоуровневый, низкоуровневый в том плане, что его можно очень по -разному применять. И получается, что на нём можно написать любую лапшу, то есть он...

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

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

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

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

Kirill Mokevnin (16:33.358)
с помощью ЭМИ -то какие -то события? Кажется, так и должно быть или всё -таки нет? Ну вот, опять же, с архитектурной точки зрения сам подход, очень простой и элегантный. То есть, во -первых, причём он даже с математической точки зрения, ещё раз с архитектуры, слово скажу уже как басборд, реакт -компонент – это акторы.

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

намного проще скейлить наше приложение с технической точки зрения и с точки зрения поддержки. Но получилось так интересно, что React пока это делал, он отказался от обсероблов, подумав, что одно артагонально другому. То есть, решить проблему... Ну, там не то чтобы стояла сильная задача решить проблему бэкбона, но как бы вот мы можем

ретроспективу примерно такой провести, что как бы так получилось, что реактор, решая проблему обсервов и бэкбона, он написал альтернативу, которая их вообще не использует. И поначалу показалось, что так и должно быть. То есть вот нас весь мир, он как бы так немножечко отдалился от всех этих обсервов, хотя все еще оставался лагерь, который говорил о том, что вот надо стандарт это внести, у нас есть неудачный пропосыл

по -моему, 2017 года, может даже пораньше, обсервабло в стандарт JavaScript. В начале этого или в конце 2023 года возродили этот пропосыл, решили его внести в живой стандарт веба, то есть не в стандарт самого языка, а в стандарт веб -опишек, которые у нас доступны в браузере конкретно. То есть, например, как бы строго...

Kirill Mokevnin (18:48.59)
по этой спецификации в ноде обсервауглов не будет, а в браузере будут. Но как бы к чему это всё приведёт, такая отдельная история, сейчас не будем затрагивать, там свои есть проблемы. Значит удобно, потому что это, как по мне, возможно, немножко решает проблему того, что у нас сейчас почти невозможно подружить несколько менеджеров состояний. Я лично сталкиваюсь с такой проблемой, что мне нужно было в одном проекте иметь там два менеджера состояния, артагональных друг другу, и это было

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

Это первая информация. Интересно, почему оно слишком сильно не бустится. Второй момент. Это в минус Апсероблом. В плюс Апсероблом то, что React пропагандирует компонентный подход и мутабельные структуры данных, но в какой -то момент библиотеки начали адаптироваться и понимать, что можно брать и компонентный подход, и какие -то реактивные структуры данных. Вью, естественно.

Angular в какой -то степени всё пытался к этому трансформироваться. Solid, если вы не знаете про эту библиотеку, Solid .js. Тоже рекомендую очень ознакомиться. И как раз -таки автор Solid .js, очень сильно начал пропагандировать. Он подружил достаточно качественно подходы React и вот эти вот самые обсерваблы, которые были в Backbone. Немножко странно, что он назвал эти обсерваблы

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

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

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

И прикол в том, что как с моей стороны это все выглядело. В прошлом году я и еще один чувак, ну там несколько людей, но больше все бурлили, я и еще один чувак из Bloomberg, который тоже в TC39 состоит, тоже в смысле с тем человеком, который предложил Observe было опять все -таки в стандарт затащить, только теперь не в стандарт языка программирования, а стандарт Web API. И

Сначала как бы бурлил, что вообще -то нам обсердлые не нужны, с ними много проблем, как бы это не универсальный примитив, там с композицией тоже есть сложности и так далее. А потом несколько месяцев тишины и бах! Появляется Rapostle в сам TC39, ну в стандарт, в комитете TC39 стандарт ECMAScript, то есть в наш JavaScript.

а не просто в web, в стандарт JavaScript, который работает везде, в браузере, в ноде, в дина, есть он самый базовый стандарт. И туда появляется пропосыл по добавлению сигналов, которые как раз таки фактически являются, вот мы как в начале говорили про лагерь FRP, это как раз обсерваблы классические, RX, вот этот вот, и лагерь

Kirill Mokevnin (23:30.894)
И как раз таки, если лагерь ОРП, он говорит не только про объектно -ориентированное программирование, но и столько про то, что у нас есть какие -то штуки, которые внутри себя содержат состояние. Всё -таки ФРП, оно, как бы, условно говоря, старается делать так, чтобы состояние не существовало. Был только какой -то поток изменения данных, но самого состояния в явной степени его как будто бы нет. Пытается от этого избавляться.

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

и очень интересный. Это те мотивации, которые действительно аргументируют то, что это должно быть именно в стандарте языка программирования в самом его ядре. Первая аргументация — то, что затаскивать такую штуку как реактивность, которая фактически форсит нас переносить очень много работы в runtime, нужно с помощью…

с помощью авторов движков JavaScriptа. есть это должно быть в какой -то степени реализовано на нативном уровне. Тогда в этом будет намного больший смысл и меньше overhead. А если это реализовывалось как бы средствами прикладного JavaScriptа, того API, который у нас есть, это будет чуть менее эффективным. Это первый аргумент. Он неплохой, ну такой, я бы сказал. Хороший аргумент, не очень сильный. Но есть еще более сильный аргумент, который как раз -таки вот про то,

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

Kirill Mokevnin (25:50.702)
Если у нас есть другая очередь подписчиков, то есть мы из одной библиотеки реактивной дёргаем другую, та тоже начинает вызывать своих подписчиков в свою очередь. И получается, мы эту очередь разорвали, ждём, когда отработает та очередь, и только после этого продолжаем эту. И самое главное, что из этого нужно вынести, уже многое сказал, то что

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

Не получится, Да, да. Попозже про конечный автомат, поговорим. Ты сейчас интересную моменту упомянул. Это runtime -debug. И в принципе, как мне кажется, многие, кто пишет на JavaScript, считая его там однопоточным и все прочее, считают, что них вообще не может быть гонки состояний, у них вообще нет такой проблемы. Расскажи вообще немножко про то, где с этим можно встретиться. И вообще в

в чем -то сложность проблема дебага этой иконки состоянии. Да, это особенно в реактивности большая проблема. Ну так вот, если у нас будет новые сигналы, то очередь этих подписчиков будет одна, нативная как бы, и там проблем меньше.

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

Kirill Mokevnin (28:07.726)
прочитать логику работы нашего кода. что вот мы текст видим, и в тексте написано, ты зависишь от того -то там. А когда это то -то там обновляется, когда как бы происходит его обновление, это нужно вот лазить, получается, по кросслинкам, по EDEшке, открывать много разных файлов, и с реактивностью у нас теряется линейность описания каких -то

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

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

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

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

Kirill Mokevnin (30:23.47)
древовидность компонентов очень крутая тем, что она матчется на HTML, на DOM. Не всегда один к одному, но часто. И это тоже дополнительный такой ментальный трюк, как сделать все проще. Но на самом деле проблема дебага этих обсерваблов, никуда не ушла. То есть мы упростили количество...

создаваемых обсерваблов и способ их распространения, есть тот же view и Svelte предполагают, что ты создал обсервабл и сигнал этот ref и передал вниз посылки, то есть он вверх никуда не уходит и не путешествует во всем приложении в непонятных направлениях. Но если у вас появляется задача всё -таки какую -то сложную логику вот такую вот описать, когда у нас

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

Это как вот если в ноде на экспрессе кто -нибудь писал, первым аргументом сети X приходят. И фактически в рятами у нас то же самое. Грубо говоря, все атомы, это такие тоже как сигналы, и все там зависимые вычисления, них подписчики, получают этот контекст, и в нем содержится информация о том, откуда он пришел. То есть каждый раз в нового подписчика...

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

Kirill Mokevnin (32:39.022)
Почему они обновились именно так? есть мы можем посмотреть от каких зависимостей, какая цепочка была операцией, из какого компонента произошел клик, потом эффект, потом засетились данные, потом что -то еще триггернулось, какой апдейт. И вот как мы оказались в этом состоянии. Рядом такое сделать позволяет. Кстати, знаешь, чем проблема с контекстом в экспрессе? Ну там на самом деле не контекст, там реклест, и все все пихают в реклест в мидоувариях.

И знаете какая в итоге эта проблема, основная претензия именно прикладных программистов к этому? GotObject, то что это такое получается? Да, это то что такое GotObject получается, и в какой -то момент люди начинают делать какие -то подобия сервисов, передавать этот реквест куда -то еще, и у этого реквеста, так как это все -таки не просто контекст, реквест, у него есть end. То есть, ей можно сказать, что все, обруби обработку получается всего реквеста.

и где -то там, в каком -то сервисе вызывается end, и ты это не можешь оследить, потому что это вообще фиг помешит о... ну то есть проблема гонки состояний в контексте вот такого глобального объекта, она только усиливается. Это одна из таких больших претензий к паттерну мидуар в экспрессии и в целом к мутации вот этого next и работать с контекстом. Я знаю, что вариатами

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

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

Kirill Mokevnin (35:06.382)
вот как раз такие сигналы, топологическая сортировка нам позволяет избежать дублирования этих вычислений или запросов, эффектов, и всё как бы в порядке становится. Но проблема с тем, что если у нас асинхронная природа обновления данных, то есть на самом деле даже не обязательно ромбовидные зависимости могут быть даже, просто может быть несколько пользователей очень быстро печатают, и нам нужно запрос на поиск саджестов в автокомплите отправить.

нам нужно получается новый запрос сделать, а старый нам нужно отменить. И механизм отмены предыдущего контекста, он в рядах тоже присутствует. То есть мы, взяв вот этот вот паттерн контекста, реализовали на его основе несколько как бы механизмов, которые позволяют решать разные задачи. Это дебаг, это асинхронный контекст, который в ноде аналог есть с помощью него там

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

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

что еще с URL, там есть helper работы, с методами lifecycle, куча всего короче. И рятом в базе все эти процессы, получается, делают конкурентными. То есть они, когда у вас какая -то логика запускается, она зависит, всегда автоматически подписывается от аборт -контроллера. И вы этим аборт -контроллером можете, получается, управлять. То есть вы можете заканцелить все производные операции.

Kirill Mokevnin (37:28.238)
При этом, естественно, есть механизм отписаться от этого abort, отписаться от этого контроллера. И наоборот явно подписаться в каком -то другом месте, но они дополнительные. Но смысл в том, что автоматически риатом всегда старается делать всё неконкурентно. То есть если у вас вызывается повторный запрос, то первый будет отвалиться, сломается автоматически. Причём удобность использования abort -контроллера в том, что очень много веб

Я очень рекомендую с этим познакомиться, если вы еще про abort -контроль или abort -сигнал не читали. Посмотрите, какое количество веб -опишек уже умеет с ним работать. Во -первых, его можно передавать в event -listener. И вместо того, чтобы писать потом remove от event -listener, вы можете вызвать сигнал, и callback получается самоудалиться. Это достаточно удобно. Плюс fetch принимает аргумент сигнал, который тоже может отменить запрос

Это прям очень важная штука, потому что у нас вебе, в браузере в среднем по разным браузерам как бы разные показатели, ещё от некоторых алгоритмов и в ристик зависит, но браузер может делать одновременно только семь запросов. Шесть. Шесть запросов параллельных может делать. То есть если вы там, у вас, тяжёлая страница, которая очень много опишек разных дёргает, у вас одновременно будут только шесть выполняться. А все остальные будут ждать в очереди. Вот шесть выполнятся, даже если вы там двадцать сразу сделали.

У вас Waterflow получится 6, и потом вот это следующее. И очень важно, соответственно, эти connection освобождать. Вот очень много библиотек, они отменяют запрос, но отменяют результат запроса скорее, не применяют результат запроса. Там такая логика отмены как бы. Но она немножко вот в этом плане слабая, то есть вряд ли вы всё -таки можете прокинуть аборт -сигнал

отменится не просто результат этого запроса, то есть он не будет дожидаться, когда запрос от бэкэнда придет, и после этого просто не применит результат, а он именно отменит сам этот феч браузерный и connection освободится, и будет возможность отправлять другие запросы. Мы так нормально к рятуму перешли, но, кажется, перешли сразу к его таким, знаешь, к его начинке, к его фичам. Давай, наверное, вернемся в начало и, в принципе, поговорим, какие примитивы есть.

Kirill Mokevnin (39:45.23)
Из того, что я знаю, там есть атомы, на эти атомы можно подписываться. Атомы очень сильно похожи на то, что я видел в кожуре. Там тоже есть атом, и можно его рефать -дерефать. Вот расскажи вообще, откуда вдохновлялся его? Давай начнём с самого начала. Да, тут история опять, история. Да, это история. Травим байки. Когда -то была такая библиотека. Я вообще

17 -м году или в начале 18 -го писать альтернативу редакса — просто поиграться. То есть я вообще хэлперы нему хотел какие -то писать, и потом было просто по приколу интересно написать какие -то альтернативы. Меня очень вдохновил стейт -менеджер или даже не знаю как это назвать. В общем, библиотека Cerebro .js. Она лежит... Построена на основе паттерна Function 3. На хабре есть перевод или даже англ... Даже, по -моему, не перевод.

В общем, на хабре есть статья про function 3, это интересный такой паттерн, описание процессов. Грубо говоря, некоторая такая альтернатива конечным автоматам в том плане, какие проблемы они решают. Это похоже на Behaviour 3, наверное, да? Есть такая штука Behaviour 3 в играх. А, может быть. Дерево поведения. И это вот, скорее всего, на это похоже. Может почитать. Про Behaviour 3, да, давай. Я теперь почитаю про Behaviour 3.

И я как -то вдохновился этой штукой, подумал, что всё может быть не так просто, а может быть интересно, и как -то лучше задачи некоторые решаются. там, не знаю, короче, за следующие там 5 -7 лет, сколько -то уже прошло, я написал там, не знаю, с десяток стейт -менеджеров, но вот «Риатом» уже 4 или 5 лет ему, как бы он такой самый стабильный, единственный теперь, в который я вкладываюсь. И ты рад с ним первого «Риатома» в качестве версии уже? Да -да,

Третья версия, она... Ну да, третья версия. Первая версия была попыткой чуть -чуть улучшить редакс. Вторая версия была попыткой очень сильно всё поменять, но всё ещё попытаться остаться в концепции редакса. То есть, грубо говоря, было заменить риатом на редаксы, и бы ничего не поменялось, грубо говоря. Но оказалось, что даже если потратить полтыщи часов времени...

Kirill Mokevnin (42:09.806)
разработки, всяких экспериментов, то редакция подчинить невозможно, и надо двигаться дальше. Ну а вдохновлялся я первым вдохновением, наверное, была библиотека «Кефир». Это как раз таки библиотека, которая вдохновлялась «Клажурой». Вообще, по «Клажуре» это, конечно, такая интересная штука. Мне очень нравится то, что Маккевин говорит про «Клажу», рассказываю я в видео несколько его

Очень вдохновляющая штуковина. Hell Samurai тоже рассказывают. Сам я на ней не писал, но очень интересная штуковина. Познакомиться, конечно, хотя бы теоретически, уже, мне кажется, мозг немножко приоткроется. Наверное, если пописать, то совсем там можно вдохновиться и открыть для себя новые границы. Есть курс по клажури на CodeBasics. Всем рекомендую пройти. Там вот такие основы тоже есть.

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

Клажуры, тоже такое FPE частично использовалось, линзы всякие, очень большая библиотека линз была, которая позволяла производные данные описывать очень большой сложности, которые получается... Ну, смысл линз, это, грубо говоря, как в редакции селекторы, селекторы, в одну сторону вытягивают данные, а линза – это такой же селектор, помимо функции вытягивания данных, есть еще функция обратного.

затаскивания. И смысл линзы в том, что она описывает один и тот же путь, но как бы для гета и для сета. То есть, когда мы создаем какую -то линзу, получается, вот так вот, может позволяет и в ту, и в другую сторону работать с данными. И там очень сложная библиотека линз. То есть, она позволяет прям какие -то супер сложные структуры данных описывать, которые там вот так перемешаются, при этом можно менять в одну и в другую сторону, читать и подписываться на все это дело.

Kirill Mokevnin (44:30.35)
Это было, всё интересно. И пытался я подружить вот эти все концепции с редакцией. Вообще мотивация была в основном поиграться. Ну, конечно, хотелось решить личные проблемы. есть, было неудобно. У редакцией очень много проблем. есть, вот всё, что вы знаете, проблемы редакцией, могу назвать в два раза больше. Одна там, например, из проблем у меня была такая, реально на проде случилось, что у редакцией фишка — он имутабельный.

в себе стейт редюсера, собирает имутабельный стейт. Но проблема редакса в том, что у него стейт не весь хранится в редюсерах. Большая часть состояния, ну, от приложения зависит размазано по селекторам. И там их не очень сложно дебажить, инспектировать, то есть они там не лагируются в дифтулзах, все что в селекторах лежит. И получается, если в редюсере упадет ошибка, потому что там какой -нибудь undefined, изнатонамбер, что -нибудь там, не знаю.

то у вас новый снапшот стейта не применится. Это называется тамарностью из теории базданных. Очень классный концепт. Очень как бы повышает надежность приложения. А если в селекторах что -то упадет, то данные в стейте останутся старые. Другие селекторы будут не актуальны, не согласованные данные показывать. Вот, это мне все

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

когда ты на одну ступеньку наступаешь, теперь видишь выше, дальше, видишь, что есть ещё ступеньки. Вот. И для меня этой ступенькой, наверное, в большой степени был мол, такая библиотека, или small. У неё очень много специфических штуковин, она там вообще предлагает отказаться от npm, от React, всего. То есть очень слишком радикальное. Но

Kirill Mokevnin (46:53.038)
как есть радикализм в сторону одну, также есть набор здравых концепций, которые она предлагает тоже использовать. Например, одна из здравых концепций — это то, что не использовать транзакции по умолчанию, а по умолчанию использовать реактивность ошибок. То есть если у вас ошибка где -то в одном месте встречается, всё, что зависит от вот этого состояния, должно упасть тоже с ошибкой, пока изначально ошибка не решится.

И кажется, что это очень правильный подход, особенно в написании UI, чтобы мы могли, например, раскидав много error boundary по нашим компонентам, если у что -то случилось, только релевантные виджеты нашего приложения. Я вот особенно часто делаю именно приложения не просто сайты, а какие -нибудь Как онлайн банкинг — это самая простой вещь, чем обычно я сталкиваюсь. Вот сейчас я в стартапе пилю конструктор сайтов. Ну как бы

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

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

работать, по идее, лучше. это как бы... Так я кратко рассказал вроде бы прошлое и, да, будущее риатома. Ну вообще, у риатома, как смотрю, комьюнити стало больше даже. Я за долгое время увидел, что там документация стала лучше, потому что я отпробовал вторую версию риатома. Первую я, наверное, не успел, а во вторую я попробовал после твоего какого -то такого же интервью.

Kirill Mokevnin (49:16.782)
Я такой, о, прикольную штуку делает человек, надо пойти тоже посмотреть, что там вообще происходит. Я там услышал про... про протеопологическую стартировку, про проблемы РХ. Я тоже с этим проблемами РХ сталкивался, и меня тоже это бесило. я как -то... когда впервые услышал про риатом. Знаю, что у вас принципе экосистема еще стала больше. Расскажи вообще, что есть, что вообще...

включая себя риатом, ну, мне, как вот текущему такому обывателю сейчас, во Frontend я больше уже сейчас обыватель, это история про РТК Redux Toolkit, РТК Query, React Query, работа с СССР, которая тоже, ну, сложновато. Как вообще, как дела у риатома на этом поле битвы и что вообще может предложить ему? Ну, да,

Очень много всего, можно сказать. Когда первая версия в 2019 году вышла, у нас была одна редмишка, и было уже неплохо. И потом мы сайт сделали, на котором была, может быть, документация по объему, не знаю, десятая часть того, что есть на сайте сейчас. И все радовались, короче. Мне приходили... Я помню, Черторогов мне сказал, это такой огромный чувак, в том плане, что он мейнтейнет кучу всяких граф -QL -ных пакетов.

ну, имеет большое уважение в индустрии, и он подходит и говорит типа «у вас документация крутая, есть ответы на вопросы», а как бы я думаю «о, ну ладно, круто». Но сейчас стандарты качества стали прям намного выше, то есть сейчас хорошая документация должна содержать, вот если на редакции посмотреть, он начинает вообще со снов программирования, грубо говоря, что такое имутабельность, редьюсеры, то есть

вводит абсолютного жуна сначала в концепты какие -то программирования, заканчивая примерами, экзамплами, там, гайдами, case studies и куча всего. Ну, вряд ли мы идем к тому же. У нас есть, развивается handbook. GetInstantRate у нас написан пачкой двух или трех особо активных контрибьюторов. То есть, я его почти не прикладывался, короче, вот к старт -гайду почти не писал.

Kirill Mokevnin (51:43.31)
Ну, в целом, да, комьюнити подросло. Вот я недавно отчет проводил, нас, по -моему, два или три месяца... Раз, два, три, четыре... За два с половиной месяца четыре разных человека заполреквестили какие -то изменения, не маленькие.

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

У нас тут много чего. В основном наша большая гордость это работа с асинхроничной. есть все, что связано с получением данных, отправкой, их асинхронной обработкой, кешированием, персистом. То есть у нас есть очень много адаптеров под все веб -сторажи. Под index .db, под local storage, session storage, Что -то по -моему пятое еще было. А под URL тоже есть синхронизация.

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

Грубо говоря, вот у вас есть хуки реакта и у вас есть получение данных. Как вы подключите персист этих данных в индекс DB, кэш какой -нибудь? Это очень непросто сделать. Помимо того, что вам надо после инициализации хука взять данные и положить, вам надо каким -то образом до инициализации хука вытащить эти данные и положить в него. То есть вам нужно сделать какую -то обертку над хуком, и реакт — это невозможно. То есть только библиотека

Kirill Mokevnin (54:01.07)
как бы сама написать какие -то там методы типа... не знаю, -нибудь callback init, callback там sync, ну то есть никто это не делает. А риатом дизайнится в плане композиции. Я даже, наверное, скажу, что вот посмотрите, хороший пример, как надо делать. У него интерфейсы достаточно открытые базового примитива атома. Таким образом, что вы всегда

Ну можете сверху что -то короче добавить туда, дописать какой -то логики. И у нас, как я говорил, можно, например, в кэш засинхронизировать с любым там local storage, index, DB через абстрактный адаптер, не нужно допомнить код, писать просто импортнули адаптер, засунули. И вот недавно добавили поддержку для пакета underedo. То есть у нас есть... Это прям реальная продуктовая задачка решалась. Есть... Пользователь ходит... Ну давайте для примера представим многоступенчатая

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

То есть мы довольно долго писали и UNDO пакет, там много исправлений было, очень таких хитрых фиксов, багов каких -то. И, ну, сам Persist, да, тоже, чтобы правильно подружить, все -таки пришлось чуть как бы внести какие -то изменения, но в целом прикол в том, что в пакет UNDO была добавлена опция приема адаптера абстрактного для Persist, а у нас уже есть биндинги ко всем стораджам. То есть мы написали интерфейс

самому персисту, а куда именно персистить, это вы уже сами выбираете, есть там код дополнительно писать не надо, и вот это вот как бы навес золота, мне кажется, что не надо дублировать код, и он друг между другом очень хорошо композируется. Кстати, мне кажется, это слух контекста в том числе, Там какой -нибудь... В контекст можно комедий сложить, что -то похожее. Да, ну вот как раз ты

Kirill Mokevnin (56:22.606)
задачу DI можешь решать за счёт синхронного контекста. У нас, например, в том же UNDA есть такая, как бы... Ну, вы когда редо делаете, не UNDA, а редо. То есть, когда вы состояние хотите обратно откатить. Вот логически представьте, чтобы записать состояние в историю какую -то, вам нужно на него подписаться. Когда вы подписываетесь на какое -то состояние, вы всегда получаете любое его изменение.

вы делаете реды этого состояния, оно откатывается, меняется, и вам прилетает информация о том, что новое состояние как бы этого случилось. Хотя слогически, ну, вы же его откатили, но оно -то формально новое, и нам нужно понять, класть в историю это новое состояние или нет. И там используется как раз -таки из Chaos Dubai, helper у нас есть. Мы можем проверить, почему изменилось состояние.

И там прямо логика, в исходниках логика написана, if escouted by... этот типа Redo, то ignore. Ну там jump используется как абстракт. Ну короче, грубо говоря, так, if scouted by Redo, то типа игнорировать и не записывать в историю это состояние. И вот возможность, писать такие штуки, как бы, на таком уровне, она... Да, интересные паттерны, в общем, можно из этого всё устроить. Да, прикольно. А давайте теперь ещё немножко сравним.

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

в русскоязычном комьюнити. Когда -то я видел это больше в западном комьюнити, сейчас тоже русскоязычным всё больше и больше людей порасплавляют Зуштант. Вроде так произносится или Цуштант. Ну и конечно есть ещё один российский аналог, я бы сказал, это Эффектор, которым тоже было много баталий и в Твиттере были, и в Телеграме. Телеграме я видел очень много баталий тебя с ребятами из Эффектора.

Kirill Mokevnin (58:46.51)
Давай вообще посмотрим на то, есть, на альтернативы и в чем их проблемы, какие может быть преимущества у риатома. РТК тем же самым. Начнем, наверное, с РТК, да? Начнем с Redux Toolkit. Ты уже начал о проблемах Redux, но Redux Toolkit — это чуть больше. Да. Redux Toolkit. Смотрите сам Redux. Вот я целью моей жизни несколько лет было...

построить на редакции что -то хорошее, грубо говоря. И у меня не получилось. И я думаю, что я не дурак, скажем так, в этом конкретном вопросе, по крайней мере. И редакция у Kit — это просто набор костылей в том плане, что они не решают некоторые фундаментальные проблемы редакции. То, что мы говорили про то, как селекторы дебажатся и работают, про то...

про перформанс этого сингл -стора, много, короче, разных моментов И Redux Toolkit, проблемы производительности не решает. Дебаг, он никак не увеличивает и не улучшает. То есть, эту возможность, если с риатомом сравнивать, отследить, что чего изменилось. По весу он больше. Экосистема у него уже относительно слабая. То есть, Toolkit,

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

в котором ты сравниваешь снапшоты и делаешь какую -то логику. Вот это вообще нигде нету, я не видел. У таких как бы стейт менеджеров, именно если мы берем. Потом, редакц все еще очень более реплейтный, все еще даже Toolkit слабо решает эту проблему. Все еще непонятная парадигма и концепция его. То есть вот это вот разделение action с диспатчером, store, selector, она избыточная.

Kirill Mokevnin (01:01:11.054)
ну как бы оказывается, есть давайте просто есть состояние, но иногда есть экшен и всё как бы. Зачем ещё вот цепочку рисовать? Она просто избыточна, то есть она не несёт практической никакой пользы, но несёт огромную ментальную нагрузку. Ну и... какие -то такие штуки, да, то есть он просто менее гибкий, то есть слайсы создавать особенно динамически у вас там не получится, перформанс на нём...

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

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

каждому проекту нужно. Вот минусы редакса я вроде бы описал, плюсы у него всё -таки… Он такой хороший средничок в том плане, что у него много наработано… Вообще, знаете, мне кажется, для того, кто выбирает сейчас стейт -менеджер, самый главный плюс редакса – это то, что по нему чаджи PT, наверное, лучше всего отвечает. То есть, это библиотека, которой лучше всего отвечает чаджи PT.

Хотя и то, ну там всё равно понятно, что надо... вам всё не расскажет, то есть и он будет путать обычные редакции Toolkit, и в зависимости от набора Middleware, которые у вас в редакции сидят, тоже код, style на редакции может быть разный. Поэтому тут нужно быть чуть поаккуратнее, но как бы такой интересный факт. Ну и да, это типа куча туториалов, куча документации, то есть он для входа кому -то будет легче, если вас надо как бы за ручку вести, то ну...

Kirill Mokevnin (01:03:30.99)
вы как бы не хотите сами сильно разбираться, хотите вот те туториал, прошел, все знаешь, это с редакцем будет, конечно, проще. Ну и, наверное, других людей, которые с ним знакомы, тоже больше уже, соответственно. То есть, в любом случае, редакц хорошо бы с ним познакомиться, просто его изучить, понять как бы вот эту тоже бэкграунд, какой -то, на котором стоит вся наша сейчас современная экосистема, потому что редакц повлиял достаточно сильно не только

React, но и очень сильно на Vue в виде PIN 'e, на NGRX есть тоже очень похожий на Redux, популярный стейт менеджер в ангулярии мире. Так что в Solito иногда затаскивают. И в принципе он framework -агностик. На мобильную разработку он дико повлиял. Flutter -блок, Flutter -Redux, тот же самый, например. То все подходы во Flutter, которые используются, они тоже из Redux 'а пришли. И в принципе этот pattern -flux...

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

Вот, потом что у нас следующее после Redux? Идёт это MobX, мне кажется. MobX...

как сказать, у него есть одна проблема, которую лично я считаю очень большой, огромный и самый плохой. Но при этом, если почитать другие обзоры, как бы ей, мне кажется, внимания уделяют, но мне кажется, что она очень серьёзная. Это то, что там используется Proxy, и это очень неявная штука. То есть вы иногда можете писать код и не знать, а он вообще реактивный или нереактивный.

Kirill Mokevnin (01:05:26.766)
То есть вы читаете коды, не знаете, что там, не можете как бы сходу сказать, что там происходит. Вам нужно там убедиться, что данные, которые пришли, они, ну там, из какого -то ММИК -стор, в общем. И самая большая проблема в том, что как бы не то, что читать, ну это относительно нормально, что мы можем прочитать часть кода и не знать, какие данные передаются. Но обычно мы можем в PuRequest, например, но в IDE мы можем навести мышкой и посмотреть типы и провалиться в эти

А в MobyX это часто так не работает. То есть у вас просто данные приходят, вы не знаете, реактивные ли они или нет. Это просто какой -то объект. Иногда это бывает именованный стор, иногда нет. Но это всё усложняет дебаг. Подписка -отписка там тоже неявная из -за проксеи этих, вы получается... Очень легко что -то пропустить и не заметить. То есть там очень много неявной... слишком много неявной работы.

Но в целом из минусов, там есть еще ряд тоже недостатков таких, типа экосистема слабее, у редакса, причем значительно. Они не очень любят вообще переиспользуемые библиотеки писать, мобиксеры, я так замечаю, они любят либо копипастить что -то, либо свой маленький более плейт, либо какие -то написать и все. Ну а МСТ?

Мобык стоит 3 в принципе. МСТ это такой фреймворк, он больше для архитектуры, но он не дает тебе очень много готовых решений. Форм нет, персист у МСТ есть, я не знаю. Там есть возможность брать снапшот, но там нет возможности, там нету адаптеров самих, которые бы...

Да, писали именно в индекс DB какой -нибудь, следили за версионированием и так далее. В нормальный был, я с мою финивоку это сср делал. Ну да, базовые вещи, конечно, так можно делать. Тут вопрос, короче, на жора какого -то. И всё -таки в MobX его меньше, чем в редакции, но всё равно в редакции больше всяких штук, хотя там, опять же...

Kirill Mokevnin (01:07:48.302)
Redux Form уже очень не актуален. MobX Form есть, но, насколько я понимаю, там странно немножко сделан, не очень его любят. В React 'ами, кстати, формы они все еще в экспериментальном. Экспериментальный это очень пакет, то есть он нестабильный. Можно посмотреть, как это можно сделать, но использовать в продакшене пока не рекомендуется. Хотя мы над этим работаем, и есть продакшен -приложение, которое использует React 'ом Form.

Вот. Ну и в целом, да, есть такая вот особенность, что редакс, очень… И вот сейчас в современном мире с экосистемой большие проблемы в редаксе, она всё -таки, я считаю, слабенькая. То есть тот же РТК, он решает только проблемы самого редакса. То есть он не решает проблемы, которые… Вот не было бы у тебя редакса, у тебя бы не было этих проблем. РТК решает только проблемы редакса.

Есть RTK Query — классная штука. В MobyX нет RTK Query. В Riatum есть Riatum Async, который очень мощный. И, наверное, из таких библиотек есть только Effector, которого есть… вылетело из головы, как называется… Ну, в общем, тоже… Farfetch. Farfetch. Farfetch, да. То есть довольно хорошая алиба, позволяет сосинхронично и как -то работать с запросами к бэкэнду.

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

В этом, кажется, основная суть для меня всего ArtCock Larry и ReactCock В Моббиксе такого нет, В Моббиксе такого, правда, нет. Я тоже не видел. Вот в Effectory ребята сделали Игорь. Ну, я сделал Игорь, а фамилию снова не назову. Извините. Накапал, тоже сейчас забыл.

Kirill Mokevnin (01:10:07.822)
Ну вот фактически есть только в редакции, риатом и эффекторе. эти вот, либо именно которые... Почему... Вот, например, частая связка, бывает сейчас Зустанд и... Я через «з» буду говорить. Зустанд и React Query. Это частая связка. Но дружить их, когда вам нужно передать данные из одного в другой, бывает больновато. Я ровно этим занимался, когда говорю про то, что не хватает двух обзёров, которые были... соединяли их. И я...

пострадал с этим. А когда оно всё построено на одном фундаменте, как в RTK Query, именно редаксовском, как в Effectory или риатоме, это, конечно, намного удобнее, то есть оно и надёжнее работает, потому что у нас нет этих гонок подписчиков, и удобнее по DX, и там, ну, логи тоже в некоторых случаях можно получше, получить. Вот. В MobX вообще в эту сторону ничего нет, они там типа «дафеч, напиши, и всё нормально будет».

То есть там про кэширование речь не идет. Погнали тогда, Блиц. Плюсы, минусы редакции? Ой, моб -экса. Также поверхностно. Ну давай, плюсы, моб -экса.

Плюс МАБЫКС – это автоматическая оптимизация производительности на очень высоком уровне. То есть ты про Перф вообще практически не думаешь никогда. Это всё -таки устоявшаяся тоже такая мейчерлиба, по которой тоже, наверное, чёт ЧАДЖИПИТИ будет неплохо отвечать, и у которой есть комьюнити. Ну, русскоговорящая в телеграмме, оно точно достаточно большое, там, может быть, не суперактивное,

Ну, по моим ощущениям, в общем, MobX Community и React примерно на одном уровне. то есть, ну, это достаточно активный комьюнити. То есть они... MobX иногда засыпает, и React тоже, там всегда можно получить какой -то фидбэк. То есть ты пришёл, что -то спросил тебе, там кто -нибудь что -нибудь скажет. Вот. И документации по MobX, ну, наверное, относительно хорошо. То есть если мы берём тот же Zustand, то уже с ним сравниваем, то, конечно, там...

Kirill Mokevnin (01:12:21.07)
намного меньше всё равно. И документации, и кейс стадис каких -то по МАК -БЫКСу намного больше инфы. И на нём часть сложных вещей намного проще будет делать. Но из минусов это то, что слишком магически всё, как говорится, в самом начале, когда он вышел, типа магически, магически, оно слишком хорошо работает из коробки. Потому что есть edge -кейсы, когда оно не работает. И дебажить это сложно. Соответственно, ещё из минусов это декоратор, который на

Декораторы сейчас опциональные, по -моему даже в документации рекомендуется их не использовать, что авторы поняли, что это очень отпугивает. Там типа «мои кавталы всё, робу, пишешь, и оно всё работает». На самом деле, МАБ -Х можно даже без классов использовать, причём довольно удобно, писать «конст», что -нибудь равно «атом -бокс» или… В общем, да, его можно использовать нормально и без декораторов. Я уже

минусы, это не записываю. Но вот использование прокси неявное, использование экосистемы слабее, bundle size достаточно жирный, 15 -7 килобайт, по -моему. Вроде это не вопрос, но с миру по нитке. Вот меня есть пост в ортологии про базовый вес. Я там, кажется, хорошую аналогию провожу, рекомендую почитать. Почему всё равно стоит библиотеки выбирать, которые поменьше весят из…

Ну вот, говорю, с миру по нитке, если ты здесь забьёшь, здесь забьёшь, у тебя там бабах. А если ты здесь чуть -чуть сэкономишь, здесь чуть -чуть сэкономишь, в итоге ты получишь профит в два раза, например. И это уже может быть значимая штука для какого -нибудь чувака, у которого телефон слабенький. И понятно, что ЦАУ у всех разное, но это такой, в общем, сложный вопрос. Если есть возможность сэкономить, лучше сэкономить по bundle size у нас, в нашей индустрии. Вот. Это что...

по MobX. и там, да, там, конечно, тоже нет никакой там арности. Теперь давай по… Я даже не знаю, стоит ли по отдельности. Если брать RTK query из устант… Ну… Просто React query из устант. Да -да, React query. Как бы не ощущение свои сказать, а факты. В общем, смотрите,

Kirill Mokevnin (01:14:43.246)
Зустанд – библиотека, которая… исходники которой умещаются на один экран. Концептуально это очень круто, это легко, это здорово, это легко дебажится относительно,

Практически нельзя написать такое маленькое количество кода и решить большое количество проблем. Понимаете? Ну так не будет такого просто. Сделали бы уже давно. До Zustand уже существовало бы уже все. Вот. И Zustand он... Вот он типа пытается эксплуатировать принцип Parret. Мы тебе легко

очень базовый кейс, очень базовый кейс, ты типа легко решишь. Но все остальные кейсы, и вот это там, может быть не 20%, там даже больше, 40 скорее, тебе придётся что -то остылить, короче, самому разбираться, там типы более плейтить, не знаю, какие -нибудь, даже не знаю, как там батчинги работают, наверное, на промиссах, ладно, предположим это лог. Но смысл в том, что селекторов там вообще нету, рьюзабельных, то есть ты...

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

не сразу очевидно. есть много людей, которые пытаются там SSR делать, сталкиваются с тем, что оказывается это довольно больно и сложно. А больнее всего и сложнее то, что там можно словить баги, которые сходу и не видны. То есть Zustan создает... Stateful получается синглтоны. Это опишка, которая создает синглтоны. И у тебя в каждом синглтоне хранится... Один тот же стейт, короче, логично. И там нет контекстов. То есть ты, когда SSR делаешь, у

Kirill Mokevnin (01:16:50.926)
на каждый новый реквест будут вот эти вот сторы с одними и тем же данными предыдущего пользователя.

Ну, это как бы так, принципе нельзя делать. Всё, забудьте, никогда так не делайте вообще. И чтобы... Вот я, как слышал, Елена Ледвиновна рассказывала про то, как они решили эту проблему, они написали, получается, Middleware на все сторы. То есть, они сделали свою фабрику. Ну, это нормально, в принципе, решение. Сделали свою фабрику стора, добавили туда Middleware. Все сторы создают только через эту свою фабрику.

в Middleware, что происходит? На каждый request перед его началом происходит reset всех стейтов. Но... Ну, норм как бы. Но, во -первых, в документации до сих пор этого нет, и вот это очень сильно подозрительно и плохо, что там не освещается такой, как бы, очень проблемный, неочевидный и небезопасный, потенциально вообще очень проблемный момент.

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

потому что ты что -то засетил вроде, а бах, оно пропало из -за другого реквеста. То есть ты за этим никак не уследишь, это надо всё помнить и знать. И узустанно, много таких мелких проблем. Короче. Соответственно, то, касается React Query, он... Хорошо вот для тех, кто такие прям реактор -разработчики, не хотят никуда уходить из как бы реакто,

Kirill Mokevnin (01:18:58.094)
прибиваться к нему, вообще их не парят. В принципе, это нормальное решение, но тоже надо понимать минусы. Оптимистик -апдейты там сделаны, просто их нет. Я бы не сказал, что там есть типа частный случай. Как решить частный случай? есть вот пример в документации. Но по факту там… Да нет там никаких оптимистик -апдейтов, там нужно это всё руками как бы что -то придумывать, стоит и дублировать. Это не очень хорошее решение.

Соответственно, принципе, работа с локальным стейтом там очень плохо сделана. Инвалидация кэша там тоже не очень удобная и яновная в некоторых случаях, когда вам нужно что -то точечное сделать. И сам кэш получается, он тоже вроде бы глобальный, и его можно целиком, например, заснапшотить или там заперсистить. Но зачем вам весь? Вам скорее нужно конкретные квири, но как раз -таки...

Возможность за персистить конкретный query нет, вам нужно идти в глобальный cache и из него при каждом каком -то движении вычислять только то, что вам нужно. То есть мы разбиваем логику нашего какого -то endpoint, то что он персистится, куда -то где -то описывается другими. Короче, смысл в том, что React Query уже очень хорошо решает базовые задачи. То есть если у зустанда него этот порет где -то 60 -40, то

вы из 60 % кейсов решаете вот очень быстро и легко, но 40 % будете страдать, то у React Query реально получше. Там, например, 80 -90 % кейсов вы будете решать достаточно хорошо, а 10 % страдать. Вот. Ну и естественно, что надо понимать, что React Query ограничен тем, что это все -таки библиотека для сетевых запросов. То есть она не предназначена

для локального управления. Можно теоретически использовать, но это всё равно очень неудобно. Грубо говоря, например, захотите вы какую -нибудь логику на конечных автоматах написать, и в React Query это будет сделать намного сложнее, чем на каком -нибудь эффектре или риатом, или моб -эксе. То есть написать свою реализацию конечных автоматов. Причём конечный автомат — это не что -то большое и сложное, это то, что вообще надо...

Kirill Mokevnin (01:21:17.262)
приходится иногда применять в разработке. Да, ну и остался, например... Вообще есть много разных еще библиотек со своими там Legend State, вот сейчас... Jotai. Jotai, да. Но они... Я так скажу, если вы хотите не мейнстрим, но пугаетесь, ну я объективно говоря, локальных решений типа там Effector или Reatom, которые могут в рамках всего мира казаться немножко нишевыми, то возьмите преактовские

Это... вот у них соотношение по поре это прям суперское. Потому что вы, даже если будете страдать, то будете страдать хотя бы с нормальным примитивом, который вам позволит сделать что -то сложное, а не будет мешать делать что -то сложное. То есть вам придётся много написать что -то сложное своего бэллирплейта. Плюс, приактовские сигналы очень похожи на то, что будет в итоге в стандарте джаваскрипта. То есть унативные сигналы. Но не то что прям очень -очень похожи,

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

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

У некоторых зарубежом очень прям популярен. По -моему, у циана виджеты на приакте есть, и это только российский рынок, а зарубежом он прям очень популярен, потому что ну и у гуглер делал, бы он его популяризовал в свое время, и сейчас приактор растет. Соответственно, как и приактовский сигнал. Ну нет, вью все еще обгоняет, у приакта 3 700 викле, у вью 5 миллионов. Ну да, догоняет, уже не в половину, уже не в два раза уже так.

Kirill Mokevnin (01:23:43.086)
Ну это всё равно… Согласись, как бы… % от вью – это ого -го, это прямо очень много. У риатома очень круто, что и у эффектора есть… и у моб -экса есть биндинги к большому количеству разных библиотек. То есть, мы сейчас много про реакт говорили, но есть же эффектор… Ой… Есть биндинги риатома к эффектору. Есть вью, да, там, солид

Svelte, Angular и есть, например, Lid, ещё довольно популярный в некоторых кругах, за рубежом тоже. Так что, ну ещё там пачка уже более мелких, конечно. Если вам нужно, чем более универсальное решение вам нужно, тем больше вам всё -таки, наверное, лучше посмотреть сторону Effector или Eriatom. Ну, по сравнению, про Effector что сказать? Меня считают хейтером просто Effector, потому

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

Хотя в том же риатоме и в любой сигнальной библиотеке фабрики просто работают. То есть, нужна фабрика каких -то сторов, вы её написали и всё, не думайте о нём. А в эффекторе вам нужно следить за горячими связями между сторами, это всё динамически делать, есть, переусложнение. Но да, экосистема неплохая, документация, ну так себе, как бы, не знаю. Ну... Всё нормально.

нормально, Там просто местами она хорошая прям, то есть есть места прям очень хорошие, а есть места, которые слабо проработаны. Ну, в целом, как у риатом? Документация, мне кажется, у нас примерно сейчас на одинаковом уровне, то есть это такой… В принципе, вопрос ложный, я бы сказал, документация. У Зуштанта это было. Посмотрите документацию, либо там сколько у него сейчас, полтора миллиона скачиваний, и там документации почти нет.

Kirill Mokevnin (01:26:06.798)
Или её очень мало? Её раньше вообще не было. Сейчас она появилась. Раньше было только вот этот... С медведем вот этот лендинг. И не было кнопки documentation. Все документации были просто в ритме. И как бы автор вообще не парился. Это было три года назад, когда я впервые пробовал Зуштанд. Его тогда не так хайпили вообще, но вот я уже тогда его попробовал. Он в реальном проекте. В принципе, это типа было сносно. За исключением того,

Люди пытались через него в том числе делать запросы и как -то хранить, как -то это всё хэндлить. А я, вспоминая свой опыт, да, и нас саги, и вот это всё, и над сагами мы делали свой РТК, ну, что -то, ну, React Query, что -то подобное React Query над сагами. И это было прям ну, такое очень сложно мустрозно. И я примерно то же самое написал для Зуштанда. Вот, то есть, что -то сложно мустрозное. И он как бы, ну, никак не помогал, но он особо не мешал.

В нём всякие прикольные штуки решены реакторские боли типа зомби -чудранов, например. Там нас была проблема, конкретно зомби -чудранами. С Зустом, где его внедрили, она ушла. Кстати, зомби -чудраны — это проблема как раз -таки нескольких списков подписчиков. То есть, если все придут на одни и те же сигналы, то зомби -чудраны перестанут существовать. Ну да, у нас вот решилось с тем, что мы взяли тогда.

Зуштанд, везде его внедрили, и это как бы пошло. Вынесли всё в него, получается, Ну да, да, всё в него вынесли, и всё стало хорошо, потому что у был RX, Зуштанд, и ещё, короче, реакторский контекст. Вот, было всё, как бы пришли к одному, стало полегче. Вот, например, из такого. Ну и я, да, я как бы смотрю на риатом, давно уже смотрел, всё никак не это.

Не решался его взять, но кажется, что он уже достаточно крутой, и его реально можно пробовать брать. Спасибо. Расскажи примерно в принципе в каких проектах ты уже встречал, собственно, рятом. И ещё, наверное, из того, что сейчас Фронтово есть, это, наверное, -то архитектурная часть, ну, архитектурное, смысле, знаешь, строение папочек. Вот. Всё -таки OE Effector 'а, под ним есть FSD.

Kirill Mokevnin (01:28:30.318)
которые, ну, во

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

Слушай, по -моему, я в чате FSD как раз встречал инфу о том, что риатом хорошо подходит для FSD. Мне кажется, я там видел такие сообщения. Про проекты для риатома, которые используют риатом. Ну тут как бы сложно сказать в том плане, что их много. То есть это не один, не два, там их десятки. Есть... я точно знаю, что риатом используется в крупных компаниях. В всяких зеленых компаниях крупных используется.

в желто -оранжевой компании частично используется. Правда, его не использовали, но, по -моему, сейчас тоже что -то где -то затаскивают.

Ну а в примере проектов не знаешь именно для чего, для каких целей его затаскивали? Ну то есть, всё -таки там тоже была какая -то мотивация? Слушай, State Manager — это такая штука. Вот есть несколько проектов, которые затаскивают Reactom, потому что он для микрофронтов нормально подходит. То есть, у нас же несколько есть разных адапторов, и у Reactom есть такая специфическая опишка.

Kirill Mokevnin (01:30:17.07)
она есть у MobX, справедливости ради, и, по -моему, даже не помню, еще. Может быть, даже где -то особо и нету. А заключается она в том, что можно подписываться на то, что кто -то на тебя подписывается. есть это Connect Hooks называются. И это, на самом деле, суперудобная штука для управления ресурсами.

у тебя есть, например, ты хочешь хранить кэш какого -нибудь там сокета, например, да? Или у тебя есть какой -то endpoint, который ты хочешь всё время pull -ить и кэшировать значение, Но ты хочешь pull -ить только когда тебя соответственная страница открыта. Логично, да? И в React 'ом как раз -таки очень легко это делается. То есть ты...

Да, ты описываешь какую -то логику асинхронную, которая что -то там делает, и она включается и выключается ровно тогда, когда тебе состояние от этой логики нужно. И возможность... Вот эта возможность, относительно мелочевая, и кому -то может вообще никогда не пригодиться. Но когда ты делаешь какие -то очень комплексные, переиспользуемые штуки, она прям супер пригождается. Вот, это первое. Второе. Уриатома

В целом, всегда разрабатываю... Тут как бы у всех людей разная мотивация может быть. есть у меня на проекте, на моём рабочем, текущем проекте долгое время не было риатома. И мы писали вообще всё на хуках реактовских и на контекстах. И у нас приложение 400 -500 тысяч строк. Оно гигантское. Его делают уже лет 7 или 8, или я не помню сколько. И...

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

Kirill Mokevnin (01:32:32.878)
То есть идея была в том, что ты можешь на любой его проект взять. На маленьком ты используешь маленький набор фич, и как раз -таки не утопаешь в документации по каким -то огромному количеству других пакетов. А на каких -то более сложных проектах, которые ты знаешь будут сильно расти, ты, соответственно, вникаешь. Риатом концептуально, если брать только core пакет, он очень простой, то есть не сильно сложнее зустанда.

он может очень хорошо скейлиться вверх. И тут много разных вариантов применения может быть. И по поводу архитектуры, соответственно... Как вообще атомы структурировать? Если мы начнем беспорядочно атомы складывать куда угодно, изнанотно файлы с компонентами, наверное, до какой -то степени это будет удобно, но с какой -то момента это будет уже плохо.

Тут смотри, ну типа универсальной архитектуры нет, то есть тут нельзя посоветовать такое, что будет работать для всех. Тот же FSD, он ну очень много сил как бы требует на его реализацию. То есть он очень специфичный и много большой пласт задач, которые ты можешь сделать намного проще, короче, быстрее без FSD. Да?

И при этом есть задачи, которые действительно в FSD хорошо ложатся. И как бы брать за дефолт FSD... Ну, повторюсь, вроде как React 'ом прекрасно работает FSD, сложно вообще представить, что React 'ом где -то будет тяжело работать. Единственный контекст надо везде шарить, но он как бы тоже нужен для SSR, для тестирования. То есть это штука, которая тебя архитектурно уже ограничивает и помогает. И в целом...

сами опишки риатома во многом задизайнены так, чтобы тебе архитектурно помогать. Но справедливости ради, естественно, можно как -то что -то не очень хорошо написать. И тут лично у меня есть пост опять же в ортологии, просто чтобы не рассказывать, это просто древовидная структура. То есть вот как React пропагандирует компоненты писать, «всё разделяем на дерево, если нужно что -то объединить, выносим выше». Точно так же ты файлы организовываешь, тебя файлы — это тоже

Kirill Mokevnin (01:34:54.094)
То есть, организуешь всё по виджетам, бы. То каждая страница, может состоять из нескольких виджетов, виджеты из компонентов. Единственное, ты выносишь в общее что -то — это UI -компоненты в отдельный пакет, а какие -то переиспользуемые части логики или там страниц или виджетов, ты просто выносишь наверх. То есть, да, тебя в какой -то момент может появиться помойка...

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

Так что я бы тут сильно не переусложнял. Я знаю точно единственное, что стоит добавить. Так я говорил, в рятами и любых сигнальных библиотеках, если вы возьмете какую -то сигнальную библиотеку, очень просто делаются фабрики. И многие используют, вот как в том же Vue и Solid, вы берете сигнал, вы просто создаете прямо в компоненте и прокидываете ниже. Это нормальный подход на самом деле, компонентный, очень простой, эффективный. И...

И мы, кстати, сейчас на него мигрируем. В моём рабочем проекте мы на такой подход ре мигрируем. Мы сейчас будем делать контексты, из которых можно вытаскивать обсерватор атомы, а не значения. Ну или сразу значения, чтобы удобнее было подписывать сток на определённые. Ну а в другом проекте, наоборот, я участвую в другом проекте, котором получается модель.

она лежит всегда отдельным файликом рядом с компонентом. И если нужно... И там два способа её реализации. Первый — это просто типа export, const, что -то там, и надо, получается, сбрасывать эти атомы, когда отписка происходит, а компонент ремонтится, нужно вручную... Unmount, ну, reset it state. Но это не очень удобно, конечно. Это прям вот большой пласт багов может породить. в некоторых только случаях. Проще всего делать фабрику.

Kirill Mokevnin (01:37:19.278)
То есть файл модели, в которой фабрика, которую ты вызываешь в компоненте, используешь по месту. Но если нужна модель, которая должна уничтожаться при, грубо говоря, Unmount при этом ее нужно шарить.

То есть не подходит вариант создать её в компоненте и проб с дриллинга большой делать или заводить отдельный контекст на то, чтобы создать модель. Это нормальное рабочее решение, но это всё boilerplate и неудобно, и разработчик сам по себе обычно не хочет этим заниматься. То есть разработчик хочет максимально простым способом написать, доступным. От этого как бы плохой код и плодица, которая в перспективе плохим становится.

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

Обычно, когда нам нужно фабрику создавать, у нас есть пейджа, открывает какой -нибудь товар по какому -то ID -шнику в Урле. Соответственно, мы просто подписываемся на этот ID -шник, и от каждого ID -шника в Atom пересоздаем инстанс фабрики. компьютер от Atom фабрикой выходит. Я не знаю, понятно ли сейчас или нет, я всё это озвучил, смысл в том, что… я смотрю видосик, поэтому не понятно.

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

Kirill Mokevnin (01:39:24.398)
у нас опишка остается достаточно простой в этот момент. Ну, кстати, прикольно, да, вообще -то выглядит. Ну и давай под конец -то ей какие -нибудь минусы риатома, наверное, поговорим о каких -то минусах. Какие они вообще есть, какие ты видишь минусы. И, может быть, какие в принципе есть, по -твоему, текущие проблемы у...

подходов с сигналами, подходов с реактивностью, сейчас минусы есть, ну и в том числе, да, минусы риатома тоже, в принципе… Ну все минусы ключевые озвучены в документации. нас… Моя отдельная гордость, что на главной странице документации у нас написаны все недостатки риатома, с которыми вы в первую очередь столкнётесь, это раздел limitations. Вот. Ключевое, что стоит заметить, в принципе, и вот

Это в статье «Реактивное программирование» разбирал. Реактивное программирование не везде нужно. Я вижу постоянную проблему, что когда берут какой -то инструмент, который удобно использовать как базовый примитив для всего, его используют и там, где это не нужно. То есть и тут как бы те же сигналы, как концепты вообще, и в риатами сигналы, которые нас ждут, они...

форсят писать как бы всё вообще реактивно и да, с этим могут быть проблемы. Надо себя сдерживать и контролировать. Это первое. Второе. Дебаг. Это тоже штука, которая касается вообще чего угодно, и вряд ли она частично решена. Я говорил про то, что можно отследить причину изменения, но проблема в том, что...

Интерфейс к этому пока что недостаточно хороший. То есть у нас просто логи сыпятся, можно посмотреть через логи, а почему поменялся такой -то стейт. Но это не очень удобно, короче, делать. Было бы хорошо отдельный UI, который рендерит какой -нибудь такой график или таймлайн, всех этих изменений, по нему прыгать. Вот так было бы круто и удобно, и это был бы действительно очень полезный инструмент. Сейчас этот инструмент фактически как бы есть, но пользоваться им... То есть

Kirill Mokevnin (01:41:48.814)
не ускоряет тебя в супер много раз, он скорее помогает в очень сложных ситуациях, а в относительно чуть -чуть сложных ситуациях проще, грубо говоря, концой лог поставить, чем что -то продебажить. что тут такой вроде плюс, вроде недостаточно он еще хороший. Ну и, не знаю, что... Количество скачиваний из NPM не огромное. Что скрывать?

Вроде у нас в чате там человек 250, наверное, добавлено. Я вот говорил, что нам постоянно приходят новые контрибьюторы какие -то, которые что -то… код. То есть я много кода не пишу вообще. В смысле большая часть триатома и документации, и кода, приходит… некоторые пакеты полностью написаны не мной вообще. Но 37 человек у нас чате, я смотрю. Но относительно это типа меньше, чем в зустенде. Вот. И тут сложно как

Русскоязычное сообщество точно достаточно активное у нас, активнее, чем в редакц -чате. Например, в редакц -чате вообще там какое -то всё время… В основном спам. Я там админ, и там в основном спам всё время сыпется, и редко люди по делу говорят. Кстати, да, вот обе проблемы, которые ты сказал, типа они везде нужно использовать, и кое -где есть другой концептуальный подход. Это подход к конечным автоматам, который, в принципе, немножко проще.

дебажить, что это как бы такая система, которая более явная, она ну абсолютно более явная, она требует больше boilerplate, но она сильно более явная и при этом ну, ослеживать изменения в конечных автоматах тоже можно, я как бы не говорю про какой -нибудь XState, он очень муструозный, но опять же можно делать маленькие конечные автоматы и тоже их использовать, в том числе как АТОМ, можно делать АТОМ со состоянием

и на него тоже так же подписываться, то есть так же стоять за изменениями и как -то реагировать на них и изменять его. Ну, это не альтернатива реактивности, То есть, справедливости ради, да, как бы сейчас стейк -менеджеры, двигаются, и вот React -Query – хороший пример, они двигаются не столько в реактивность, как бы, куда, ну, какие опишки добавлять в стейк -менеджер. Они двигаются в сторону решения прикладных проблем, например,

Kirill Mokevnin (01:44:13.742)
кэширование, фетчинг или описание каких -то асинхронных процессов. Вот Effector говорит, что типа с помощью него очень круто описывать асинхронные процессы какие -то. Я лично этим не согласен, мне очень не нравится. Мне кажется, вот на Cypress очень удобно описывать какие -то асинхронные процессы, и я стараюсь дизайнить риатом так, чтобы… Ну потому что правда, у тебя Cypress, вот код на

То есть, интеррационный тест, он показывает то, как бизнес хочет видеть реально работу твоего приложения. То есть, поэтапно, четко, step -by -step описаны какие -то шаги. Вот, то есть, ну прям step -by -step. Вот следующая строчка кода выполняется просто предыдущей. Говорят об этом. Вот. И нарядами частично можно так писать в таком стиле. То есть, там овейтишь, у тебя там конкурентность будет работать, что я считаю большим, огромным просто плюсом. То есть, ты...

Можешь у тебя... Ну, как на сагах. Ты описал, что у тебя много -много -много каких -то там овейтов отработало. Потом, если перезапускается процесс, то всё дропается, и тебе не надо практически ничего для этого сделать. Он рядом сам это отследит, и ты заново как бы идёшь. Но вот для описания процессов, с одной стороны, мы сейчас двигаемся в эту сторону, с другой стороны, да, конечно, автоматы,

Киллер фичи, который у них есть, который больше я нигде не знаю, это персист состояние автомата. есть, автомат может работать -работать, мы его зафиксировали в таком -то состоянии, заснапшотили, перезагрузили страницу, автомат продолжает работать. Это, конечно, прям крутая фича или там передали куда -нибудь по сети. Но очень большую цену это берётся. есть, Buller Plate, всё -таки... Тот же XState вообще жутко Buller Plate.

Кстати, какие еще библиотеки ты знаешь для описания конечных автоматов? Да, ну меня есть своя библиотека F -Smooth для конечных автоматов. В ней boilerplate сильно меньше. В ней есть примерно то же, что в принципе концепция, которая мне когда -то понравилась в React 'e, это работа с контекстом. И контекст как способ работать с DI 'ем. Потому что, ну, когда тебя есть подписчики, тебе в любом случае в подписчиках нужно иметь какие

Kirill Mokevnin (01:46:36.398)
и эти сторонние системы хорошо чтобы тоже управлялись вот этой всей твоей большой машинейрией. Потому что одно из меня каких -то таких больших идей это сделать в SM registry такую штуку над всеми конечными автоматами, которая будет управлять конечными автоматами как акторами. Вот и это позволит ну например многие вещи которые есть проблемы которые есть в каком -нибудь в программировании микроконтроллеров, программировании

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

Соответственно, легко сказать, что а давай теперь посмотрим, что внутри, и это будет как бы часть твоего дебага. Ты просто делаешь там этот рендер, вызываешь, и вот смотришь, там внутри. И это такой нормальный способ ну дебага конечных автоматов, потому что у тебя всегда есть... Также помимо этого у Кирилла Макевнина есть классный доклад про конечный автомат, который недавно был, и у него есть классная проблема, которую он там заметил. Это разница между атрибутами.

состоянием. как по мне, так, вообще реактивное программирование и вот все подходы, которые связаны сейчас с работой состоянием как стейт менеджерами, это работа с атрибутами. То есть у нас есть некоторые там, то что мы называем состоянием, то что мы называем состоянием, оно не всегда является состоянием процесса. Это атрибуты этого

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

Kirill Mokevnin (01:48:57.294)
у нас вот библиотека рятама синк, типа за промисс помогает вокруг промиса построить абстракцию, там всякие кэши настроить и так далее. И у него есть типа состояние пендинга у промиса, типа true -false. И как бы грубо говоря, первая бага, с которой мы столкнулись, это когда у тебя транзакционность отрабатывает, типа промисс зарезолвился, у тебя какие -то данные, на основе данных промиса начали вычисляться, упала ошибка, откатывается транзакция.

и откатывается информация о том, что Промес зарезолвился. И это как бы, ну, это бред полный. То есть у тебя типа Промес зарезолвился, а информация об этом не сохранилась. вот когда... Да, то есть это... Потому что состояние Промеса, то, что он зарезолвился, это как раз -таки внутреннее состояние, конкретно вот этого актора, считай.

какие -то дополнительные вычисления, в зависимости от того, на каком мы масштабе смотрим, это дополнительные атрибуты. Это я имел в виду. Я правильно тебя понял? В целом в том числе, например, у тебя есть состояние заказа, и у заказа есть, например, прист. В тот момент, когда заказ оформлен, у него появляется, например, цена со скидкой, ну вот оно вычисляется в этот момент. И всегда, когда у тебя есть… Это инвариант системы. Вот то, что еще называется по -другому, это инвариант

И, например, если брать у промиссов, как таковых самих промиссов, атрибутом, он с натяжкой может служить то, с чем он зарезовится, то есть у него есть как бы сам процесс, то есть есть как бы… как бы… pending, full field, rejected. И вот когда он переходит из pending в одно из следующих состояний, у него атрибутом может служить то, что в нём лежит, например.

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

Kirill Mokevnin (01:51:19.982)
Большая интересная тема. Я думаю, те, кто заинтересуется, могут посмотреть доклад Кирилл Маккевнина на колесах. Он уже выложен. Я не уверен, выложен ли он с Холли. Тех, кто уже видел на Холли, крутой доклад был. Так что да, я думаю, ребята, кто нас смотрит и кому тоже понравился выпуск, который мы записали сегодня с Артёмом, ему большое спасибо, что он пришёл.

Мне Василию Кузненькову большое спасибо, что я тоже пришел послушать и вам, надеюсь, это тоже понравилось, так что жмите лайки, колокольчики, все дела, подписывайтесь на канал Хекслита, до новых встреч. Пока, спасибо, тут позвали и слушали.