TypeScript *

Введение в любой фреймвок начинается с написания одного простого компонента. Чаще всего этим компонентом будет "счетчик нажатий". Это своеобразный "hello world" в мире фронтенд разработки. Именно поэтому я и возьму его за основу данного материала.

Несколько месяцев назад я написал статью — «Observable — удобный state‑manager», что было скорее заметкой, и за что мне здорово досталось в комментариях! Уважаемым комментаторам — спасибо, я постарался учесть все замечания.

Сегодня представляю вам kr‑observable 2.0 — библиотеку для реактивного программирования на JavaScript. И удобный state-manager тоже.

Что такое TypeScript? Официальная документация отвечает так: “TypeScript — это JavaScript с синтаксисом типов”. Однако некоторые считают TypeScript своеобразным слиянием двух языков: языка для манипулирования значениями JavaScript и языка для манипулирования типами.

Cистема типов TypeScript Тьюринг-полная. Это означает, говоря по-простому, что система может решить любую вычислительную задачу при наличии некоторого представления входных и выходных данных.

Можно ли использовать это знание на практике? Как избежать крайностей от примитивного аннотирования типов до избыточного усложнения?

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

Вы уже встречались с этими "веселыми" историями, когда разработчик заканчивает работу над задачей, она проходит тестирование, отправляется в прод, а там встречается неожиданным отказом какого-нибудь мелкого метода api и укладывает всё приложение так, что пользователи наблюдают только белый экран?

Я в своё время познакомился с ними чересчур близко... И, честно сказать, потоки RxJs прекрасные учителя - тебе не захочется снова повторять их уроки. Чему же они нас учат? В первую очередь тому, что не стоит доверять внешним источникам; вы не контролируете ни соединение с сервером, ни api-сервис, а значит не имеете никаких оснований слепо доверять им и ожидать безотказной работы.

Полиморфизм — сколько в этом слове красивого и даже таинственного. Происходит от греческого πολύμορφος что означает — многообразный.  В программировании это понятие встречается часто и  обыденно для понимания большинством программистов. Но так ли это на самом деле? 

В статье — о том, как мы решили отказаться от PropTypes в пользу TypeScript для автоматического извлечения типов пропсов React-компонентов. 

Наши разработчики давно просили эту возможность, справедливо возмущаясь: «Зачем описывать типы дважды — в TypeScript и PropTypes?». Тем более, что аналогичный механизм уже работал в Storybook.

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

На одном из проектов мне нужно было реализовать Telegram-бота с использованием Web App. Я выбрал стек: Vite + React + Zustand + TypeScript. До этого я в основном работал с Webpack, и столкнулся с вопросом — как удобно организовать алиасы. В Vite есть resolve.alias, и это удобно. Но дополнительно нужно прописывать пути в tsconfig.json, чтобы IDE понимала, что происходит. А ещё это не работает с HTML-импортами.

💡 Здесь важно: HTML теперь может импортировать модули напрямую, и если бы алиасы работали и там — можно было бы писать одни и те же пути и в скриптах, и в коде, и в конфиге.

Как собирать чистые и переиспользуемые DTO в TypeScript и NestJS с помощью миксинов? Модульность, валидация и никакого дублирования — всё в одном месте.

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

Когда мы решили вывести на прод Telegram‑мини‑приложение для «капельных» (drip) TON‑платежей, довольно быстро стало ясно: обычный CRUD‑фронт тут не выживет. Сразу накрыла волна специфичных задач — от гранулярного онбординга в Web‑App до борьбы с ограничениями API‑ключей и тонкостей работы с TON SDK во встроенном браузере Telegram. Каждый шаг требовал не только кода, но и аккуратного выбора архитектурных приёмов, иначе продукту грозили дубли запросов, «белые экраны» и несогласованность состояний.

В этой статье я разобрал пятнадцать самых характерных «боевых» сложностей, показал, каким паттерном мы их укрощали, и какой антипаттерн поджидал за поворотом. Это не академический список, а выжимка из коммитов и ночных дебаг‑сессий, которая поможет тем, кто строит похожие интеграции между Telegram, TON и React.

Привет, Хабр! Я Борис Ермаченко, фронтенд-разработчик сервисов для физических лиц ПСБ. В этой статье рассмотрим, как с помощью ESLint построить архитектуру в проекте, и поговорим про несколько подходов.

Также прикладываю бонус — демо-проект, где можно экспериментировать и пробовать все подходы.

Ранее на Piccalilli Сэм Роуз поделился реальными примерами использования вспомогательных типов (utility types) TypeScript. Сегодня я хочу продолжить эту тему и поделиться несколькими продвинутыми возможностями TypeScript для работы с типами, которые, на мой взгляд, особенно полезны и применимы в реальных проектах.

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

Введение: Архитектурное дежавю

Вы когда-нибудь замечали, как цифровой мир движется по спирали? В 2018 году я, размахивая Dockerfile и Helm-чартами, внедрял микросервисы на C# с RabbitMQ — всё ради священной цели «низкой связанности». А через три года, переключившись на Angular, с ужасом осознал: фронтенд-компоненты общались через цепочки Input/Output, словно это 2005-й, а мы пишем WinForms.

Это как собрать космический корабль, но управлять им через телеграф. На бэкенде мы гордо декларируем event-driven architecture, а на фронтенде компоненты перешёптываются через пропсы, будто подростки на школьной дискотеке. Ирония? Чем сложнее становились наши системы, тем больше они напоминали те самые монолиты, от которых мы бежали в мире backend.

Фронтендеры, постоянно в поиске идеальной архитектуры. Слои, фича-слайсы, атомарный дизайн, фрактальность... Все эти подходы имеют право на жизнь. Но сегодня я хочу поделиться способом мышления, который сделает любой ваш код лучше, а любую архитектуру – яснее.

Как известно, у Solid довольно скудная экосистема, поэтому для сложных проектов я беру React+MobX. Однако недавно подвернулся небольшой mobile-only проект, в котором разве что маскированные инпуты и кастомные селекты, которых для Solid предостаточно. При этом требования к размеру выходных файлов и перфомансу были высокие.

Очевидным решением посчитал взять Solid, заодно и сравнить его по всем параметрам (размер, перфоманс, возможности реактивности, удобство настройки) в реальном проекте. Никаких синтетических тестов с рендерингом больших таблиц и хранением в сторе нескольких мегабайт данных не будет, зато приведу замеры из реального приложения. Бонусом — репозиторий с универсальной архитектурой для Solid+Preact+React, где замена фреймворка (набора стейт‑менеджер + рендеринг UI) производится одной строчкой кода.

Всем привет! 👋

Я — Дмитрий, автор Sury — самой быстрой библиотеки для работы со схемами. Если вы фанат Zod (а кто не фанат?), эта статья для вас. Сегодня я поделюсь неожиданными результатами тестов производительности Zod v4, расскажу, что это значит для вас, и как избежать подводных камней.

Zod v4: Стал в 17 раз медленнее и никто этого не заметил 🙈

Начнём с небольшого кликбейта.

Это действительно так, но, конечно, не вся правда. Давайте разберёмся.

Покрытие UI-тестами — вещь, о которой все говорят, но почти никто не измеряет. А если и измеряет, то по старинке, через Excel, TMS или на глаз. Это как считать шаги, не надевая шагомер.

ui-coverage-scenario-tool — это как шагомер, но для UI-тестов. Он показывает, с чем именно взаимодействуют ваши тесты, что осталось в тени, и главное — делает это автоматически. Без ручного труда, без вымышленных цифр, без «по ощущениям».

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

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

Я хочу сравнить самые популярные методы для редиректов в браузере с помощью JavaScript, а так же способы как их сделать безопаснее и продуманнее.

🐝 Тестирование роя агентов

Юнит тесты - единственный способ принять работу промпт инженера, так как не понятно, действительно ли он всё это время чатился с моделью или списал в работу на 5 минут пару недель времени. Так же, статья содержит типовые галлюцинации роя агентов, которые обязательно нужно проверить