TypeScript *

Привет! Я – Егор, фронтенд-разработчик в Чиббис. Наша команда разработала новый личный кабинет для партнеров – b2b-приложение с нуля, используя Feature-Sliced Design. В статье я делюсь нашим опытом: от выбора стека технологий до построения процесса разработки, который помог нам за 5,5 месяцев превратить пустую папку в рабочий продукт. Мы разберем итерации, FSD-макеты, этапы создания разделов и расскажем, как удалось сократить время разработки и тестирования.

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

Когда речь заходит о TypeScript, один из самых частых вопросов, которые мне задают студенты, звучит так: «Что лучше использовать: интерфейсы или типы?»

На эту тему написано уже множество статей, в том числе на Хабре (например тут и тут), и обсуждений в сообществе более чем достаточно. Однако даже после всех этих разъяснений часто остаётся ощущение, что однозначного ответа нет. Одни авторы говорят: «Интерфейсы лучше для декларативности», другие уверяют: «Типы универсальнее», и каждый подкрепляет свою точку зрения примерами.

Долгое время я придерживался простой и прагматичной позиции: «В целом разницы нет, всё зависит от предпочтений и соглашений команды». Однако, чтобы не быть голословным и действительно разобраться в нюансах, я решил покопаться в этом вопросе глубже.

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

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

В поисках наиболее точного и понятного объяснения различий между интерфейсами и типами я пересмотрел множество источников. Среди них особенно выделилась статья «Type vs Interface» от Mykyta M.. В ней автор обстоятельно разбирает преимущества и недостатки обоих подходов, а также приводит примеры их использования.

Добро пожаловать в путешествие по динамичному миру реактивного программирования! Эта увлекательная парадигма направлена ​​на создание быстро реагирующих, отказоустойчивых и адаптируемых приложений, которые легко и практически мгновенно управляют огромными объемами данных.

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

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

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

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

NestJS — это прогрессивный фреймворк для построения эффективных и масштабируемых серверных приложений на Node.js. Он использует современные возможности JavaScript и TypeScript, вдохновлен архитектурными паттернами Angular и поддерживает модульность, инъекцию зависимостей и другие современные подходы.

TypeORM — это ORM (Object-Relational Mapping) инструмент, который позволяет взаимодействовать с базами данных, используя объекты и классы, что упрощает разработку и поддерживает различные СУБД, такие как PostgreSQL, MySQL, SQLite и другие.

Сочетание NestJS и TypeORM предоставляет мощный инструментарий для разработки REST API, обеспечивая высокую производительность, модульность и удобство поддержки кода.

В этой статье я расскажу о добавлении нового поля workUntilDate с типом timestamp(6) в таблицу Webhook базы данных Webhook.

На стороне фронтенда (в Angular-приложении) для этого поля будет реализован удобный календарь с возможностью выбора времени.

Пользователи смогут задавать дату и время в своей временной зоне, тогда как бэкенд (NestJS-приложение) будет сохранять введённые данные в базе данных в формате UTC+0.

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

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

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

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

Всемирная паутина (WWW) — это не просто набор веб‑страниц, это революция, изменившая наше восприятие информации и общения. С момента своего появления в начале 1990-х годов WWW кардинально трансформировала мир, открыв новые горизонты для бизнеса, образования и повседневной жизни. История веб пестрит взлетами, падениями и уходами в крайности, но здесь мы пройдемся только по самым ярким моментам! Следить за эволюцией технологии, которая навсегда изменила наше общество, мы будем глазами фронтенд‑разработчика.

История о плагинах для TypeScript продолжается! В этой статье расскажу о том, как написать плагин для транспиляции, зачем использовать библиотеку ts-patch, как с её помощью можно трансформировать TypeScript и о многом другом!

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

В этой статье я покажу, как устроена многослойная архитектура крупного реактивного web-приложения, и особенности его запуска под Electron. Материал будет полезен, если вы планируете начать свою разработку, хотите попробовать себя в роли архитектора, вас не пугает Shared Workers, Service Workers или, в конце концов, вы хотите это попробовать или разобраться.

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

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

Этой статьей я хочу представить сообществу разработку www.ruinsworld.ru, которой, по сути, посвятил пять последних лет жизни. Все начиналось с браузерного сингл‑шутера, потом была не очень удачная и быстро наскучившая попытка в стратегию, после чего я поставил себе, казалось бы, невозможную задачу. Реально ли, используя все эти наработки, построить многопользовательский шутер в браузере, да еще не просто «стрелялку внутри небольшой коробки», а с большим открытым миром и огромным количеством неписей в нем? Чтобы можно было «идти куда хочешь во все стороны и делать что заблагорассудится», как в самых лучших постапокалиптических РПГ?

Обратная совместимость — одно из ключевых требований к современным UI‑библиотекам, которое стоит в одном ряду с требованиями к удобству использования компонентов и наличию качественной дизайн‑системы. Более того, она должна обеспечивать не только сохранение работоспособности проекта клиента после обновления библиотеки, но и неизменность самого подхода к написанию кода. Последний аспект может бросать определённые вызовы для команды разработки UI‑библиотеки и создавать уникальные сценарии.

Привет, Хабр! На связи Павел Урядышев, главный ИТ‑инженер Platform V UI Kit в СберТехе. В этом материале я расскажу, с какой необычной проблемой обратной совместимости столкнулась наша команда во время подготовки релиза UI‑библиотеки Platform V UI Kit. Это решение для построения интерфейсов любого уровня сложности: от корпоративных приложений до сайтов.

Привет, это снова Костя из Cloud.ru! В своих последних статьях я делился рецептами довольно сложных типов. Например, рассказывал, как преобразовывать ключи объектов из snake_case в camelCase. Давайте представим, что вы воспользовались одним из таких рецептов. Как его поддерживать? И что скажет ревьюер, увидев такой код?

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

В Angular 15 появилась новая фича, которой не уделяют должного внимания, — Directive Composition API. Она добавляет hostDirectives: [...] в декоратор @Component/@Directive. В этом массиве можно перечислить standalone-директивы, которые хотим автоматически навесить на компонент или директиву. Это позволяет очень удобно декомпозировать логику и открывает много дверей для новых подходов к разработке.

Всем привет! 13 ноября, в официальном Telegram канале Feature Sliced Design состоялся релиз новой версии архитектурной методологии. Он принёс в себе несколько важных, фундаментальных изменений, о которых мы сегодня и поговорим.

Вокруг все говорят о серверных компонентах реакта, о серверном рендеринге, и разных новшествах в мире фронтенде. Как будто JQuery в один миг взял и исчез. Несмотря ни на что он всё ещё остаётся самой популярной библиотекой 😅.

Сегодня я вам расскажу, как мы постепенно мигрируем с JQuery на React.

В текущей версии TS (5.7) нет нативного расширения типов.

Расширение в TS реализуют интерфейсы через ключевое слово extend, причем интерфейсы могут быть расширены только от одного объекта.

Хотя для типов (type/interface) предусмотрена операция интерсекции (&), которая объединяет свойства двух или более типов - она обладает важным ограничивающим свойством - при наличии одинаковых свойств, операция интерсекции присваивает их результирующему типу значение never.

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

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

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