$mol_atom: теорія і практика реактивності

Привіт, мене звати Дмитро Карлівський і я… заможна людина. У мене є стан на сервері, стану в локальних сховищах, є стан вікна браузера, є стан доменної моделі, є стан інтерфейсу. І все це різноманіття станів потрібно підтримувати синхронізованим. Якщо один стан змінюється, то інші пов'язані з ним стани повинні як можна швидше оновитися. Особливу пікантність ситуації надає те, що синхронізація з сервером може займати секунди, а блокувати користувальницький інтерфейс можна лише на частки секунд.
Заможна людина
Далі ви дізнаєтеся: як реактивність перемагає асинхронність, як імперативна реактивність уживається з функціональної, як прості абстракції дозволяють писати надійний і швидкий код, а також як одного разу я перейшов на идемпотентную сторону сили і все заверте
Читати далі →

RxConnect — коли React зустрічає RxJS

Цей переклад є російськомовною інтерпретацією документації, яку я сам і написав, тому не соромтеся задавати питання.
Введення
Обробляти користувальницький введення може бути не так просто, як здається. Ми ж не хочемо відправляти запити на сервер, поки користувач все ще набирає свій запит? І, звичайно ж, користувач повинен завжди бачити результат на останній запит, який він відіслав.
Існують різні способи реагування на інтерактивні події в React додатках, і, на мою думку, реактивний підхід (завдяки таким бібліотек, як RxJS або Bacon) — один з найкращих. Ось тільки для того, щоб використовувати RxJS і React одночасно, Вам доведеться мати справу з життєвим циклом React компонента, вручну керувати підписками на потоки і так далі. Хороша новина — все це можна робити автоматично з допомогою RxConnect — бібліотеки, розробленої в процесі міграції з Angular на React в ZeroTurnaround.

Читати далі →

it's the future

Цей пост просто жарт і не намагається виставити інструменти, згадані тут, в поганому світлі. Я використовую їх постійно, вони прекрасні, і я рекомендую їх використовувати. За мотивами it's the future @ CircleCI Blog
— Гей, я б хотів навчитися писати круті веб-додатки. Чув, у тебе є досвід.
— Так, я якраз займаюся фронтендом, юзаю пару тулз.
— Круто. Я зараз роблю просте додаток — звичайний TODO-лист, використовуючи HTML, CSS і JavaScript, і планую заюзать JQuery. Це норм?
— Не-не-не. Це олдскул. Джиквери мертвий — ніхто не використовує його тепер! Тобі потрібен React. Це майбутнє.
— Окей, лади. А що це?

Читати далі →

Розпізнаємо коди Морзе з використанням Rx.js



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

Читати далі →

Використання RxJs для зв'язування компонентів програми

Способи «спілкування» компонентів

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

Перше, що приходить в голову, це публікація і підписка на іменовані події. Один з компонентів посилає подія в «ефір», а інші слухають цей «ефір» і ловлять ті повідомлення, які їм потрібні. Ідея гранично проста і давно добре себе зарекомендувала.

image

Це чимось нагадує WI-FI в кафе, коли всі можуть обмінюватися повідомленнями з усіма, але при цьому є роутер (диспетчер), який забезпечує існування «ефіру» і віддає повідомлення тільки тим, кому вони адресовані.

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

Читати далі →

Kefir.js - нова бібліотека для функціонального реактивного програмування (FRP) в JavaScript

Напевно багато хто вже чули про підхід 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 дозволяє писати велику частину коду на «чистих функції» і управляти потоком даних явно (з допомогою потоків подій), а стану зберігати теж явно в Property.


Читати далі →