CSP срещу RxJS: какво не знаеш.

Какво се случи с CSP?

Снимка от Джеймс Понд на Unsplash

Вероятно сте щракнали върху тази статия, мислейки „какво е CSP?“ Той съобщава последователни процеси. Все още сте объркани?

CSP е метод за комуникация между различни функции (генератори) във вашия код чрез споделен канал.

Какво в света означава това? Казвам го направо. Има тази концепция за канал. Мислете за това като на опашка. Можете да поставите неща върху него и да ги свалите.

Така че с две функции можете да имате едно добавяне на неща на канала (производител) и друго издърпване на неща и вършене на някаква работа (потребител).

Типичен случай за разширена употреба биха били множество производители и един потребител. По този начин можете да контролирате данните, които получавате, но можете да имате много неща, които ви ги дават.

За разлика от RxJS, тези канали са автоматични. Не получавате ценности волно-неволно, трябва да ги поискате.

Използване на CSP

Ето един малък пример на CSP, използващ супер простата (и мъртва) библиотека Channel4:

CSP каналите работят асинхронно. Така че веднага след като това стартира, първо се регистрира синхронното съобщение „ДОСТЪП“. Тогава нашите канали се изпълняват по ред.

Най-интересното за мен е блокиращият (но асинхронизиращ) характер на CSP. Забележете как създадохме третия ход преди да поставим „C“ на канала. За разлика от първите две функции за взимане, третата няма какво да предприеме. След като нещо влезе в канала, веднага го приема.

Също така имайте предвид, че потребителите трябва непрекъснато да свалят нещата от канала, докато този канал се затвори. Ето защо „D“ никога не се записва. Трябва да определите друго вземане, за да вземете следващата стойност от канала.

С наблюдения ви се дават стойности, така че не е нужно да се притеснявате дали ръчно да ги изтеглите. Ако искате да буферирате тези стойности, RxJS предоставя доста методи на тръбопровода за точно тази цел. Няма нужда да използвате CSP.

Цялата концепция зад наблюдението е, че всеки слушател получава едни и същи данни, веднага след като наблюдателят се обади следващия. При CSP това е като подход IxJS, където се занимавате с данни на парчета.

CSP Е СМЪРТ !?

Можете да намерите реализациите на CSP в Go и Closure. В JavaScript всички библиотеки с CSP освен няколко са мъртви и дори тогава тяхната аудитория е малка .

Разбрах за CSP от страхотна беседа на Винченцо Чианес. Той препоръча тази библиотека от висок клас, наречена js-csp. За съжаление, той вече не се поддържа.

Въз основа на казаното от него в разговора си за 2017 г. изглеждаше голяма работа. Той говори за това как датчиците ще избухнат след няколко месеца и как js-csp вече има подкрепа за тях.

Изглежда CSP може коренно да промени начина, по който сте разработили async приложения в JavaScript. Но нищо от това никога не се е случило. Преобразувателите умряха; заменен от библиотеки като RxJS и свръхзащитата около CSP се разтвори.

Винченцо отбеляза как CSP е цяло „по-ниско ниво над обещанията. Той е прав. Силата, която получавате от множество функции, взаимодействащи асинхронно, е невероятна.

Обещанията, поради нетърпеливата си природа, не са дори в един и същи терен. Малко знаеше, че последните няколко библиотеки на CSP ще успеят да подкрепят обещанията под капака .

CSP Алтернатива: Redux-Saga

Ако някога сте използвали Redux-Saga, идеите и концепциите около CSP вероятно звучат познато. Това е така, защото са. Всъщност Redux-Saga е внедряване на CSP в JavaScript; най-популярният досега.

Има дори концепция за „канали“ в Redux-Sagas:
https://github.com/redux-saga/redux-saga/blob/master/docs/advanced/Channels.md

Каналите получават информация от външни събития, буферни действия към магазина Redux и комуникират между две саги. По същия начин се използват в CSP със същите функции за вземане и пускане.

Доста готино да видите действително внедряване на CSP в JavaScript, но странно много малко са го забелязали. Това ви показва колко малко CSP излетя преди да умре.

CSP Алтернатива: Наблюдава се Redux

Може би сте чували за нещо, наречено Redux-Observable Това е подобно понятие на CSP и Redux-Saga, но вместо императивния стил на генераторите, той използва функционален подход и използва RxJS тръбопроводи, наричани "епици".

В Redux-Observable всичко се случва чрез две теми: действие $ и състояние $. Това са вашите канали.

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

Ако искате да изградите опашка в Redux-Observable точно като CSP, това е малко по-сложно, тъй като за тази цел няма оператор, но е напълно възможно.

Създадох отблъскване, което прави точно това:

В сравнение с нашия по-ранен пример за CSP, можете да очаквате това:

Примерът изисква само RxJS и всичко е в един файл за простота. Както можете да видите, много по-трудно е да поставите на опашка елементи в RxJS по същия начин, както бихте могли да използвате и CSP. Напълно възможно е, но изисква много повече код.

Лично аз бих искал да видя как RxJS добавя оператор като буферКогато ви позволява да разкривате отделни елементи вместо целия буфер. Тогава бихте могли да постигнете CSP-стила в Redux-Observable много по-лесно.

заключение

CSP беше страхотна концепция, но в JavaScript е мъртъв. Redux-Saga и Redux-Observable са достойни алтернативи.

Дори и с възможността да се интегрира с преобразувателни библиотеки, RxJS все още има ясен крак нагоре. Масовата общност от преподаватели и производствени приложения затруднява конкуренцията.

Ето защо мисля, че CSP умря в JavaScript.

Още четения

Ако ви е харесало прочетеното, моля, прегледайте и другите ми статии по подобни отварящи поглед теми:

  • Наблюдаван Redux може да реши вашите проблеми с държавата
  • Редокс-забележим без Redux
  • Обратни обаждания: окончателното ръководство
  • Обещания: окончателното ръководство