Начнем цикл статей нашей компании легко и непринужденно, с темы из мира front-end. Надеюсь, что статья будет полезна тем, кто хоть как то связан с миром front-end. Предупреждаю, что backend разработчикам может быть скучновато из-за того, что у них давно все стандартизировано)

Когда я провожу собеседование на позицию React разработчика, обычно задаю общий вопрос об архитектуре - "как бы ты строил архитектуру своего приложения и почему?". После обсуждения, я начинаю рассказывать небольшую часть материала из этой статьи, 5% по содержанию, приводя тезисы, по которым можно будет собрать общую картину моего видения. И обычно получаю положительную обратку. Поэтому решил изложить этот материал более развернуто здесь. Буду отправлять ссылку тем, кому это может пригодиться.

Angular Signals является частью будущей спецификации 16-й версии Angular. В первую очередь Signals нацелены на решение проблемы с обнаружением изменений в Angular, однако Angular Team позаботилась и о том, чтобы разработчики смогли не только писать более оптимальный код с точки зрения самого фреймворка, но и чтобы самим разработчикам было удобнее и приятнее писать код на Angular. Сигналы предлагают более декларативный подход для написания приложений, позволяя новичкам быстрее вкатываться в Angular и по-новому посмотреть на использование RxJs в своём приложении.

Типичное видение модели распространения события, которое мы привыкли видеть в интернете - это модель всплытия события (bubbling) подобно пузырьку, или погружению (capturing) подобно “камню”.

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

Hello, world!

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

В первой части мы поговорим о возможностях JS, во второй — о возможностях TS.

Это первая часть.

Вот ссылка на вторую часть.

Обратите внимание: название почти каждой возможности — это также ссылка на соответствующий раздел MDN.

Руководства, шпаргалки, вопросы и другие материалы по JavaScript, TypeScript, React, Next.js, Node.js, Express, Prisma, GraphQL, Docker и другим технологиям, а также Блог по веб-разработке.

Всем привет, меня зовут Владимир. Я занимаюсь фронтенд разработкой в Tinkoff.ru.

В Ангуляре для передачи данных внутри приложения или для инкапсуляции бизнес-логики мы привыкли использовать сервисы. Для управления асинхронными потоками отлично подходит RxJS.

Ангуляр в сочетании с RxJS позволяет писать в декларативном стиле, коротко и ясно. Но иногда мы сталкиваемся со сторонними библиотеками или API, которые используют коллбэки, промисы, тем самым подталкивают нас отступить от привычного стиля и писать императивно.

Цель статьи — показать на примере подобных API, как с помощью RxJS их можно без проблем обернуть в Observable-сервисы. Это поможет достичь удобства использования в Ангуляре. Начнем с Geolocation API.

Плюсы микро-фронтенд архитектуры

• Автоматизация CI /CD. Поскольку каждое приложение интегрируется и развертывается независимо, это упрощает CI/CD. Так как все модули разделены, то не нужно беспокоиться обо всем приложении при внедрении нового модуля. Если в коде модуля есть ошибка, CI/CD прервет весь процесс сборки.
  Гибкость команд разработчиков. Многочисленные команды могут разрабатывать и развивать информационные системы, работая по отдельности.
• Единая ответственность. Каждая команда микро-фронтеда на 100% фокусируется на функциональности своего микро-фронтенд приложения.
• Возможность повторного использования. Микро-фронтенд приложение может быть повторно использовано несколькими командами в разных системах.
• Технологический агностицизм. Архитектура микро-фронтенд не зависит от технологии. Возможно использовать компоненты, разработанные на разных фреймворков веб-разработки (React, Vue, Angular и т.д.).
• Простой порог входа в систему. Небольшие модули легче изучать и понимать новым разработчикам, входящим в команды, чем монолитную архитектуру с огромной структурой кода.

Мы используем TypeScript, потому что это делает разработку безопаснее и быстрее.

Но, на мой взгляд, TypeScript из коробки содержит слишком много послаблений. Они помогают сэкономить немного времени JavaScript-разработчикам при переходе на TS, но съедают очень много времени в долгосрочной перспективе.

Я собрал ряд настроек и принципов для более строгого использования TypeScript. К ним нужно привыкнуть один раз — и они сэкономят массу времени в будущем.

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

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

Привет!

Саша Инкин и я регулярно пишем на Хабр статьи по Angular. Почти все они основаны на нашем опыте разработки большой библиотеки компонентов.

Эту библиотеку мы развиваем, перерабатываем и дополняем уже несколько лет, а свои идеи проверяем на нескольких десятках проектов Тинькофф Бизнеса и внутренних систем компании. Мы рады сообщить: выложили нашу библиотеку в открытый доступ!

В этой статье хочу описать основные концепции и практики, на которых строится библиотека, а также рассказать, почему ее стоит внедрить как в новые проекты, так и в уже готовые — с иными компонентами или UI Kit’ами.

Вам когда-нибудь хотелось отобразить состояние загрузки, пока ngIf ждет ответа от async-пайпа? Или, может, вы мечтали передать в ngFor шаблон для пустого массива? Возможно, вы бросили это, потому что вам не хотелось реализовывать базовую логику этих директив самому. На самом деле в этом нет нужды! Один и тот же селектор может подцепить несколько директив, что позволяет расширить функциональность встроенных директив дополнительной логикой.

Недавно Бхарат Рави опубликовал статью о директиве самосохраняющегося select-элемента на InDepth. Это интересная концепция изолирования логики в директиве, что в целом идея хорошая.

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

Сверстать собственный индикатор загрузки — одна из самых простых задач, с которой может столкнуться веб-разработчик. Для получения рабочего решения пригодятся базовые знания HTML и CSS, а JS будет нужен лишь для управления процентом выполненной задачи.

Однако эта простота обманчива. Интернет наполнен множеством решений, в которых индикатор загрузки анатомически состоит из кучи вложенных друг в друга div-контейнеров, приправленных щепоткой CSS. Не нужно так! В мире грустит один котенок, когда вы игнорируете семантику верстки и забываете про доступность (a11y).

В этой статье я расскажу, как мы в проекте Taiga UI подошли к написанию собственных Angular-компонентов ProgressBar и ProgressCircle.

В Angular есть два режима change detection: Default и OnPush. В этой статье мы разберем, как можно спокойно использовать OnPush всегда без лишнего труда и почему стоит начать это делать.

Чтобы использовать Angular CLI на полную, разработчики должны знать, что такое схематики. Например, команды ng add, ng update и ng generate используют схематики для добавления, обновления и настройки библиотек и кодогенерации в приложениях. Во время выполнения схематика вы получаете доступ к файловой системе и можете мутировать исходный код приложения так, как вам нужно. «Но, чтобы мутировать код, нужно работать с AST, а это сложно», — возможно, скажете вы, и будете правы!

В этой статье расскажу, как мы пытаемся упростить работу с AST и сделать написание схематиков обыденным. А еще покажу, что так же просто можно работать с AST не только в Angular-проектах, а практически в любом проекте на JavaScript/TypeScript.

Когда я интегрировал свое Angular-караоке с YouTube, мне попался официальный YouTube-компонент из Angular Material. В README прилагалась инструкция для подключения. Почти каждая строка в ней примере сомнительна. Давайте разберемся, как сделать лучше и применить имеющиеся инструменты для ленивой подгрузки библиотеки.

На днях я смотрел кино, где оператор использовал телеграф. Он знал наизусть азбуку Морзе и очень быстро нажимал свою единственную кнопку. Я задумался: с RxJS мы способны на большее! Давайте запилим телеграф, используя единственный fromEvent и массу интересных трюков. Потренируемся с Dependency Injection, директивами и операторами RxJS, чтобы собрать демо, которое выглядит круто и звучит аутентично.

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

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

Статья написана по опыту разработки фронтовых библиотек и с советами вокруг JS-экосистемы, но часть идей будет полезна и для других направлений.

Taiga UI — это огромная библиотека компонентов на Angular. Мы в Тинькофф разрабатывали ее внутри пару лет, прежде чем выпустили вторую, мажорную версию на публику. С тех пор прошел год, и я хочу подвести итоги и обозначить планы на 2022 год.