FRP
Functional Reactive Programming Week 2- Как работать с состоянием в реактивной системе? Поддержка состояния Изменение состояния Как работать с состоянием в реактивных системах? Мы рассмотрим функции, которые позволяют работать с изменяемым состоянием.
Объект имеет состояние если и только если его текущее поведение зависит от истории.
Операционная эквивалентность = невозможно разработать тест, который позволяет различить две сущности. Если есть две сущности, произвольные последовательности операций над всегда ними приводят к одинаковому результату, то такие сущности являются операционно эквивалентными.
FPR - это архитектура обработки событий. Традиционно под обработкой событий понималось назначение метода обработки события и вызов его каждый раз, когда происходило это событие. В FPR событие рассматривается как функция прозводящая из момента времени какое-то состояние. Например, при движении мыши этим состоянием будут координаты мыши в текущий момент времени. В FPR событие моделируется как сигнал Signal[ event time => state]
У сигналов есть две фундаментальыне операции: получить значение сигнала (последнее сгенерированное состояние) Конструктор сигнала, который позволяет определить один сигнал в терминах другого сигнала. Константный сигнал - производит одно и то же значение. Переменный сигнал - значение сигнала может изменяться с течением времени. Имеет метод update.
Сигналы с переменными значениями имеют одно критическое отличие - если значение сигнала, зависит от значения другого сигнала, то значение второго сигнала автоматически обновляется при значени первого.
Why is reactive programming? Современные системы становятся все более реактивными.
Реактивное программирование строится на основе функционального.
Это набор моделей и подходов которые стали популярны в последние несколько лет. В связи с увеличением всех параметров (количество серверов, вычислительных узлов, количества данных, уровня доступности) возникают новые требования к решения.
Решения предыдущего поколения, такие как Enterprise Java состоящие из серверов и контейнеров уже не являются адекватными ситуации.
Современные - реактивные приложения (reactive applications). Реактивный - готовый отвечать на события. event-driven - react to events scalable - react to load. An application is scalable if it is able to be expanded according to its usage. scale up - использование параллелизма и множества ядер. scale out - использование множества узлов сервера. Самое важное для масштабирования: shared mutable state -> min resilient - react to failures. An application is resilient if it can recover quickly from failures (software failures, выброс исключений, hardware failures, connection failures). Typically, resilience cannot be added as an afterthought; it needs to be part of the design from the beginning. Важные методы: loose coupling. strong encapsulation of state. pervasive supervisor hierarchies. модульность, комбинируемость модулей. responsive - react to users. An application is responsive if it provides rich, real-time interaction with its users even under load and in the presence of failures. Responsive applications can be built on an event-driven, scalable, and resilient architecture.
Важжны все характеристики:: их совместная комбинация позволяет добится реактивного поведения.
Реактивная система: система полученая путем объединения слабо-связанных обработчиков событий. Отдельные обработчики событиый слабо возаимодействуют друг с другом, в связи с чем эффективно используются ресурсы и возможен параллелизм. Система становится все более и более масштабируемой.
В целом, реактивные системы - это как раз те эталонные системы о которых я думал как же их сделать.
Традиционно, обработка событий выполнялась при помощи паттерна Observer и его вариайий (Event Listener) при помощи call-backов. needs shared mutable state. Т.к. изменяется состояние, то в системе имеются побочные эффекты. Обработчики требуют разделяемого состояния, что очень плохо. cannot be compose. Из обработчиков событий сложно сложить абстракции верхнего уровня. call-back hell. Сложно понять что на что влияет и очень скоро можно запутаться в изменениях состояния.
Как сделать лучше? Можно использовать принципы и фундаментальные конструкции из функционального программирования для создания комбинируемых систем обработки событий. Events are first class. Events are often represented as a message. Handlers of events are also first class. Complex handlers can be composed from the primitive one.
Карта курса: Обзор функционального программирования. Монады Stateful Futures - абстракции над событиями Observables - абстракции над события. Actors - архитектура обработки событий Supervisors - метод обработки отказов. Distributed Actors - масштабирование и распределенные системы. Традиционные конкуррентные системы содержат множество потоков, которые сообщаются друг с другом посредством разделяемого состояния.
Современные системы конкуррентной обработки событий содержат слабо связанные обработчики событий, что позволяет обрабатывать события асинхронно, без блокировок.
Functions and Pattern Matching Присваивание в for-comprehesion является фильтром по умолчанию.
for(val x:T+ <- Expr:Coll[-X]) выберет из коллекции Expr некоторого супертипа X- все элементы со значением конкретного подтипа X+. Значения остальных типов будут проигнорированы.
self => синоним для this.
RxJS
https://blog.wakanda.io/reactive-programming-operators/ https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
https://glebbahmutov.com/blog/journey-from-procedural-to-reactive-javascript-with-stops/
Last updated
