FediScanner

#react

← Back

Удалить полпроекта: как мы переписывали MobX‑сторы на React Query в большом Next.js‑проекте

Привет. Я Дима Рагозин, фронтенд-разработчик в KTS . Эту статью я хочу начать с предыстории. Полтора года назад на проекте для одного крупного клиента мы получили задачу — ускорить главную страницу. К тому моменту в кодовой базе уже жили два отдельных фронтенд-приложения под две разные платформы — CSR-версия (Client Side Rendering) и SSR‑версия (Server Side Rendering), — а MobX‑сторы все время жизни проекта разрастались вместе с функциональностью. Каждый новый экран приносил еще один класс (а то и несколько), еще кучу связей, и в какой‑то момент мы стали замечать снижение воспринимаемой скорости приложения, избыточные HTTP‑запросы, сложности с поддерживаемостью и другие проблемы, которые становились критичнее по мере роста проекта. В статье я расскажу о том, как мы шаг за шагом перевели такие сторы на React Query, сократили код вокруг запросов на ≈50 % и практически избавились от повторных GET‑ов. Попутно поведаю о наших граблях и поделюсь советами по миграции.

habr.com/ru/companies/kts/arti

#mobx #React #React_Query #Nextjs #Frontend #Управление_состоянием #Оптимизация_производительности #ssr

Show Original PostReport

Как я устал вручную писать сервис-воркеры и сделал next-pwa-pack, чтобы больше не страдать

Сколько лет уже кто-то говорит: «А можно, чтобы оно работало без интернета и ставилось на домашний экран?» И каждый раз после этой фразы начинается медленный спуск в персональный ад — ты лезешь в документацию по PWA, где всё разваливается на ровном месте, service worker живёт своей жизнью, кеш то работает, то ломается, App Router рушит весь твой кастомный пайплайн, а пользователи сидят на старых версиях, потому что вручную обновлять им, конечно, влом. Словом, если ты когда-то пробовал прикрутить оффлайн-режим к Next.js-проекту, ты наверняка вспоминал всех, кто придумал этот стек. Я — точно. Поэтому, как человек, у которого было слишком много кофе и слишком мало терпения, я сделал единственное разумное: написал свою обёртку. Так и появился next-pwa-pack — дроп-ин пакет, который превращает любой Next.js-проект в полноценное PWA, буквально одной строкой. Да, даже с App Router. Просто заворачиваешь свой layout в PWAProvider, и всё: приложение можно установить, оно кэширует страницы, работает оффлайн, синхронизирует вкладки и даже показывает отладочную панель, чтобы не гадать, сработало ли что-нибудь. Воткнул — и живи дальше. А то: Сервис-воркер? Напиши вручную. Кешировать HTML? Сам придумай как. Синхронизация вкладок? Ну это уже магия, удачи. Обновление кеша после деплоя? Ну ты ж senior, сам справишься. 🤡 И ты сидишь, как идиот, с 300 вкладками про Workbox, cache-first , network-only , костылями из Stack Overflow 2019 года, и потеешь. Если раньше каждый запрос «сделай оффлайн» вызывал у меня флэшбэк на тему next-pwa, неподдерживаемых версий, кривого кеша и плясок с бубном вокруг обновлений — теперь всё это ушло. Я хотел простой setup, который просто работает: предзагрузка, нормальные TTL, понятное обновление и синхронизация. Без фокусов, без багов, без “подожди, сейчас DevTools открою”. Погнали дальше!

habr.com/ru/articles/935024/

#nextjs #progressive_web_apps #app_router #serviceworker #reactjs #react

Show Original PostReport

Great UX shouldn't require a complete rewrite. Dave Mosher compares a React SPA vs HTMX for the same app.

HTMX delivers on what matters:
- Ship faster (one deployment vs two)
- Onboard developers faster (HTML + HTTP, done)
- Serve users better (works without JS)
- Keep it together (1 script vs dependency chaos)

Not about abandoning React—it's about choosing complexity only when it adds user value.

Compare the approaches:
link.testdouble.com/3a0881

Show Original PostReport

Принцип единой ответственности SOLID в React

Всем привет! Меня зовут Дмитрий , и я руководитель фронтенд-разработки в компании Интелси. Сегодня хочу рассказать о принципе единственной ответственности (Single Responsibility Principle) — первом из пяти принципов SOLID, сформулированных Робертом Мартином в его книге "Agile Software Development: Principles, Patterns, and Practices" . Суть этого принципа звучит так: «Класс должен иметь только одну причину для изменения» ( A class should have only one reason to change ).

habr.com/ru/articles/934928/

#react #reactjs #design_patterns #solid #typescript #javascript

Show Original PostReport

[Перевод] Dependency Injection в JavaScript: зачем он вам нужен

Как избавиться от проп-дриллинга, упростить тестирование и навести порядок в зависимостях React/JS‑приложения? В статье — зачем вообще нужен dependency injection в JavaScript, почему он редко используется и как это меняет @wroud/di . С кодом, примерами и без тяжёлой рефлексии.

habr.com/ru/articles/934876/

#di #dependency_injection #react #typescript #javascript

Show Original PostReport