Для начала нужно определиться с базовым понятием реактивности. Тоже много уже копий на этом поломали и каких трактовок только не существует. Тут будет то как я понимаю реактивность.
Реактивность - это свойство системы автоматически поддерживать себя относительно заданных правил. Правила могут быть как для входов, так и для выходов. И в зависимости от того на что рассчитаны правила, то реактивность можно разделить на: ориентированную на реактивное состояние, ориентированная на реактивные процессы(реакции).
Давайте возьмем самый простой пример, который только может быть для описания реактивного состояния.
a = 2
b = 5
c = a + b
что мы здесь видим? у нас есть состояние заданное 3мя ячейками: a/b/c. Если это императивный код, то изменение
a/b не повлечет за собой обновление с. А вот для реактивной парадигмы если оказывается, что с перестал быть равен а + b. Если это произошло, то по сути мы нарушили заданные правила. Такая система не является реактивнойС другой стороны, если мы напишем что-то такое, чтобы обновить
с:a = 10
systemActualize()
то скорее всего внутри
systemActulize произойдет нечто, что заставит обновиться и с. Только вот автоматизма в этом не особо много, так как мы должны вручную следить за обновлениями и вызывать эту функцию. Такая система тоже не является реактивной.Те если система сама следит за изменениями и поддерживает заданные правила, то ее можно считать реактивной. Способов реализации такого великое множество. Стоит заметить, что так как абсолютное большинство языков программирований сами по себе не является реактивными, то каждая реактивная система задает свои правила игры в рамках которой она является реактивной. Это может доходить даже до некоторого подобия DSL для того чтобы указывать правила. С помощью данного подхода мы можем разложить все реактивные системы на различные группы, однако это совершенно отдельная тема.
Это все о реактивном состоянии. Однако, важны и реактивные процессы, которые указывают как одни действия влекут за собой какие-то последствия. Они чуть сложнее. Проще всего их представить на знакомых большинству Event emitter-ах/Event Bus-ах. Те есть некоторая сущность на которую можно подписываться множеству слушателей, и ее можно триггерить. Только чаще всего подписываются не на какое-то событие, а вот прям на сам эффект триггера. Концепция простая, но невероятно мощная если вокруг нее накрутить сверху побольше "мясца". Те такая система будет реактивной, так как она будет автоматически преобразовывать "раздражители" в последствия. Важно, что реактивная система себя показывает в "реальном времени", те это не просто вызов функции. А как создание организма, которое будет реагировать на раздражители. Оставлю как основной пример такого подхода: Rx
Значит ли что если мы реализуем реактивное состояние, то исключаем реактивность процессов. Нет. Но чаще всего библиотеки сосредотачиваются на чем-то одном, а второй элемент оставляют побочным. Например, в Rx удобно описывать процессы, но вот работа с состояниями вызывает затруднения (а особенно, если мы хотим, чтобы код оставался производительным). Обратный пример это реактивная система Vue: в ней легко описывать данные и их соотношения, но вот процессы приходится писать весьма в императивном стиле, реактивные процессы задаются только для прослушивания изменений в данных. Однако, некоторые системы стараются быть одинаково удобны и для данных и для процессов. Такими примерами могут быть Reatom и Effector. (Если вам известны другие такие системы буду рад дополнить). Есть случаи, когда фреймворки просто оставляют 1 систему для данных, другую для процессов (например Angular).
Надеюсь, что в некотором роде прояснил 2 основных подхода к реактивности и с какой стороны их можно рассматривать. На самом деле подходов и тонкостей гораздо больше, но пусть это будет отправной точкой.