Наверняка многие уже слышали о подходе FRP для организации асинхронного кода. На хабре уже писали об FRP (Реактивное программирование в Haskell, FRP на Bacon.js) и есть хорошие доклады на эту тему (Программировние UI с помощью FRP и Bacon.js, Functional Reactive Programming & ClojureScript, О Bacon.js от Juha Paananen — автора бекона)

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

Вот что это дает по сравнению с обратными вызовами:

1) Поток событий (Event stream) и значение меняющаяся во времени (Property / Behavior) становятся объектами первого класса. Это значит что их можно передавать в функции и возвращать из функций.

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

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

К примеру можно написать функцию, возвращающую поток перетаскиваний (drag). В качестве параметров она будет принимать 3 потока — начало перетаскивания, движение, конец перетаскивания. Дальше можно передать в эту функцию: либо потоки для соответствующих событий мыши (mousedown, mousemove, mouseup), либо для touch событий (touchstart, touchmove, touchend). Сама же функция не будет ничего знать об источниках событий, а будет работать только с абстрактными потоками. Пример реализации на Bacon.

2) Явный state

Второе большое преимущество FRP это явное управление состоянием. Как известно, state — один из самых главных источников сложности программ, поэтому грамотное управление им позволяет писать более надежные и простые в поддержке программы. Отличный доклад от Рича Хикки о сложности (complexity) «Simple Made Easy».

FRP позволяет писать бОльшую часть кода на «чистых функциях» и управлять потоком данных (dataflow) явно (с помощью потоков событий), а состояния хранить тоже явно в Property.

Задача: на входе сигналы с клавиатуры (keyup, keydown) — на выходе буквы и слова декодированные по азбуке Морзе. О том, как декларативно решить данную задачу используя FRP подход, в частности Rx.js — ниже под катом. (Зачем? Because we can)

Способы «общения» компонентов

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

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



Это чем-то напоминает WI-FI в кафе, когда все могут обмениваться сообщениями со всеми, но при этом есть роутер (диспетчер), который обеспечивает существование «эфира» и отдает сообщения только тем, кому они адресованы.

Такая организация позволяет, например, «бесплатно» получить слабое связывание компонентов. Недостаток ее в том, что при росте числа компонентов и соответственно числа событий становится сложно уследить за именами событий и за тем, кому какие события нужны для правильной работы. Появляются пространства имен и имена событий из чего-то типа «Событие1» превращаются в «Состояние_приложения1.Компонент2.Событие1». И что совсем невозможно делать при такой организации это компоновать события. Например требование «сделай что-то когда событие Б возникнет после двух событий A» выливается в тонну локальных переменных, хранящих последние данные из событий и счетчики самих событий.

Этот пост просто шутка и не пытается выставить инструменты, упомянутые здесь, в дурном свете. Я использую их постоянно, они великолепны, и я рекомендую их использовать. По мотивам It's the future @ CircleCI Blog

— Эй, я бы хотел научиться писать крутые веб-приложения. Слышал, у тебя есть опыт.

— Да, я как раз занимаюсь фронтендом, юзаю пару тулз.

— Круто. Я щас делаю простое приложение — обычный TODO-лист, используя HTML, CSS и JavaScript, и планирую заюзать JQuery. Это норм?

— Не-не-не. Это олдскул. Джиквери мёртв — никто не использует его теперь! Тебе нужен React. Это будущее.

— Окей, лады. А что это?

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

Введение

Обрабатывать пользовательский ввод может быть не так просто, как кажется. Мы же не хотим отправлять запросы на сервер пока пользователь всё ещё набирает свой запрос? И, конечно же, пользователь должен всегда видеть результат на последний запрос, который он отослал.

Существуют разные способы реагирования на интерактивные события в React приложениях, и, по моему мнению, реактивный подход (благодаря таким библиотекам, как RxJS или Bacon) — один из самых лучших. Вот только для того, чтобы использовать RxJS и React одновременно, Вам придётся иметь дело с жизненным циклом React компонента, вручную управлять подписками на потоки и так далее. Хорошая новость — всё это можно делать автоматически с помощью RxConnect — библиотеки, разработанной в процессе миграции с Angular на React в ZeroTurnaround.

Здравствуйте, меня зовут Дмитрий Карловский и я… состоятельный человек. У меня есть состояние на сервере, есть состояния в локальных хранилищах, есть состояние окна браузера, есть состояние доменной модели, есть состояние интерфейса. И всё это многообразие состояний нужно поддерживать синхронизированным. Если одно состояние как-то изменяется, то остальные связанные с ним состояния должны как можно скорее обновиться. Особую пикантность ситуации придаёт то, что синхронизация с сервером может занимать секунды, а блокировать пользовательский интерфейс можно лишь на доли секунд.

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

Как известно, клиенты Tinkoff.ru видят перед собой не отделение банка, а интерфейс сайта или мобильного приложения — так что для компании две эти вещи особенно важны. О мобильной разработке мы её недавно уже расспрашивали. А теперь в преддверии конференции HolyJS, где разработчик Tinkoff.ru Алексей Носов выступит с докладом, задали вопросы о JS/фронтенде: и самому Алексею, и руководителю HR-проектов компании Ольге Шпунтенко.

Представляю вашему вниманию типичные варианты использования Observable объектов в компонентах и сервисах Angular 4.

Подписка на параметр роутера и мапинг на другой Observable

Задача: При открытии страницы example.com/#/users/42, по userId получить данные пользователя.

Решение: При инициализации компоненты UserDetailsComponent мы подписываемся на параметры роутера. То есть если userId будет меняться — будер срабатывать наша подписка. Используя полученный userId, мы из сервиса userService получаем Observable с данными пользователя.

// UserDetailsComponent

ngOnInit() {
  this.route.params
    .pluck('userId') // получаем userId из параметров
    .switchMap(userId => this.userService.getData(userId))
    .subscribe(user => this.user = user);
}

Веб в наши дни двигается очень быстро и мы все это знаем. Сегодня Реактивное Программирование является одной из самых горячих тем в веб-разработке и с такими фреймворками, как Angular или React, она стала гораздо более популярной, особенно в современном мире JavaScript. В сообществе произошел массовый переход от императивных парадигм программирования к функциональным реактивным парадигмам. Тем не менее, многие разработчики пытаются с этим бороться и часто перегружены его сложностью (большой API), фундаментальным сдвигом в мышлении (от императивного к декларативному) и множеством понятий.

Хотя это не самая простая тема, но как только мы сумеем ее понять, мы спросим себя, как мы могли без нее жить?

Несколько месяцев назад я наткнулся на интеллектуальную ЭЭГ-гарнитуру с поддержкой Bluetooth и тут же увидел её потенциал в некоторых крайне интересных областях. А именно, эта гарнитура и Web Bluetooth вполне могли позволить напрямую связать мой мозг с веб-страницами.



ЭЭГ, или электроэнцефалография — это способ мониторинга электрической активности мозга. Обычно при ЭЭГ-исследовании на поверхности головы размещают несколько электродов, которые затем регистрируют электрические явления, сопутствующие работе мозга. Результаты регистрации записывают в виде электроэнцефалограмм. Мне идея поэкспериментировать с этими данными показалась очень интересной. Обычно ЭЭГ применяют в медицинских целях, но в последнее время стали появляться проекты, предусматривающие новые способы использования данных об электрической активности мозга.

Один из таких проектов — Muse. Его создатели продают, примерно за $250, систему, которая обучает медитации. В её состав входит отлично сделанная ЭЭГ-гарнитура, которая поддерживает Bluetooth. Хотя Muse должна обучать тому, как успокаивать разум, мой разум успокоился только после того, как я понял, как мне работать с данными от гарнитуры в веб-браузере.

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

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

Два наиболее популярных решения это ngrx/store, вдохновленной по большей части Redux, и Observable сервисы данных.

Лично мне очень нравится Redux, и он стоит каждой строчки бойлерплейт кода. Но, к сожалению, некоторе со мной могут не согласиться или Redux не особо применим в их приложениях.

Поэтому я решил поведать вам, как может пригодится Mobx, в решении проблемы управления состоянием. Идея заключается в том, чтобы объединить два мира, Redux и Mobx.

В этом материале мы поделимся с вами переводом интервью с руководителем проекта RxJS 5+, инженером Google Беном Лешем.

В огромном мире фронтенд-разработки существует множество интересных инструментов. Я стремлюсь найти правильный подход к изучению практических вещей, поэтому я решила пообщаться с одним из самых ярких представителей RxJS-сообщества, Беном Лешем. Мне хотелось побольше узнать о RxJS, и о том, почему мне, начинающему разработчику, стоит вложить время в изучение реактивного программирования. Кроме того, мне хотелось понять — зачем применять RxJS в моих проектах. Бен рассказал мне о том, как использовать RxJS и поделился советами, касающимися изучения этой технологии.

Введение

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

Я подразумеваю, что, читая эту публикацию, вы хорошо знаете ReactJS и, хотя бы, представляете суть RxJs. Я не буду использовать Redux в примерах, но все, что будет написано ниже, прекрасно проецируется и на связку React + Redux.

Привет, Хабр! Представляю вашему вниманию перевод статьи "RxJS: Don’t Unsubscribe" автора Ben Lesh.

Ну… ладно, просто не отказывайся от подписок.

Я часто помогаю кому-нибудь в отладке проблем с их RxJS кодом, в том числе со структурированием приложений, которые несут в себе много асинхронного кода. При этом я всегда вижу одно и тоже, как люди держат обработчики на тоннах подписок. Разработчик делает 3 HTTP-запроса с Observable, сохраняя 3 объекта подписки, которые будут вызваны, когда произойдет какое-то событие.

Я знаю, почему так происходит. Люди привыкли использовать `addEventListener` N раз, а затем, когда они больше не нужны, вызывать `removeEventListener` N раз. Естественным будет делать то же самое и с объектами-подписками, и по большей части вы будете правы. Но есть и лучшие способы. Сохранение слишком большого количества объектов подписок — это знак того, что вы управляете своими подписками императивно и не пользуетесь преимуществами Rx.

Нынешний апрель был, конечно, не самым удачным месяцем для чтения о добром и вечном; все в мыле носились за разбушевавшимся РКН и клеили побитые блюдца. Однако жизнь за пределами зоны его ответсвенности не останавливалась. Наш фронтенд-разработчик Максим Попов даже в самый разгар боевых действий отслеживал интересные новости по Angular и делился ими с коллегами. Кроме того, он отсмотрел доклады прошедшей ng-conf и подготовил подборку наиболее ценного. С его любезного разрешения делюсь этой информацией с Хаброй — будет что почитать и, главное, посмотреть в длинные выходные.

Для тех, кто в длинные выходные готов не только кушать шашлык, но и читать всякие нужные тексты, я собрал десятку майских ссылок из канала разработчиков Vimbox в корпоративном Слаке Skyeng. Как и в прошлый раз, подборка сконцентрирована вокруг фреймворка Angular и будет интересна работающим с ним программистам.

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

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

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

Введение

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

Прошло уже достаточно времени с выхода обновленного Angular. В настоящее время множество проектов завершено. От "getting started" множество разработчиков уже перешло к осмысленному использованию этого фреймворка, его возможностей, научились обходить подводные камни. Каждый разработчик и/или команда либо уже сформировали свои style guides и best practice либо используют чужие. Но в тоже время часто приходится сталкиваться с большим количеством кода на Angular, в котором не используются многие возможности этого фреймворка и/или написанного в стиле AngularJS.

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