Наверняка многие уже слышали о подходе 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.
Я не люблю CSS. Он простой и понятный. Это движущая сила Интернета, но он слишком ограниченный и им трудно управлять. Пришло время привести этот язык в порядок и сделать его более полезным, используя динамический CSS при помощи LESS.
