Elijah

MoscowJS 72 + siberiacancode = 🌞 Встречаемся на новом летнем MoscowJS вместе с Лемана Тех. Собираем фронтенд-сообщество, чтобы поговорить о технологиях. Ребята хорошие друзья с Докой 😆 — платформой с понятными статьями от разработчиков для разработчиков. Регистрация на офлайн уже открыта. Напоминаем: если используете промокод, то не забывайте нажать «Применить». Конечно же будет и онлайн часть, которую ваш покорный слуга будет стримить. Будем обсуждать, комментировать и хорошо проводить время и конечно задавать вопросы спикерам. Если вы хотите стать спикером, то я максимально рекомендую попробовать свои силы, подать заявку и выступить у ребят на митапе. Я лично знаю ребят организаторов и точно знаю, что они вам помогут с вашим выступлением, подробнее можно узнать тут MoscowJS: https://t.me/moscowjs Задать вопросы спикерам: https://moscowjs.org/qna/

effector-refetch Пока расскажу про библиотеку, которую я делал Зачем? Потому-что существующего туллинга просто не хватило. Не так давно мы с командой полностью мигрировали на effector-based стек и переехали на ff.effector.dev Но в фарфетчед было много недочетов, с которыми мы впоследствии столкнулись – отсутствие пагинации (infinite-query) из коробки, мало примеров и гайдов в доке, нет возможности настроить фабрику для запросов из одного места (приходится или сверху городить фабрику фабрик, или копипастить с перегрузками), поддержка Suspense (и работа на реальных эффектах), поддержка миграции с apollo/tanstack/farfetched одним codemod В итоге получилось сохранить одно и тоже API как в farfetched, но и расширить его – инлайн операторы (retry/cache итп), фабрики для запросов ({ createQuery } = createQueryFactory({})), новые фабрики (например для infinite-queries), кодген с heyapi, примеры работы с gql, websocket итп Также честные optimistic-апдейты, SSR, поллинг и примеры для всего на свете (vite, next, vike, react-router итп) Почему не контрибьют в farfetched? Потому-что хотелось изменить некоторые механики, расширить существующее апи и проверить некоторые идеи на работоспособность. Ребята обещают продолжить работу над farfetched, но пока у команды есть другие приоритеты. И как? Оно живое! Уже есть ребята, которые взяли его тоже в прод, принесли фидбэк и даже законтрибьютили в либу. Спасибо всем причастным! Дальше больше! 🙂 https://github.com/Olovyannikov/effector-refetch

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

@effector/reflect 10.1.0 ✨ Новая фича: mapProps const Hello = reflect({ view: Greeting, bind: { // ... }, mapProps: { label: { source: $user, fn: (user, props) => `${props.title} ${user.name}`, }, }, }); Спасибо @olovyannikov_frontend за пуллик! 📚 Документация: https://reflect.effector.dev/docs/reflect#deriving-props-with-mapprops

effector-eslint-plugin v0.19.0 ✨ Новое правило: enforce-exhaustive-useUnit-destructuring – требует деструктурировать все юниты, переданные в useUnit. Теперь стало значительно сложнее потерять юниты в компоненте и избежать лишних подписок. Вошло в пресет react - спасибо @olovyannikov_frontend за реализацию! 🛠️ Улучшены enforce-store-naming-convention и enforce-effect-naming-convention – теперь проверяются не только простые объявления, но и различные binding контексты (деструктуризация, параметры функций) 🪄 Исправлено no-units-spawn-in-render – теперь корректно подсвечивает factory.createModel() из effector-factorio внутри рендера 🪄 Улучшена работа mandatory-scope-binding – правило подсвечивает только потенциальные вызовы юнитов, теперь будет меньше ложных срабатываний 📚 Документация • Changelog 🔗

Коммунити, принес вам потрогать очередную дата-фетчилку для эффектора. Паритет с farfetched, фичи, которых не хватало, effect-based. Принимаются предложения, улучшения и все такое Постарался закрыть максимально потребностей) + девтулы, кодмод для миграции с фф, скилл для AI Нейрослоп из доки не вычищал пока, сделаем это ближе к релизу, если он случится :) https://olovyannikov.github.io/effector-refetch/

Данные не должны лежать в базах мёртвым грузом. Они должны двигаться. В своём докладе Илья Оловянников расскажет о «кинетическом» подходе к управлению данными: event-driven архитектуре и графах правил, где вы не управляете каждым шагом процесса, а задаёте законы, по которым он работает. 📎 Выложили программу митапа, так что теперь у вас точно на два повода пройти регистрацию больше! 25 июня, MoscowJS 71 x Школа 21 Регистрация | Промокоды | #moscowjs #moscowjs71

HOLYJS В С Ё! Ну, в смысле закончился HolyJS Spring 2026, дальше только через полгода :) Было круто – суперские доклады, которые я буду смотреть вместо сериалов в ближайшую пару недель, ламповое сообщество и просто самые лучшие люди :) Спасибо всем, кто пришел поддержать нас на стенде MoscowJS – мы старались, чесслово :) Дальше – больше! :)

Продолжаем сезон живых встреч: MoscowJS едет на HolyJS! В этом году мы будем стоять на стенде сообществ — а значит, будет не только «подошёл-послушал», но и «подошёл-пообщался» 😎 Что вас ждёт у нас на стенде: > Моковые собесы — можно безопасно проверить себя и получить честный фидбек. > «Норм или стрём в IT?» — обсудим горячие темы и холивары. > Игра «Контакт» — да, та самая, где нужен талант чтения мыслей. Приходите знакомиться, болтать, спорить про архитектуру и просто проводить время в кругу тех, кто тоже живёт JavaScript’ом ❤️ Увидимся на HolyJS 14–15 мая!

☄️ @effector/router v1.0.0 release candidate Новый роутер основан на идеях и коде atomic-router и argon-router. А так как последние уже не поддерживаются, то effector core team приняли решение о переносе проекта в организацию effector. Чтобы переехать нужно заменить зависимости предыдущего роутера на @effector/router@v1.0.0-rc.0 и @effector/router-react@v1.0.0-rc.0. Кроме этого, из ломающих изменений сейчас необходимо использовать historyAdapter(history) или queryAdapter(history) для router.setHistory(). https://router.effector.dev/core/adapters.html До полноценного релиза важно получить фидбек и истории переезда. В том числе, чтобы написать полноценный Migration Guide. Репозиторий: https://github.com/effector/router Документация: https://router.effector.dev 🧡

Коротко про Next.js — «Так App Router — это уже стабильно?» — «Да, с версии 13.4.» — «А почему у меня тогда в 14.2 падает продакшен?» — «Потому что experimental изменили на stable, но специально оставили 146 issue на GitHub, чтобы вы не скучали».

Кажется, что я никогда не видел майских праздников. Только работа, только х2 (sad)

Обожаю, когда оставляют отладочную инфу на сайтах. Это кстати https://theweldercatherine.ru/

Когда опенсорс это часть работы Не так давно наша кодовая база на effector на рабочем проекте стала расти с бОльшей скоростью и, конечно, сильно влиять на легаси код. Таким образом в огромных компонентах где смешаны бизнес-логика, ui-стейт, выполнение сайд-эффектов, преобразования данных, мемоизация итп, и туда стал проникать useUnit из effector. useUnit - хук (в случае реакта), который связывает модель со вьюшкой. Если передан стор, то он подписывает компонент на этот стор и обновляет компонент, если стор изменился. Если переданы события или эффекты, то useUnit гарантированно вызовет это событие/эффект в нужной области (scope). useUnit умеет "батчить" апдейты - если компонент подписан на несколько сторов/событий, то он дождется всех изменений и применит из разом, но только в том случае, если используется один useUnit. const Component = () => { const [user, products] = useUnit([$userStore, $productsStore]) } Если используется несколько useUnit, то магии не случится, и каждое обновление будет вызывать обновление (ререндер) компонента. const Component = () => { const [products] = useUnit([$productsStore]) const [user] = useUnit([$userStore]) } Очевидно – лучше меньше ререндеров, чем больше :) Но как нам контроллировать количество вызовов этого самого useUnit? Особенно в большой кодовой базе в больших компонентах? Вариант А – руками. Ходить по всей кодовой базе, менять самостоятельно вызовы, бить по рукам разработчиков, которые по каким-то причинам не соблюдают такое простое правило. Вариант Б – заиметь статический анализатор, который укажет на проблему и попробует пофиксить её автоматически. По этому пути я и пошел - написал правило для eslint-плагина effector'a, которое парсит вызовы useUnit и мержит их, если возможно, или подсвечивает warning с ошибкой, которая сообщает, что лучше так не делать. Хорошо, множественные useUnit устранили, но что если: - Мы использовали в компоненте какой-то store, но теперь он нам не нужен. Мы его удалили по месту использования, но забыли удалить из useUnit const Component = () => { // Используем $user, но не используем $products const [user] = useUnit([$user, $products]); return <UserCard id={user.id} /> } В таком случае подписка сохранится - если $products поменяется, то компонент тоже обновится. Неприятно. Для этого кейса тоже можно написать ESLint-правило! Парсим вызов useUnit (или его алиасов, если используете), смотрим на то, что было деструктурировано и сравниваем с аргументами, которые передали. Если аргумент есть, а деструктурированного вызова нет - сообщаем об этом пользователю. https://github.com/effector/eslint-plugin/pull/175

Привет-привет-привет! Мы так давно ничего вам не писали. Зато теперь нам нужно столько всего рассказать! > 30 апреля у нас будет юбилейный MoscowJS 70 🤩 > Празднуем вместе с X5 Tech. > Готовим для вас масштабную программу, запускаем аж 2 потока докладов. > Не обойдется без холивара за круглым столом. > Позвали на митап нашего друга Доку! Напомним, что вы можете не только её почитать, но и поконтрибьютить или заглянуть в чат. > И уже ждём твоей регистрации. При использовании промокода не забывайте нажать «Применить». Не пропустите анонсы докладов и спикеров 😘 Регистрация | Промокоды | #moscowjs #moscowjs70

Начинаем сезон!