Зачастую обычные веб-приложения не покрывают E2E тестами, однако, когда разговор заходит об административных панелях, формах биллинга и разнообразных конструкторах, то данная потребность быстро возникает.
В этой статье мы рассмотрим, как правильно организовать селекторы для тестирования веб-приложений.
Я починил плохой перевод силами ИИ, написав расширение при помощи ИИ. И я удивлён, что до сих пор такого не сделали.
Этот документ — не просто список, а выжимка боли, шишек и неожиданных открытий, с которыми сталкивается почти каждый фронтендер. Неважно, Vue ты выбрал или React, если твое приложение должно работать в браузере на айфоне пятилетней давности — добро пожаловать в клуб. Здесь будет всё: от странностей с Safari до неожиданных проблем с синтетическими событиями.
Нюансы мобильных браузеров и PWA
iOS Safari не поддерживает Notification API без установки PWA
Проблема: На iOS ты не можешь просто вызвать new Notification(...) — API будет недоступно, пока пользователь не установит сайт как PWA на домашний экран. Так же, в Safari просто не будет доступен класс Notification, браузер его просто не имплиментирует на этапе браузерного окна.
Решение:
- Чтобы проверить можно ли использовать уведомления можно написать следующую проверку:
typeof window !== 'undefined' && 'Notification' in window;
🔗 [MDN — Notification API](https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API)
🔗 [WebKit — Push Notifications](https://webkit.org/blog/12945/meet-web-push-on-ios/)
Пару лет назад единственной настольной игрой, в которую я играл онлайн с друзьями, была «Монополия». Со временем она начала надоедать, и мне захотелось чего‑то нового. Моим открытием стала Machi Koro — экономическая карточная игра, где победа зависит не столько от случайности, сколько от выбранной стратегии, что выгодно отличает её от «Монополии».
На тот момент я не нашёл достойных онлайн‑аналогов Machi Koro, что и подтолкнуло меня к созданию собственной реализации. В этой статье я подробно расскажу о технической стороне проекта: от составления требований до выбора стека технологий.
Устали от бесконечных споров о CSS-методологиях? В этой статье я рассказываю, как объединил БЭМ и Tailwind в мощный гибридный подход, который спас мой проект и нервную систему. Узнайте, как избавиться от мучительного нейминга, решить проблему с отступами и ускорить разработку в два раза.
Никакого догматизма — только практический опыт и реальные примеры использования лучших сторон обоих подходов.
Привет, Хабр!
Сегодня рассмотрим, как тестировать React‑хуки с помощью @testing-library/react-hooks.
Если вы занимаетесь фронтенд-разработкой, то наверняка работали со Storybook — удобной витриной компонентов, на которой красиво лежат компоненты и примеры их использования. Его любят за интерактивную документацию, возможность визуального контроля и изолированной разработки. Но замечали ли вы, сколько действий приходится делать, чтобы взять компонент из Storybook и вставить его в реальный проект?
Наверняка вы сталкивались с ситуацией: нашли компонент в Storybook, затем переключились обратно в IDE, скопировали код, вставили, адаптировали, проверили, и повторили снова. Кажется, многовато действий для простой вставки компонента, правда? Постоянные переключения между браузером и IDE, ручной копипаст и отсутствие связи с уже написанным кодом делают этот процесс неудобным и медленным.
Storybook Studio: всё в одном месте...
Тут я расскажу о том, как я впервые с нуля поднимал проект на React, используя связку FSD, TanStack Router, TanStack Query и Effector — и как мы всё это далее подружили подружили или нет 🙂.
Сразу оговорюсь:
Проектом занимается команда, но архитектурный старт, выбор технологий и базовая структура — легли на меня. Это был мой первый опыт в такой роли: отвечать не просто за компоненты или страницы, а за фундамент проекта.
А так же, это моя первая статья. Не претендую на истину в последней инстанции, но надеюсь, кому‑то мой опыт будет полезен и палками бить сильно не будете.
KafkaRail гудел на фоне.
Паб The Broken Tag, где начиналось утро героев, только просыпался — запах старого эля, крошки лог‑файлов, и бильярдный стол под тусклым светом прожектора. Через узел маршрута /corp/news метропоезд пронёсся, как push‑уведомление на рассвете. День в Киберляндии начинался.
JSON откинул капюшон куртки BitStone Protocol с QR‑патчем на рукаве, кивнул Mr. Parseley и заказал, как обычно, Schema Fresca. Он прошёл к бильярдному столу английского пула, стоявшему под старым плакатом «Keep Calm and Close Tags», где RAMmy спорил с TryCatch о синтаксисе ударов.
Привет! На связи Михаил Шпаков, руководитель разработки в Timeweb Cloud.
Мы создаём облако, в котором удобно запускать и управлять проектами: от простых ВДС до масштабных решений с Kubernetes и десятками интеграций. Мы много думаем о том, как сделать инфраструктуру не только стабильной, но и понятной.
Когда вы работаете в облаке, всё выглядит структурировано: список серверов, IP-адресов, баз данных, кластеров. Но в какой-то момент возникает вопрос: а как всё это связано между собой?
Что подключено к балансировщику? В какой сети находятся серверы? Почему не пингуется база? Ответы есть, но они спрятаны в разных разделах интерфейса или требуют обращения в поддержку.
Мы в Timeweb Cloud решили это изменить. Инфраструктура — это карта, а не таблица. Её нужно рисовать, а не запоминать.
Мы сделали визуальную карту, на которой можно не просто увидеть ресурсы, но и настроить их расположение как в реальной жизни: сгруппировать, пояснить, добавить связи и комментарии. Это не просто картинка — это инструмент, который помогает понимать, как всё устроено, и быстрее находить проблемы.
Это как перейти от чтения логов к полноценной карте: наглядно, понятно, живо. Визуализация стала тем самым недостающим элементом, который помогает по-настоящему понять, как устроена инфраструктура.
Каждый разработчик рано или поздно сталкивается с вопросом: как организовать проект так, чтобы он не превратился в хаос? Или как исправить проект, в котором уже царит хаос?
Начинается всё одинаково: мы делаем простое MVP или проект с ограниченным функционалом, не заморачиваемся по поводу архитектуры и организации кода, ведь проект небольшой и несложный, а сделать его нужно уже здесь и сейчас. Но время идёт, и у бизнеса появляются всё новые требования. Какие‑то изначальные идеи полностью отменяются или меняются до неузнаваемости, разрастается команда, дизайн меняется несколько раз, появляется необходимость покрыть проект тестами, а иногда и необходимость вообще сменить стек технологий. И вот вы уже работаете над кодом, в котором становится всё сложнее вносить изменения в существующий функционал. Всё держится на костылях, становится трудно ориентироваться в куче файлов, и кажется, что всё устроено как‑то не так, как должно быть.
В этот момент мы начинаем задаваться вопросом: «а как нужно писать и организовывать код на самом деле?». В поисках ответа мы читаем статьи, смотрим обучающие видео, доклады и неизбежно натыкаемся на Feature‑Sliced Design (FSD).
В 2022-м мы окончательно задолбались.
Каждый новый проект все по кругу: таблички, формы, фильтры, CRUD. Всё снова, как в Groundhog Day. Копипастить старое было больно, собирать с нуля – ещё хуже. И главное, ощущение абсурда: 2022 год, а мы продолжаем лепить админки вручную, будто на дворе 2015.
Окей, логичный шаг – найти готовое решение.
Мы правда пытались не изобретать велосипед
Первым делом пошли смотреть на CMS. Попробовали Strapi – мощный зверь, но если вам просто нужно бэку выдать пару CRUD’ов, то тянуть за собой целую экосистему с философией и особым образом жизни, это как стрелять из базуки по воробьям.
Дальше, дизайн-системы вроде Salesforce Lightning, Fluent UI и Fusion Design. Компоненты красивые, но по факту это просто UI-кирпичики. Всю бизнес-логику, связи между сущностями, обработку данных всё равно пишешь сам. Хотели сэкономить время, а получили “ты теперь ещё и архитектурой займись”.
React-Admin показался перспективным. Но мы быстро поняли, что он хочет, чтобы ты делал вещи его способом. А мы хотели делать их по-своему. Онбординг тяжёлый, кастомизация сложная, UI на любителя. Как часто бывает: сначала кажется, что ты взял инструмент, а потом он берёт тебя.
Мы поняли: компромиссы – это медленно
С хорошей отказоустойчивостью интерфейс остаётся стабильным и понятным, пользователь получает предсказуемый и комфортный опыт, а сбои отдельных компонентов не приводят к сбоям всей системы.
Хорошая отказоустойчивость начинается с мышления.
Важно не просто латать ошибки по мере их появления, а комплексно подходить к решению — формировать правильное понимание, разрабатывать устойчивые подходы и строить систему, способную адекватно реагировать на возможные сбои.
Принципы описанные ниже в большинстве своем универсальные и подойдут к большому количеству сфер, даже вне области информационных технологий. Но моя основная опора будет на сферу веб-разработки
Ни для кого ни секрет, что разработка и IT‑решения в 2025-м году — это гонка за скоростью: от выяснения бизнес‑требований до финальной версии продукта. Чем быстрее пишется код, тем раньше ваш продукт попадает к пользователям. Разумеется, выбор технологий существенно сказывается на скорости разработки.
В этой статье я бы хотел затронуть современные инструменты Frontend‑разработчика, которые уже начали вытеснять классику, а также попутно сокращают объём кода, избавляя разработчика от рутины.
(История экономиста с неоконченной Computer Science, который нашёл себя в автоматизации логистики)
Хабр, привет! Меня зовут Александр и я обычный менеджер по работе с ключевыми клиентами в логистической компании, которая занимается в основном контейнерными перевозками из Китая в РФ (рекламы не будет).
Кратко обо мне: всегда интересовали компьютеры и программирование, но жизнь складывалась немного иначе чем хотелось. В 14 лет всей семьей уехали жить в Италию, где я закончил экономический, а также потом поехал учиться на 3 года на Computer Science в г. Пиза (да, это там, где башня падает и все никак не упадет). К сожалению, в связи с бумом ковида было принято решение возвращаться домой, да и долги по учебе не добавляли оптимизма в связи с чем, спустя год изоляции (возможно многие знают как жестили в Европе с ограничениями) я отправился на родину в Москву, где после непонятного года я смог более‑менее укрепиться в сфере международных перевозок.
Несмотря на все пертурбации, я по‑прежнему искал любыми способами оставлять в жизни место и время для программирования, Хабра и поиска интересных решений и попыток самому что‑то сделать годное. В моем небольшом арсенале есть основы С с универа и Java/Kotlin/JS, которые я использую везде куда дотягиваются руки.
История началась с того, что я не раз уже руками писал небольшие скрипты или же десктопные мини окошки, которые бы помогали мне в работе, но со временем я понял, что мне банально не хватает времени и инженерных навыков чтобы быстро создавать инструмент под нужную мне задачу (рынок логистики очень быстро меняется).
Привет! Мы Дима и Илья, работаем в команде ТМА-разработки Doubletapp и расскажем, как создать Telegram Mini App на стеке React + Python.
Telegram Mini Apps — это мощный инструмент, который позволяет создавать интерактивные веб-приложения, работающие прямо внутри мессенджера. Они идеально подходят для игр, маркетплейсов, сервисов бронирования и многого другого.
В этом туториале мы разберем процесс создания Mini App:
• настроим проект
• создадим фронтенд на React с поддержкой Telegram SDK
• реализуем бэкенд на Python (Django)
• свяжем все компоненты и развернем приложение.
Несомненно, появление концепции лайка открыло новую страницу в механизме feedback. Не только для крупных компаний, но и для мелких девчушек, которые гоняются за лайками от своих сверстников. Однако, в какой‑то момент времени, лайки стали тормозить развитие механизмов получения того самого feedback. Зачем что‑то выдумывать новое, если уже есть лайк, понятный даже макаке‑резус и регулярно повсеместно используемый? Концепция лайков противоречит количественной социологии? Да ну ее на фиг, эту социологию! Одним лайком сложно получить качественный feedback? Зато лайк это уже традиция — так еще наши прадеды делали, деды, отцы делали, и мы делать будем, и наши дети и правнуки, ну Вы поняли. В данной статье не только делается попытка поиска следующего за лайком механизма feedback. Но и приводится вместе с исходным кодом действующий компонент на React TypeScript. Если кому интересна тема поиска новых механизмов feedback, добро пожаловать под кат!
Важность надежной обработки запросов в оффлайн-режиме невозможно переоценить, особенно для приложений, которые должны функционировать и в отсутствии интернет-соединения. Workbox - это мощный инструмент для управления Service Worker в браузерах, он как раз призван решать подобную задачу при помощи соответствующего плагина, но поддержка Background Sync API не универсальна. В этой статье я покажу, как расширить Workbox, чтобы Background Sync корректно работал даже на платформе iOS/Safari.
Работая над продуктом для «внешнего» пользователя, разработчик интерфейсов может столкнуться с необходимостью использовать серверный рендеринг. Поисковые системы по прежнему остаются значительным источником трафика почти для любого сайта, контент на котором не будет проиндексирован, если сервер его не отдаст. Кроме того, «приготовленный» определенным образом, серверный рендеринг может положительно сказаться на всех основных метриках производительности проекта, существенно ускорив загрузку страниц. В то же время, эта технология накладывает определенные ограничения, с которыми необходимо считаться и повышает требования к экспертизе разработчика. В статье будут предметно разобраны подводные камни, с которыми можно столкнуться при разработке платформы, использующей отрисовку HTML в Node.js окружении, и даны практические рекомендации, как их избежать.
На конференции React прошлым летом команда объявила, что Remix «уходит в спячку».
К тому моменту Remix v2 стал настолько тонкой обёрткой над React Router, что между проектами возникло искусственное разделение. Чтобы упростить архитектуру фреймворка, команда перенесла код сборщика и серверного рантайма из Remix непосредственно в React Router v7, объединив всё лучшее из фреймворка в так называемый “framework mode” для роутера. Также было объявлено о планах добавить ограниченную поддержку React Server Components (RSC) в React Router.
Эта работа была завершена: версия 7 была выпущена в ноябре прошлого года, а в конце мая была представлена предварительная поддержка RSC. Теперь разработчики, использовавшие Remix v1, v2 или более ранние версии React Router, могут рассчитывать на стабильную платформу с долгосрочной поддержкой.
Теперь же, пришло время заняться Remix!
