Всем привет! Сегодня я возвращаюсь с новой порцией TypeScript- и React-магии. Вместе разберем полиморфизм в React, а именно — паттерн as. Зачем он нужен, как его прикрутить без багов и почему это сделает ваши компоненты в разы круче. Как обычно — всё под катом.
Привет! Меня зовут Алексей Гомелевский, я frontend-разработчик в Garage Eight. Моя команда занимается улучшением взаимодействия пользователей с продуктом, и недавно мы решили реализовать комментарии. В этой статье расскажу, как выбирали между решением из коробки и собственной разработкой, с какими сложностями столкнулись и как на базе комментариев создали чаты.
Я построил полноценную образовательную платформу для изучения иврита — с интерактивными тренажерами, умным словарем на 4000+ слов и системой подписок. В статье рассказываю о нетривиальных технических решениях, архитектурных выборах и ошибках, которые пришлось исправлять по ходу.
Продукт: hebrewglot.com
Стек: Next.js 15, TypeScript, PostgreSQL + SQLite, Stripe, NextAuth
Hawk — это open-source трекер ошибок, разработанный в России. Позволяет отслеживать ошибки в веб-приложениях, API и мобильных сервисах. В этой статье подробно рассмотрим функциональность, которая сегодня доступна пользователям Хоука — от регистрации до продвинутых SDK-функций и планов на будущее.
Решил мигрировать с WebStorm на VS Code, но обнаружил, что нет поддержки автоимпорта Angular-компонентов. В WebStorm это работало из коробки — начинаешь писать <app-, IDE сразу подсказывает компоненты и автоматически добавляет импорт. В VS Code такого не было.
На первый взгляд задача выглядела несложной — пару регулярок накидать и можно сделать своё решение.
Но пока я разбирался с регулярками, Angular-разработчики выпустили официальную поддержку: добавили импорты на автокомплит и диагностику. Можно было опустить руки, но официальная реализация оказалась неидеальной, и у меня было несколько идей фич, которые позволяют сохранить актуальность проекта и приблизить опыт работы к WebStorm.
Сколько раз вы меняли поле в API, обновляли тип на бэкенде, а потом вспоминали, что надо поправить ещё и фронтенд? А если есть мобилка? А если схемы валидации тоже дублируются? Я устал от этого и создал шаблон монорепозитория, где TypeScript типы, Zod схемы и константы живут в одном месте и используются везде.
Однажды при работе с крупной кодовой базой одного фронтенд-приложения я заметил, что функционал постепенно группируется относительно команд (доменов). Каждая из таких групп функционала постепенно накладывает собственные ограничения на архитектуру. Как оказалось, обработка ошибок при сравнении кода двух разных команд неоднородна. В одном случае разработчики структурировали ошибки стандартным наследованием JS/TS, в другом были использованы перехваты возникающих ошибок и логирование.
Стало ясно, что нам требуется обобщить подход к тому, как мы структурируем (называем, наследуем) и выбрасываем ошибки. Как показала практика, соглашений о кодировании недостаточно.
Что мы хотели получить?
Object-Relational Mapping (ORM) — технология, призванная «поженить» реляционную природу SQL-баз (PostgreSQL, MySQL, SQLite и т.п.) с объектной моделью языков программирования. Она настолько популярна, что её пытаются реализовать даже в необъектных языках — например, в Go или Erlang.
Если в Java без ORM действительно неудобно, то в экосистеме Node.js (и TypeScript в частности) ситуация принципиально иная. И ORM здесь — зачастую избыточная абстракция. В большинстве случаев рациональнее обойтись компактным SQL-билдером который сильно упрощает построение запросов, оставляя над ними полный контроль, и который совсем не занимается управлением объектами. Почему в Node.js ORM почти не даёт преимуществ...
Привет! Я Максим Кузьмин, старший инженер по автоматизации в команде Т-Путешествий. Строю и развиваю процессы автоматизации и разрабатываю инструменты тестирования.
Для внутренних нужд мы разработали фреймворк для изолированного тестирования бэкенда. Он написан на TypeScript, обеспечивает гибкость, масштабируемость и интеграцию с разными внутренними системами. Выступает как единое решение для написания, запуска и поддержки тестов в стабильной и предсказуемой среде.
В статье будет история миграции с Jest на Vitest. Расскажу, какие проблемы подтолкнули нас к переходу, как мы адаптировали окружение и какие результаты получили. Поделюсь опытом улучшения скорости запуска тестов и стабильности результатов. Надеюсь, что наш опыт поможет кому-то превратить автотесты из источника проблем в устойчивый инструмент контроля качества.
Да, я его действительно ненавижу. Мне кажется, что команда React'а презирает разработчиков, и я презираю их в ответ. Все их решения направлены на то, чтобы сделать разработку сложнее, медленнее и непредсказуемее. На сегодняшний день они даже умудрились сломать работу JavaScript. Уму непостижимо, почему им это сходит с рук.
Очередной чат, и к тому же на rust?! Да, yet another. И да, в этой статье не будет каких-то новых откровений системного программирования с написанием своего фреймворка для работы со сетью на уровне драйверов или других испытаний. Этот альманах про мой первый опыт в веб-разработке, который может быть полезен для других новичков, ведь тут мы затронем помимо злосчастного rust такие вещи, как devcontainer, REST API, идентификацию-аутентификацию-авторизацию, WebSockets, SSE, юнит и интеграционные тесты, некоторые паттерны, логирование и прочее.
За годы работы с TypeScript, Java, Kotlin и Go я не раз сталкивался с одним и тем же паттерном: команда внедряет «правильное» архитектурное решение — и получает не гибкость, а технический долг.
Причина проста: оверинжиниринг маскируется под профессионализм. Мы выбираем сложные инструменты не потому, что они нужны, а потому, что «так делают в серьёзных проектах».
В результате принцип KISS — «Keep It Simple, Stupid» — работает не хуже, чем в 1930-х, когда его впервые сформулировали в среде авиационных инженеров. В этой статье — мой личный список подходов, которые в 90% случаев (особенно в REST-серверах) приносят больше вреда, чем пользы.
Solo developer journey: Как я довел B2B платформу от 8.5/10 до 8.8/10, исправил 13 критических багов, прошел Context7 MCP аудит и успешно задеплоил на production с первыми пользователями.
После первой части (концепция и MVP) и второй части (решение технических проблем), настал момент истины - финальная подготовка к production.
Привет, Хабр! На связи снова Сергей, ведущий фронтенд-разработчик из Центрального университета. В последнее время я преисполнился URL и опять хочу про него рассказать.
В прошлой статье я рассказал о том, почему неправильно использовать URL API для валидации ссылок. В этот раз буду использовать инструменты по назначению. Речь пойдет про новый URLPattern API для сопоставления URL с шаблонами, который позволит валидировать ссылки без головной боли.
Всем привет, я Иван, продакт-менеджер. И я состою в айтишном чате — человек двести, может, чуть больше. Там всё как обычно: обсуждаем новости, спорим про фреймворки, кидаем мемы.
Сообщений очень много, и когда новички приходят, пишут интро о себе — через пару минут их уже никто не видит, всё уходит в ленту. В какой-то момент стало интересно: можно ли эту проблему решить алгоритмом?
Так появилась идея бота, который помогает людям знакомиться по интересам, а не случайно. В этой статье я расскажу, как мы с командой его сделали.
В этой статье я покажу, как связать Nest.js и Obsidian: хранить заметки в формате Markdown прямо из бэкенда, редактировать и синхронизировать их с базой данных. Если вы тоже любите Obsidian и пишете pet-проекты — это может вам помочь.
Продолжение статьи о разработке B2B платформы международной торговли
Прошло несколько месяцев с момента публикации первой части, где мы рассказали о концепции и начальном этапе разработки LiqTrade. За это время проект прошел путь от MVP до полноценной production‑ready платформы.
В этой статье я хочу поделиться реальными проблемами, с которыми мы столкнулись, и способами их решения. Никакого идеализированного «как всё прекрасно работает» — только честный разбор косяков, рефакторинга и технического долга.
Дисклеймер: Если вы ищете статью в стиле «10 строк кода, и ваш стартап взлетел» — это не здесь. Здесь будет про то, как мы 3 раза переписывали систему ролей, боролись с circular dependencies и почему наш bundle вырос до 1.2 МБ (спойлер: мы его победили).
Интеграция простой формы с AmoCRM на «бумаге» выглядит просто. Кажется, что можно просто отправить контакт, создать лид, прикрепить товары к сделке — и готово». На практике всё наоборот.
Честно говоря, документация AmoCRM сначала меня запутала. Я полез гуглить по моей ситуации (связка формы с CRM) почти ничего. Посмотрел ролик на YouTube про библиотеку. Понял основы, но всё равно оставалось куча вопросов.
Дело в том, что AmoCRM в упор не видит дубликаты контактов и товаров. При очистке дублей из админки ничего не удаляется. Все из-за уникальных ID, которые назначаются при отправке данных.
После множества экспериментов, я все таки смог подружить небольшой бэкенд и API AmoCRM.
В TypeScript аннотация типа или указание типа осуществляется с помощью оператора
двоеточия : , после которого следует идентификатор типа. TypeScript является
статически типизированным языком, поэтому после того как идентификатор будет
связан с типом, изменить тип будет невозможно.
