artalog
4.26K subscribers
568 photos
42 videos
40 files
944 links
Развернутые ответы на вопросы в чатах, мысли от рабочих процессов.
Вопросы - @artalar.
Download Telegram
У меня выдалась какая-то неделя зависимых запросов, хотелки по этой фиче и связанные проблемы валились на меня каждый день. На проде я из-за этого сначала создал, а потом пофиксил блокер. В чате реатома было много дискуссий.

Краткие итоги своих мыслей я выложил в канале реатома: https://t.me/reatom_ru_news/228

Расскажу сюда еще немного контекста, мне кажется это интересно.

Задача известная, зафетчить одни данные на основе других асинхронных данных - с другого эндпоинта. Обычно, это выглядит так: юзер инпут -> запрос А -> запрос Б.

Доки react-query. Напомню, там нет трекинга и автоотмены цепочки операций. У меня на проекте похожий хук, только поле enabled называется actual. И вот в чем проблема, мы проставляем actual, обычно, как !pending от зависимого запроса. Первый запрос завершается - actual переключается в true и рефетчит данные (сейчас речь о том когда второй запрос зависит от первого, но семантически, не параметрами, данные там из одного во второй не прокидываются).

Но! если первый запрос при маунте actual: false, ждет какой-то пользовательский ввод или еще один запрос, то его pending будет тоже false и конечный запрос будет с actual: true и пойдет выполнятся - хотя это не верно.

Мы решили на этот случай добавить и использовать флаг ready / fresh или еще как, который будет означать что данные уже зафетчены (и сейчас не фетчаться).

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

Хотелось бы как-то явнее, но все еще декларативно описывать зависимость одних ресурсов от других. Какие есть варианты?

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

У $mol и jotai используется suspens / алгебраические эффекты (выкидывание промиса) для того что бы позволить писать обычный процедурный код, но хендлить реактивность и асинхронную инициализацию. Так вот, у этого подхода куча проблем! Jotai просто не работает в половине случаев, а в $mol далеко не всегда понятно как это работает, и накладывает сильные ограничения на кодстайл - все вычисления должны быть идемпотентны (вы не можете вызвать просто Date.now - нужно мемоизировать), вот отсюда можно отмотать вверх и почитать тред: https://t.me/mam_mol/131401

Что делать-то, в итоге? Тут подробнее рассписал как я планирую это реализовать в реатоме: https://github.com/artalar/reatom/issues/530#issuecomment-1683873873
🤔3👍21👌1
В последних стандартах обсуждали миграцию редакса на esm. Я выскажусь по теме рядом - организация OSS проекта с системой плагинов.

Какие есть варианты? Монолит или разбиение на пакеты, а пакеты в монорепе или любые в NPM.

В https://github.com/artalar/reatom монорепа с кучей пакетов и это очень удобно.

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

Надежность - это хорошо, но удобно ли это для сторонних контрибьютеров? Если кто-то захочет написать либу поверх реатома и опубликовать ее в npm, она будет выглядеть белой вороной, потому что все основные пакеты лежат в скоупе @reatom. Решается это очень просто - нужно быть максимально дружелюбным к сторонним контрибьютерам! У нас есть подробный гайд как вносить правки. Есть возможность сгенерить темплейт для нового пакета одним скриптом - это очень удобно, учитывая что очень мало людей знают как наполнять package.json и паблишить пакеты правильно.

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

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

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

Нужно вырабатывать новые стандарты платформенных пакетов. Мне, пока, нравится все как в Реатоме организованно. Интересно, какие улучшения откроются в будущем.
👍13
#доклады

React-query VS reatom/async — конфигурация против композиции

Сегодня расскажем о новом хардкорном докладе на HolyJS 2023 Autumn.

Постоянный спикер HolyJS и создатель библиотеки Reatom Артем Арутюнян устроит баттл между react-query и reatom/async. Посмотрим, что лучше применять в рабочих задачах — специализированную библиотеку или библиотеку общего назначения с набором хелперов.

Подробности и билеты на HolyJS 2023 Autumn.
🔥15🤡6👍41
В чатике спросили как сделать горизонтальный скролл на wheel попроще. Я знаю такой хак - css only!
🔥95
Экспериментирую с отображением лога операций реатома. Читать сверху вниз, как таймлайн или git-log.

Оказалось, рисовать на SVG достаточно просто и интересно. Особенно радует, что его можно вставить напрямую в DOM и легко навесить интерактивность на узлы.

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

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

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

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

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

Отображение, пока что, максимально упрощенное, но общий смысл мне уже очень нравится. А вам? :)
👍75👎2
Есть популярный на западе стейт менеджер Jotai, у него пол миллиона скачиваний в неделю - это очень много. Меня частенько спрашивают, чем реатом отличается от него, типа и там и там “атомы”? В Jotai “атом” - это просто базворд, сейчас бы примитив они назвали сигналом. А в реатоме все идет от ACID и кложи, нейминг обоснован. Не то что бы это сильно важно… Про практические отличия я тут рассказывал.

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

Баг существует, примерно, с начала года. Повторюсь, пол ляма скачиваний. 14к звездочек на гихабе. Активное камьюнити и гитхаб. А толку? 🙂

И надо понимать, что это не Jotai такой ужасный, это норма в современном софте, к сожалению. Баги есть везде, даже, казалось бы, у популярных и проверенных временем либ.
🤡20👍11
Через 5 минут сделаю стрим в котором расскажу о проблемах написания биндингов в разным UI либам.
Live stream started
Live stream finished (18 minutes)
Все еще не понимаю чего он так популярность набирает.
🤡18👍1👏1
Вы заиспользовали все компоненты and.design на одной странице и теперь она рендерится 10 секунд. В конце рендера вы написали `Promise.resolve().then(some)`, но до этого, во время рендера, пользователь нажал на кнопку. Что отработает раньше?
Anonymous Quiz
52%
some
48%
onclick
🤪14
Кликните, пока красный.

https://microtasks-test.vercel.app/
#не_вопросы_для_собеседований

Что и где сломается при попытке запустить этот код?

async => async
await => await
async <= async
await <= await
🥴35👎15💩4🤡4😁3
Учились в ВУЗе (больше двух лет хотя бы)?
Anonymous Poll
61%
Да и НЕ жалею
18%
Да и жалею об этом
21%
Не учился
CleanShot 2023-09-03 at 17.41.19@2x.png
5.4 MB
Купил себе Pixel 6A ради хороших фото. Оказалось фокусное расстояние достаточно большое и макро делать нереально. Сначала я подумал.

Но вот вам фото кузнечика на 3x зуме, встроенные алгоритмы достаточно хорошо повышают резкость.

Вот еще два сравнения фото с 4x зумомом в RAW (слева) и в JPEG (справа). Цвета на сырую выглядят хорошо, но хуже на обработанном фото, зато резкость значительно лучше - мне вся эта грязь теперь сниться будет)
🤡5
This media is not supported in your browser
VIEW IN TELEGRAM
А ТС подрос! Вычисления на типах можно делать еще сложнее 🙂

Когда я последний раз тестировал трамплины, еле-еле считало “300+1”.

Сейчас попробовал на node: v20.5.1, TypeScript: v5.2.2, подумав справляется с “1000+1”.

Да и сама величина рекурсии подросла. Раньше на 30 сваливалось, а сейчас 90 может съесть.
🔥11