Этот настраиваемый хук особенно полезен в сценариях, где вам нужно обрабатывать вводимые пользователем данные, такие как строки поиска или поля формы, и где вы хотите отложить выполнение действия до тех пор, пока пользователь не закончит вводить текст или взаимодействовать с пользователем. Это также полезно для оптимизации сетевых запросов, гарантируя, что запросы будут отправляться только после того, как пользователь перестанет печатать или выбирать параметры.
Сегодня хотелось бы поговорить с вами о такой теме как Легаси.
Давайте дадим определение, что такое легаси.
Легаси - это тот код, который писали до нас и который пришел нам от других.
Легаси - это не всегда «плохой» код, а просто код, который устарел по технологии, по структуре или по пониманию.
Почти любой проект со временем превращается в легаси, если его не обновлять.
На своем опыте разработки я могу классифицировать легаси на три категории. Опять же я не претендую на абсолютную объективность. Это только моя классификация, на основе того, с чем лично я столкнулся.
1) Технологии, которые еще работают, но есть обновленные версии пакетов, фреймворков и инструментов. Просто в данный момент код работает на предыдущих версиях. Самый очевидный пример проект написанный на Vue2, когда есть Vue3. Переписать его на новую версию с одной стороны не так уж и трудно. А с другой это связано с подводными камнями. Если мы переходим с Option Api на Composition Api то простой заменой одного кода на другой не обойтись. Некоторые вещи работают иначе. И придется отлавливать локальные проблемы. Если проект небольшой и сложной логики там мало, то это делается быстро. Если же она есть то проблемы точно будут. Кроме того не стоит забывать, что часть пакетов и библиотек, которые работают с Vue2, не работают с Vue3. Следовательно придется искать аналоги. В целом проблемы и способ перехода здесь прозрачны и это самый легкий вариант.
2) Нельзя переписать, но можно работать. Это проекты написанные на старых технологиях, как jquery и других. Они не могут быть быстро и легко переведены на современные инструменты. Так как для этого придется все писать заново. Однако код, который был написан, достаточно понятен и его не так сложно поддерживать. А переезд на новый вариант это параллельная разработка нового. Здесь тоже все понятно. Мы не имеем возможности бесшовно перейти на новые версии, потому что их просто может не быть. Поэтому приложение пишется с нуля на новом стеке.
Мы из Березников — города, о котором мало кто слышал за пределами Пермского края. Здесь нет венчурных фондов, акселераторов или готовых бизнес‑ангелов. Каждый шаг — это борьба за возможность расти и доказывать, что мы способны конкурировать с компаниями из Кремниевой долины. Наша цель проста и дерзка: заработать $1 000 000 и показать, что любой проект может родиться даже в российской глубинке.
СТОП! НЕТ! Березники нормальный город, пару фоток сюда!
Одним из ключевых преимуществ этого пользовательского хука является его простота. Вы можете использовать его для хранения данных любого типа, таких как строки, числа или даже сложные объекты, всего с помощью нескольких строк кода. Кроме того, useStorage выполняет сериализацию и десериализацию данных за вас, поэтому вам не нужно беспокоиться о преобразовании значений в JSON и из него.
Привет! Хочу поделиться с тобой опытом перехода от Feature-Sliced Design к Clean Architecture во фронтенде. Почему я считаю Clean Architecture более подходящей для сложных приложений, и как она решает проблемы, с которыми ты точно сталкивался.
Если ты используешь FSD и тебе уже больно или до сих пор пишешь всю логику в компонентах React — эта статья точно для тебя.
Если у вас есть два приложения на React + Vite — хост и микрофронт (remote) — и при общем старте через одну команду всё магически ок, а при раздельном запуске хост падает с 404 на remoteEntry.js, вы не одиноки. Разбираемся, почему так, и показываю рабочие рецепты.
Зачастую разработчики сталкиваются с двумя крайностями: либо пишут огромное количество бесполезных тестов, которые почти ничего не проверяют, либо вообще отказываются от тестирования, боясь сложностей. Здесь мы рассмотрим простой и эффективный подход к созданию правильных юнит-тестов в проектах на React.js.
20 частых антипаттернов в React и как их исправить. Разбираем ошибки с хуками, состоянием, мемоизацией и структурой компонентов: когда не нужен useEffect, зачем useCallback, почему не хранить производные значения в state. Минимальные примеры, чёткие принципы, практичные альтернативы.
В этой статье я детально опишу свой опыт создания «большого» (по меркам приложений которые можно получить из ИИ) с помощью ИИ.
Стабильность, упомянутая в заголовке выражается, в том что создаваемые мною Промты пригодны для широкого круга нейронных сетей в любом состоянии их интеллектуальности и адаптивности, которые в рамках отдельных моделей чаще падают, чем растут.
Основа моей идеи была в том, чтобы сделать приложение, которое будет состоять из
useScript можно использовать в различных сценариях. Например, вы можете загружать внешние библиотеки, такие как jQuery, что позволяет использовать его мощные функциональные возможности, не увеличивая объем вашего пакета. Кроме того, вы можете загрузить аналитические скрипты, виджеты социальных сетей или любые другие скрипты, необходимые для динамического поведения вашего приложения.
Кейс из жизни: мини-приложения, анимированные обложки, внешние команды — и одна на вид «валидная» анимация, которая кладет все приложение. Рассказываем, как мы научились воспринимать Lottie-файлы не как медиа, а как исполняемый код — и почему это улучшило стабильность всей системы.
Привет, Хабр. Давайте о больном. У вас 5+ лет опыта, вы уверенно решаете сложные задачи, менторите джунов и знаете свой стек досконально. Вы чувствуете себя сеньором. Но раз за разом на собеседованиях вам либо предлагают позицию Middle+, либо дают оффер с зарплатой, которая явно не дотягивает до сеньорской.
В чем проблема?
Проблема в том, что вы пытаетесь измерить свой уровень одномерной линейкой «знания технологий». А в голове у адекватного нанимающего менеджера — многомерная система координат.
Как бывший рекрутер, я видел десятки таких «матриц компетенций» в разных IT‑компаниях. И сейчас я вскрою этот черный ящик и покажу, по каким на самом деле осям вас оценивают.
Многие начинающие разработчики учат то, что никогда не пригодится на первой работе. В этой статье — 7 навыков, которые junior-фронтендеру можно смело отложить: от юнит-тестов до глубокого погружения в паттерны проектирования.
Разберём, почему эти знания избыточны на старте карьеры, как их отсутствие влияет на поиск работы и что действительно стоит учить в первую очередь.
Статья основана на анализе реальных вакансий и требований к начинающим специалистам. Подойдёт тем, кто хочет оптимизировать подготовку и быстрее устроиться на первую работу.
Всем привет! Меня зовут Тим и я недавно завершил проект под названием ether-pos цель которого — объяснить, как на самом деле работает система Proof of Stake (PoS, Доказательство доли владения) Ethereum. Если вы еще не видели ее, посмотрите здесь: ether-pos.
Позвольте мне немного рассказать о том, почему я его создал и чему я научился в процессе.
Привет. Я Дима Рагозин, фронтенд-разработчик в KTS. Эту статью я хочу начать с предыстории.
Полтора года назад на проекте для одного крупного клиента мы получили задачу — ускорить главную страницу. К тому моменту в кодовой базе уже жили два отдельных фронтенд-приложения под две разные платформы — CSR-версия (Client Side Rendering) и SSR‑версия (Server Side Rendering), — а MobX‑сторы все время жизни проекта разрастались вместе с функциональностью.
Каждый новый экран приносил еще один класс (а то и несколько), еще кучу связей, и в какой‑то момент мы стали замечать снижение воспринимаемой скорости приложения, избыточные HTTP‑запросы, сложности с поддерживаемостью и другие проблемы, которые становились критичнее по мере роста проекта. В статье я расскажу о том, как мы шаг за шагом перевели такие сторы на React Query, сократили код вокруг запросов на ≈50 % и практически избавились от повторных GET‑ов. Попутно поведаю о наших граблях и поделюсь советами по миграции.
Сколько лет уже кто-то говорит: «А можно, чтобы оно работало без интернета и ставилось на домашний экран?» И каждый раз после этой фразы начинается медленный спуск в персональный ад — ты лезешь в документацию по 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 открою”.
Всем привет! Меня зовут Дмитрий, и я руководитель фронтенд-разработки в компании Интелси.
Сегодня хочу рассказать о принципе единственной ответственности (Single Responsibility Principle) — первом из пяти принципов SOLID, сформулированных Робертом Мартином в его книге "Agile Software Development: Principles, Patterns, and Practices". Суть этого принципа звучит так: «Класс должен иметь только одну причину для изменения» (A class should have only one reason to change).
Как избавиться от проп-дриллинга, упростить тестирование и навести порядок в зависимостях React/JS‑приложения? В статье — зачем вообще нужен dependency injection в JavaScript, почему он редко используется и как это меняет @wroud/di. С кодом, примерами и без тяжёлой рефлексии.
Одним из ключевых преимуществ этого пользовательского хука является его простота и возможность повторного использования. Всего с помощью нескольких строк кода вы можете без особых усилий реализовать адаптивное поведение во всем вашем приложении. Независимо от того, требуется ли вам условный рендеринг компонентов, применение определенных стилей или запуск различных функций в зависимости от размера экрана, useMediaQuery поможет вам в этом.
