TypeScript *

RxJS (Reactive Extensions for JavaScript) — мощный инструмент для работы с асинхронными потоками данных, который используется во многих современных веб-приложениях. Хотя RxJS предоставляет богатую коллекцию операторов, иногда для решения специфических задач бывает необходимо писать свои собственные. Это позволяет избежать дублирования кода и повысить читаемость программы.

Создание своих операторов RxJS может показаться сложным, особенно для тех, кто только начал использовать библиотеку. Однако, фундаментальные принципы их разработки понятны, если погрузиться в механику работы RxJS. В этой статье мы углубимся в то, как создавать собственные pipeable и creation operators, а также рассмотрим практические примеры их применения.

В этой статье я расскажу о настройках TypeScript, определяемых в файле tsconfig.json, которых я использую в своих проектах.

❯ 1. Возможности, не затрагиваемые в этой статье

В этой статье описывается в основном настройка проектов, в которых все локальные модули являются ESM. Мы почти не будем говорить об импорте CommonJS.

Также мы не будем говорить о следующем:

• импорт и проверка типов обычного JavaScript — настройках allowJs и checkJs
• настройка JSX. См. раздел "JSX" карманной книги по TS
• "проекты" (полезно для монорепозиториев): настройка composite и др. См.:
  
  • раздел "Ссылки на проекты" карманной книги по TS
  • статья "Создание простых монорепозиториев с помощью пространств имен (namespaces) npm и ссылок на проекты TS"

Я и сам до конца не знаю, является ли заголовок статьи кликбейтом или нет. Разберёмся в комментариях. Только давайте по-честному! Согласен с тезисами — напиши, что статья огонь, поставь лайк и всё такое. Не согласен — аргументируй, а не просто: «бред»! Есть что добавить (идеи, фишечки) — добро пожаловать в комментарии.

Привет, меня зовут Андрей Шпилевский, и в этой статье я расскажу, почему я делаю тестовое лучше большинства, а также дам советы, как проходить этот этап быстро и максимально эффективно. Тема достаточно большая, поэтому будет разбита на 3 части. Это первая и начну ее я, пожалуй, не с советов: ‘Делай так, спина болеть не будет’, а с лирического вступления, которое, на самом деле, важнее, чем какие-либо пункты.

Если вы разрабатывали приложения на Angular, то наверняка сталкивались с ситуацией, когда множество компонентов требуют тесного взаимодействия друг с другом. Количество @Input, @Output, Services и Subjects растет с каждым коммитом и требует все больших усилий для сохранения качества кода...

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

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

Эта статья станет интересной не только специалистам по TypeScript, но и всем разработчикам, ищущим лучшие практики работы с ошибками в современном программировании.

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

Я подробно описываю, как моя реализация решает сложности AWS SDK и делает его использование более надежным.

Буду рад узнать ваш подход к работе с ошибками, пишите в комментарии. Спасибо!

Недавно давно я смотрел ничем не примечательный техническое интервью и услышал фразу от интервьюируемого: «Ну можно написать свой useReducer или useState». Мне врезалась эта фраза в голову, ибо я никогда в серьез не задумывался как они работают под капотом и в исходниках особо не копался, максимум в типах. Поэтому я решил их воссоздать с минимальным количеством зависимостей и попытался интегрировать в реакт.

Современный React все больше соответствует идеалам функционального программирования.

Ежедневно мы пользуемся подходами из мира ФП, зачастую даже не подозревая об этом.

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

В этой статье мы применим один из функциональных паттернов в React приложении и посмотрим что из этого выйдет.

С ростом приложения и увеличением количества зависимостей, мы осознали необходимость в централизованном управлении зависимостями, выходящем за рамки React и MobX. Существующие IoC-контейнеры показались избыточными и тяжеловесными. Поэтому было создано собственное решение. В статье вы узнаете, как мы решили уравнение :-)

Удивился, что про столь популярный продукт не было статьи на Хабре, срочно это исправляю. Drizzle ORM — это #2 самая желаемая ORM по опросам, и она даже вошла в top 50 JavaScript Rising Stars 2024, заняв 27 место.

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

Цель этого эксперимента — проверка жизнеспособности стека ASP .NET + WebKitGTK + frontend на JS/TS. Этот стек предназначен для работы на ОС Linux. В проекте весь код написан на C# за исключением клиентской части, которая реализована при помощи TypeScript и Angular 19.1.

Этот концепт представляет из себя приложение, которое получает данные из Github API и для выбранного языка программирования проводит анализ количества новых репозиториев github по годам, строя линейную диаграмму, показывая тем самым тренд языка программирования. Этот анализ изначально не слишком объективен, но для тестового приложения вполне нормальный сценарий использования. В приложении на том же WebKitGTK реализована OAuth аутентификация Github. Полученные токены хранятся в системе при помощи библиотеки libsecret в зашифрованном (AES) виде. После первого входа пользователю необходимо установить пин-код, который является частью ключа. Немного заморочился с безопасностью токенов, да =)

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

Трудно представить код современного React-приложения без таких функций как useState, useEffect, useRef и так далее.

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

Создание кастом-хуков это прекрасная возможность выделить часто переиспользуемый код в отдельные сущности.

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

Ниже мы рассмотрим примеры некоторых из них.  

В данной статье я хочу затронуть такую интересную тему, как обновление бандла Capacitor-приложений (CodePush, live update и т.д).

Сталкивались ли Вы когда-нибудь с ситуацией, когда необходимо незначительно обновить мобильное приложение, написанное на Capacitor?

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

А если нужно сделать релизы во всех популярных магазинах? Google Play, RuStore, AppGallery и, конечно же, самые нерасторопные из существующих — App Store. Выпуск во всех интересующих магазинах может занять значительное время. Вы, конечно, можете автоматизировать этот процесс при помощи различных инструментов, но, так или иначе, это занимает время на одобрение модераторами.

Привет, Хабр. Я Сергей, фронтенд-разработчик в Clevertec. И сегодня поделюсь опытом использования обновленной 7-й версии React Router. Расскажу, как мы реорганизовали структуру роутинга. Покажу, как избавились от лишних «букав кода», улучшили производительность приложения, создали навигацию по страницам и еще много полезного.

Многие, конечно, знают, что в Angular-сообществе принято трепетно следить за подписками на Observable, потому что это чревато утечками памяти. Но не все видели эти утечки в глаза и не встречались с их последствиями. Давайте смоделируем простую ситуацию по следам утечки, с которой недавно столкнулся я (первый раз).

В этой статье я рассказываю о создании своей библиотеки для работы с Telegram Bot API на TypeScript.

Около половины материала посвящено разработке собственного парсера, который превращает рутинные HTTP запросы в удобный и типизированный интерфейс.

Если вам интересно, как избавиться от постоянного переключения между документацией и кодом и при этом сохранить весь набор возможностей API – эта статья для вас 😊

Как всего одна небольшая React-задача помогает глубже понять уровень кандидата на собеседовании? Разбираем нюансы работы с хуками, асинхронностью, состоянием гонки и сайд-эффектами. На первый взгляд задача кажется простой - всего лишь компонент, загружающий данные по username. Но в процессе решения выявляются ключевые моменты: правильно ли кандидат управляет состоянием, учитывает ли смену пропсов, обрабатывает ошибки и предотвращает race conditions. Этот вопрос помогает не просто проверить знания, а увидеть, как кандидат рассуждает и принимает технические решения.

Привет! Я инженер по контролю качества продукта Amplicode в компании Haulmont. Одним из направлений деятельности нашей компании является разработка плагинов для IntelliJ IDEA и расширений для VSCode. Передо мной встала задача протестировать расширение Amplicode Frontend для VS Code. Задача оказалась не самой тривиальной и в процессе мы столкнулись с немалым количеством проблем и нюансов, о которых я и хочу рассказать в этой статье.