JS challenge:

- you have a list of 1000 items
- you have an async function process(item)
- you need to process all items
- it needs to be done concurrently, but not more than 25 at a time
- collect items with errors

what's the cleanest way to do this?
libraries allowed

…

На скрине мой вариант решения :)

#не_вопросы_для_собеседований

Сколько логов будет выведено?

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

Да и вообще, не забывайте подписываться на наш YouTube канал и оставлять там побольше комментариев. На алгоритмы это не влияет, но нам очень радостно!

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

Как и какие данные передаются от сети к компоненту, от события в сеть, от страницы к странице, от функции к функции.

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

Это вкратце, за деталями - думать.

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

Супер кратко:
1. Уже больше года есть баг, при котором у вас не инвалидируется клиентский кеш, что приводит к отображению устаревших данных. Буквально вы редактируете сущность, затем возвращайтесь к списку сущностей и там видите устаревшие данные.
2. Люди из команды верселя появились в issue полтора раза, затем всё стало выглядеть так, словно это намеренное игнорирование проблемы.
3. Через некоторое время (практически год!) они дописывают документацию, показывают схему кеша, но проблема не решается.
4. Согласено схеме, люди должны использовать функцию, которая приводит к инвалидации кеша, однако даже на приложениях для личного использования легко завалится за лимит в 100 инвалидаций, которые предусмотрены бесплатным тарифом.

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

Ну или иными словами, используешь app routes? → плоти

https://github.com/vercel/next.js/issues/42991#issuecomment-1670794471

React.js в 2023

Десять лет назад была создана самая популярная библиотека для SPA. Может ли успех длиться так долго и что будет дальше?

Начнем с маркетинга, политики и социологии. У меня в них околонулевые знания, все нижесказанное просто мнение старпера.

Я уверен что 2/3 популярности библиотеки - это хороший маркетинг. Конечно, лейбл фейсбука сыграл не малую роль в продвижении реакта. "Все ли пишут новый фейсбук"... Но маркетинг не обязательно должен быть целевой, это может быть удача зацепить ярких фанатов и амбасадоров, набрать критическую массу сарафанного радио. Проблема в том что иногда, как вышло с реактом, этот процесс становится очень инертным и не затухающим. Куча человеков ввязалась в какую-то тему и будут ее отстаивать просто по принципу "мое самое лучшее".

Нам свойственно популярность приравнивать к качеству, хотя это не так. Можно апеллировать к большому количеству документации и сообществу, готовому придти на помощь, но реальность намного сложнее. Хорошая документация (react.dev) появилась 5 месяцев назад. Давайте еще раз, самая популярная в NPM библиотека для фронта обзавелась нормальной документацией только спустя 10 лет разработки. Ладно, предыдущая дока была не плохая, но множество моментов в ней было опущено. Хотя, и в новой документации все еще много чего не раскрыто или раскрыто не полностью. Конечно, есть множество курсов, статей, даже книг. Но на сколько они достаточны и корректны, актуальны? Я не говорю что с документацией у реакта все плохо, вполне хоршо, но я бы не идеализировал этот фактор и не переоценивал его значимость. По моему опыту, самое полезное что может быть - это комьюнити. Но. Вам комфортно в @react_js или заходить туда скорее не приятная необходимость? 😉

Экосистема. Ryan Florence - автор самого популярного пакета для роутинга react-router, который ломает обратную совместимость каждый год 🤦‍♂️🤦‍♂️🤦‍♂️ пишет, "а че это у нас в экосистеме нет 1-2 хорошего юй-кита для всех". Действительно, нет.

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

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

Хуки - это не способ выделения логики, это жесткая привязка к компоненту в частности и к реакту в общем (код на хуках вообще не портабельный). У Angular, Vue и других библиотек реактивный примитивы - это отдельная библиотека. Я не говорю что код логики нужно все время переносить между фреймворками, но когда он не привязан к вьюшке - это хорошо, его легче писать, перемещять, тестировать. А писать логику на пачке useEffect, многократно логировать данные в ререндерах и пытаться понять что лишнее, а что нет, уфф...

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

Еще напомню про квирки React.js.

Конечно, в реакте много хорошего: очень редкие breaking changes, синтетические события удобны и надежны в рядовой разработке, иммутабельность и простота.

Но как все выше написанное взвесить вместе?

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

Реакт - микрофреймворк в специфическом стеке фулстек разработчика. Он точно не нужен большинству. Практика GraphQL показала что даже часть ответственности бекенда отдавать фронту - задача тяжелая и далеко не всегда профитная.

Куда вам уходить с реакта? Простой и надежный ответ (далеко не идельаный) - vue.

А я пойду пилить свои велосипеды.

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

Описывать хоть немного реактивную логику нормально сейчас очень сложно. С любым тулингом. Пока примите как данность.

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

...

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

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

Иконки и JSX.

Вот хороший обзор: Breaking Up with SVG-in-JS in 2023.

Но мне стало интересно, можно ли использовать JSX и компоненты для удобства темизации и параметризации, но не рендерить их в DOM?
Накидал прототип. Позамерял потребление CPU через профайлер - разницы не заметил =( Есть идеи что я мог сделать не так или тут впринципе нечего оптимизировать?

Спасибо всем за комментарии! Обновил песочницу, поправил способ замера, задеплоил прод версию (реакт в деве делает много лишней работы): https://csb-x6qhq3-azxnw4k6s-artalar.vercel.app/

Результаты, примерно, такие:

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

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

Песочница

А вывод такой, нет браузерного апи планирования собственных задач в нужное время. Мне, как автору библиотеки, нужно зашедулить колбек после отработки всех подписчиков на текущее событие. Сделать это в текущем таске невозможно. Добавлять и удалять временного слушателя на текущее событие не безопасно из-за preventDefault, а использование setTimeout иногда может отложить задачу на несколько фреймов - не вариант.

Для меня все это очень большая пичалька и головная боль. Буду еще копать, может найду какие-то хаки, все же. Если знаете - подскажите, пожалуйста :)

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

Хорошим балансом вышла статья Отменить нельзя продолжить, разбирающая с иллюстрациями на простом примере серьезную проблему. Однако, для создания большего количества подобных материалов требуется много времени и мотивации. Уже несколько недель я постепенно готовлю простое и практичное введение в Reatom для разработчиков React, но мне не хватает ресурсов, чтобы его завершить.

Я хочу снять видео на 10-15 минут, в котором покажу, как можно упростить и оптимизировать работу со стейтом в React, добавив щепотку Reatom, при этом оставаясь в рамках компонентной модели React.

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

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

Каналу осталось несколько десятков человек до 2к подписчиков. Давайте когда это случится - отпразднуем это выходом нового видео 🙂 Можете ускоренить это шарингом и рекомендациям среди друзей - https://t.me/artalog/187 🙏

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

Краткие итоги своих мыслей я выложил в канале реатома: 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

В последних стандартах обсуждали миграцию редакса на esm. Я выскажусь по теме рядом - организация OSS проекта с системой плагинов.

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

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

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

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

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

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

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

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

#доклады

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

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

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

Подробности и билеты на HolyJS 2023 Autumn.

В чатике спросили как сделать горизонтальный скролл на wheel попроще. Я знаю такой хак - css only!

Экспериментирую с отображением лога операций реатома. Читать сверху вниз, как таймлайн или git-log.

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

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

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

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

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

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

Отображение, пока что, максимально упрощенное, но общий смысл мне уже очень нравится. А вам? :)

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

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

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

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