TypeScript *

Каждый фронтендер знает эту боль: пишешь запрос через fetch - и автоматически добавляешь try/catch. Где-то ловишь TypeError, где-то 500-й статус, где-то подвисший запрос с AbortController. В итоге половина кода в проекте - это обработка ошибок, а не бизнес-логика.

Я прожил с этим годами. Чем больше становился проект, тем больше росла копипаста: таймауты, ретраи, проверки на res.ok, костыли для разных браузеров. Одно и то же, снова и снова.

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

Так появилась библиотека @asouei/safe-fetch. Маленькая (3kb), без зависимостей, но с тем, чего нет у самого fetch: общий таймаут, умные ретраи, нормализованные ошибки и поддержка Retry-After.

🌟 Библиотека добавлена в Awesome TypeScript — один из крупнейших мировых списков лучших TypeScript-проектов

Сегодня мы разработаем с 0 собственный геймтон и запустим соревнования среди хабравчан и всех желающих just for fun. А также дадим возможность запустить свой геймтон локально по своим правилам Под катом вас ждет разработка геймтона на стеке nodejs + prisma + vuejs + fastify. А также пример разработки фулстек приложения с различными тонкостями построения API.

Рассуждаю о проблеме регулярного создания файлов и о том, как поддержать архитектуру и автоматизировать рутину.

Написал утилиту на Go для генерации структур файлов по шаблонам, которая, думаю, будет полезна многим.

Мы все видели и использовали поля типа boolean в базах данных как часть структуры данных.
На первый взгляд это удобно: два значения — «да» или «нет», просто и понятно.

Например, у пользователя может быть флаг is_active, который показывает, включён аккаунт или нет, или поле is_deleted, которое используется как мягкое удаление. Такие поля встречаются повсюду.

Но на практике хранение boolean в базе данных как элемента модели часто приводит к проблемам.

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

Записки одного QA. Вспомогательная часть автотестов: советы и практики (Playwright + Typescript)

В статье рассматриваются подходы к организации вспомогательной части для автотестов на Playwright: структура проекта, Page Object, helpers, constants и шаги. Приведены практические примеры того, какие решения помогают поддерживать автотесты читаемыми и масштабируемыми, а каких стоит избегать. Материал будет полезен QA-инженерам и разработчикам, начинающим работать с Playwright.

Паттерны типизации в TypeScript напрямую влияют на технический долг — накопление неоптимального кода (костылей), которое замедляет разработку, увеличивает риски ошибок и повышает затраты на поддержку. Осознанный выбор паттерна минимизирует эти проблемы, обеспечивая предсказуемость и масштабируемость кода, что ускоряет адаптацию новых разработчиков и сокращает время на отладку

Привет! Меня зовут Никита, я старший фронтенд-инженер в Ozon Tech и я разрабатываю кабинет рекламодателя. Однажды мы попытались обновить версию Node.js и нашли баг, который затянулся на два года и вовлёк в себя команды Jest, Node.js и V8.

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

Real-time системы и протоколы — тема, которая меня давно интересовала. В рамках эксперимента я решил попробовать свои силы:

Работа с WebSocket для двунаправленной связи в реальном времени

Масштабирование соединений и оптимизация производительности

Разработка собственного протокола/формата передачи данных для надёжности и скорости

Салют, Хабр! 

Меня зовут Паша, я вхожу в группу обеспечения производительности интерфейсов; неформально это команда «Скорость» SberDevices. Мы с коллегами отвечаем за то, чтобы сайты sberdevices.ru, giga.chat, developers.sber.ru и другие быстро работали и красиво выглядели. Если пользователю неудобно использовать сайт, он быстро с него уйдёт (и не станет ничего читать и покупать).

Как только потребовалась оценка качества веб-страниц, появилось и множество подходов к ним. Но в итоге индустриальным стандартом стали методы, предложенные Google и реализованные на уровне браузерных API. Чтобы понять, как сайты стоит оптимизировать и что влияет на их быстродействие, Google оперирует тремя метриками — Core Web Vitals. Две из них действуют с мая 2020 года, а третьей не исполнилось и года. Сегодня расскажу, как разработчик может оценить их и улучшить без консультации команды скорости (если она есть). А ещё благодаря оптимизации метрик Core Web Vitals сайт ранжируется в поисковиках выше. Поехали!

Автоматизация тестирования — это не только про стабильность и скорость, но и про понимание причин падений. В этой статье практические приёмы, которые помогут сделать Playwright-тесты не просто «зелёными», а по-настоящему надёжными и понятными. Разберём, как:

— подключить минимальный набор инструментов для диагностики;
— улучшить читаемость отчётов;
— использовать кастомные ассерты для более информативных ошибок;
— выбрать подходящие репортеры под разные роли в команде;
— и даже применить AI для автоматического анализа падений.

Материал будет полезен QA-инженерам и автоматизаторам, работающим с Playwright, а также разработчикам, тимлидам и менеджерам, которым важно получать прозрачную картину состояния автотестов. 

Pet-проект которой далеко зашел, но так и не дошел до цели!

Ретроспектива моей первой попытки создать полезный и востребованный пользователям продукт, ошибки, которые мы допустили, и сделанные выводы.

Одним из ключевых преимуществ этого пользовательского хука является его простота. Вы можете использовать его для хранения данных любого типа, таких как строки, числа или даже сложные объекты, всего с помощью нескольких строк кода. Кроме того, useStorage выполняет сериализацию и десериализацию данных за вас, поэтому вам не нужно беспокоиться о преобразовании значений в JSON и из него.

Басня о коде и мёде

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

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

И вот однажды мудрый старый архитектор, известный как «Пчеловод», собрал молодых строителей. «Вы стремитесь строить «Великие вещи», — сказала она, и ее голос был теплым, как летний мед. «Но вы строите из камня и железа, когда вы должны строить из самой жизни. Посмотрите на пчел. Их ульи — шедевры дизайна, построенные на века на протяжении поколений. Давайте узнаем их секреты».

Так начинается наша история. История не только о коде, но и о вечных закономерностях природы, которые могут помочь нам создавать создавать красивые программы. Мы отправимся в самое сердце Шестиугольного Улья, откроем его секретный генетический код и узнаем, как выращивать собственных «рабочих пчел», которые будут служить нашему цифровому королевству добросовестно.

Этот вопрос интересовал меня настолько давно, что за прошедшие годы даже стал как-то про него забывать. И не то, чтобы меня это прям как-то сильно интересовало, но всё же лучше понимать назначение было бы приятно.

И, ведь, ну в самом деле, подумаешь, ну может разработчику хочеться вернуть не эземпляр, не instance, а какой-нибудь другой объект, и зачем-то при этом ему нужен именно вызов конструктора. Ну, допустим, он хочет чтобы new.target был заполнен и т.п., ну, мало ли какие варианты зачем-то иметь возможность в противном случае вернуть объект. Или может он хочет асинхронных конструкторов и вернуть new Promise, где уже в resolve передать this как вариант для создания await new MyConstructor. Или может быть хочет вернуть Proxy над this для отслеживания операций с этим экземпляром. В общем есть всякие разные причины когда гуманно было бы иметь этот "сахар", но всё же, может быть есть что-то, что иначе никак не сделать? И, самое важное, что эта функциональность былв всегда, с самой первой версии же. Понятно, что может быть про это вообще не думали, просто делали "как привычно". И, да, функции-конструкторы, в отличие от class-овможно вызвать без new и в те времена никаких классов в JavaScript не было конечно, и return объективно был нужен, но может быть есть какие-нибудь варианты когда и с new имеется глубокий практический смысл уже и тогда существовали, то есть может быть назначение операции возврата иного значения конкретно у конструкторов вполне себе приемлемое. И, да, конечно, конструкторы не возвращают примитивы, но может быть и для объектов есть какое-то применение тоже находилось бы, ну, вдруг, внезапно, может быть ...

Привет! Хочу поделиться с тобой опытом перехода от Feature-Sliced Design к Clean Architecture во фронтенде. Почему я считаю Clean Architecture более подходящей для сложных приложений, и как она решает проблемы, с которыми ты точно сталкивался.

Если ты используешь FSD и тебе уже больно или до сих пор пишешь всю логику в компонентах React — эта статья точно для тебя.

Представьте, что вы делаете сайт-визитку или интернет-магазин на Angular. У вас есть главная страница, страница «О нас» и страница с товарами. Логично, что при клике на ссылки пользователь должен переходить между этими страницами

В классических сайтах это решается просто: при каждом клике браузер запрашивает у сервера новую HTML-страницу. Но в современных SPA (Single Page Applications) всё работает иначе — приложение загружается один раз, а дальше мы просто подменяем содержимое внутри него

Именно за это отвечает Angular Router.

Если вы начинающий специалист в автоматизации тестирования, или автотестировщик с опытом, готовый обсуждать и улучшать стратегии тестирования, то с радостью представляю вам первый пост в серии, посвященный разборам подходов к тестированию ПО. Здесь я разбираю свой взгляд на способы решения реальных задач по тестированию, используя Playwright + TypeScript.

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

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