Что вы знаете о Schedulers в RxJS? Они скрывают от разработчиков работу с контекстом выполнения Observable. Как те эльфы-домовики из Гарри Поттера, которые выполняют всю черную работу в Хогвартсе, а о них никто даже и не слышал. Давайте исправим это и узнаем о них чуть больше.

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

Как и многие другие Angular-разработчики, я мирился с одним ограничением. Если мы хотим использовать Observable в шаблоне, мы можем взять знакомый всем async-пайп. Но его нельзя применить к @HostBinding. Давным-давно это было возможно по ошибке, но это быстро исправили. Все потому, что хост байндинг относится к родительскому view и в нем этот пайп может быть не подключен. Это довольно желанная фича. Давайте посмотрим, как мы можем ее реализовать, пока нет официального решения.

Drag & drop - одна из функций, которая может быть очень полезна для пользователей нашего приложения. Кроме того, это отличный пример, показывающий, как RxJS можно использовать для простой реализации функционала перетаскивания. Давайте посмотрим, как мы можем это сделать.

Первое, что нужно понять об операторах, - это почему они существуют. Они существуют, потому что observables как тип позволяют нам обрабатывать события (или значения во времени) как множества или набор вещей.

Говоря более просто, любое четко определенное множество будет иметь операции, которые могут быть выполнены с ним, которые могут преобразовать его в новое множество того же типа. Например, предположим, что у нас есть грузовик с яблоками. Мы могли бы превратить его в грузовик с нарезанными яблоками с помощью машины для нарезки яблок. Та же самая машина для нарезки яблок затем может быть использована на любом грузовике с яблоками, чтобы превратить их в грузовик, загруженный нарезанными яблоками. В этом случае машина для нарезки яблок будет считаться «оператором», который сопоставляет яблоки с ломтиками яблок. Точно так же мы могли бы иметь грузовик с сахаром, мукой, яйцами и т. д. И объединить их с грузовиком с ломтиками яблока, чтобы сделать грузовик с яблочными пирогами, используя какую-то машину для производства пирогов. Итак, в этом примере грузовик - это тип множества, машина для нарезки яблок или машина для изготовления пирогов будут «операторами», а сахар, яблоки, ломтики яблок, яйца и т. д. Будут просто значениями, переносимыми нашим типом множества.

В результате работы с фреймворком Angular, мы декомпозируем наше web-приложение. И по этому у нас возникает ситуация, когда нам нужно передавать данные между компонентами.

Работая с Angular волей-неволей будешь использовать RxJS, ведь он лежит в основе фреймворка. Это очень мощный инструмент для обработки событий и не только. Однако далеко не каждый проект использует его по полной. Часто это просто запросы на бэк, нехитрые преобразования данных и подписка. Мы с Ромой очень любим RxJS и решили собрать несколько интересных кейсов из нашей практики. Мы сделали из этого что-то вроде челленджа на 20 задачек, которые мы предлагаем решить с помощью RxJS и попрактиковать свои навыки.

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

Меня зовут Андрей, и я занимаюсь разработкой фронтенда на Angular для внутренних продуктов компании. Фреймворк обладает обширными возможностями, одни и те же задачи можно решить огромным количеством способов. Чтобы облегчить свою работу и повысить продуктивность, я задался целью найти универсальный и не сложный подход, который бы упростил проектирование и позволил уменьшить объем кода при сохранении его читаемости. Методом проб и ошибок я пришел к архитектуре, которой хочу поделиться в этой статье.

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

One of the main challenges in the world of web development is to achieve a seamless user experience. Many factors come into play when trying to achieve the goal of a smooth UX. The user interface, the load-time of webpages, and updating any data/input sent, are some prominent examples.

All web development frameworks offer tools that enable the developer to make the UX as smooth as possible. After all, it’s an important aspect of a website. In the case of the popular front-end framework Angular, such a tool is the RxJS library.

Through RxJS, Angular applications can employ the reactive programming and functional programming paradigms to ensure a smoothly working inside-out. This article acts as a quick guide to RxJS and how it is used in Angular applications. It will discuss some of its robust features and give you their flavor through code examples. Using RxJS to speed up and improve an Angular application’s UX is common practice and this article will show you why.

What Does RxJS Do Exactly?

In the everyday workings of a website, it handles different requests and events. Requests like inputting/outputting certain data or transforming some data, and events like responding to a mouse click or keyboard key press. If all of the requests and events are coming in one after another (synchronously), they are responded to in that order. However, few frameworks can respond quickly and reactively in the case of asynchronous requests and events.

RxJS is a JavaScript library of functions that allow to smoothly handle asynchronous events and requests. The name comes from the fact that it enables reactive programming in JavaScript. It allows for playing with and tracking time in your Angular application. The amount of time between responses or events can be fine-tuned as required through RxJS, letting the developer control the responsiveness of the application.

Эта статья — перевод оригинальной статьи Ben Lesh “Learning Observable By Building Observable”.

Ben Lesh рассказывает как создать свой observable и сравнивает его работу с observable из RxJs.

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

Около 5 лет назад я пересел с Реакта на второй Ангуляр и первое, чего мне там не хватило был модуль angular-resource из первого Ангуляра. Вменяемых аналогов я не нашел, поэтому за неделю написал свою библиотеку. Решение оказалось настолько удачным, что практически без изменений дошло до сегодняшнего дня. Используется в куче проектов, работает стабильно (не смотря на то, что до сих пор там нет ни одного теста), в общем, есть о чем рассказать.

Что привлекает в Ангуляре экспертов и удручает начинающих? Одно и тоже, RxJS.

   Почему же это так сложно для начинающих? Возможно потому, что есть очень большое количество операторов, которые нужно просто знать, и без поиска понимать в чем разница между concatMap, switchMap и mergeMap. Почему же это так нравится тем, кто это уже выучил? Возможно, потому что вы начинаете понимать все могуществао RxJS, когда одним оператором вы можете сделать то, что в императивном коде писали бы полдня на двух страницах. Ведь это так приятно, ощущать себя богом, когда код просто отскакивает от ваших пальцев, а вы радостно рассказываете коллегам как вы классно и главное просто решили задачу.

• Часть 1. Реактивность и потоки
• Часть 3. Higher Order Observables

"Вы поймете, когда вам нужен Flux. Если вы не уверены, что вам это нужно, вам это не нужно." Пит Хант

Для управления состоянием приложения я как правило применяю Redux. Но не всегда есть необходимость в использовании модели Action\Reducer, хотя бы из-за трудозатратности ее применения для написания простейшего функционала. Возьмем в качестве примера обычный счетчик. На выходе хотелось получить простое и практичное решение, которое позволит описать модель состояния и пару методов его меняющие, наподобие такого:

state = {value: 0} 
increase() { 
  state.value += 1 
} 
decrease() {
  state.value -= 1
}

Сходу кажется, что такое решение может обеспечить MobX, так почему бы им и не воспользоваться? Поработав с MobX некоторое время, для себя пришел к выводу, что лично мне проще оперировать последовательностью иммутабельных состояний (наподобие Redux), чем логикой мутабельного состояния (наподобие MobX), да и его внутреннюю кухню я бы не назвал простой.

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

В прошлой статье мы рассмотрели как создавать свои операторы RxJS. Сейчас я хочу поговорить о малоизвестном операторе создания — defer — и объяснить как можно использовать его для некоторых ситуаций