Полгода назад я написал статью «Observable — удобный state-manager». Это была скорее заметка, из-за чего мне немного досталось в комментариях. Данная статья — более подробное знакомство с Observable — библиотекой для реактивного программирования на JavaScript.

Преимущества Observable

• Маленький размер (3.2 kB)
  Действительно маленький, а не «малое ядро», которое бесполезно без дополнительных модулей, увеличивающих итоговый размер.

• Работает и с объектами, и с классами
  Для классов не накладывает никаких ограничений: можно использовать приватные свойства, наследование и другие возможности.

• Нет зависимостей
  Observable — framework agnostic. Он лишь добавляет реактивность в ваш JavaScript.

• Минимум бойлерплейта
  Убедиться в удобстве Observable с точки зрения Developer Experience можно в примерах с кодом из прошлой заметки или на observable.ru.

• А также...
  Автобатчинг, автотрекинг зависимостей, автобинд, вычисляемые свойства (computed properties), наблюдаемые коллекции (observable Set, Map, Array), глубоконаблюдаемые объекты (deep observables).

Классический счетчик на React с Observable занимает всего 15 строк кода:

import { makeObservable, observer } from 'kr-observable';

// Состояние счетчика можно менять откуда угодно, и компонент перерендерится
const counter = makeObservable({ count: 0 });

function App() {
  return (
    <div>
      <button onClick={() => ++counter.count}>-</button>
      <div>{counter.count}</div>
      <button onClick={() => --counter.count}>+</button>
    </div>
  )
}

export default observer(App);

Чтобы показать остальные преимущества, нужно сравнение с другими решениями. Сравнивать будем по нескольким параметрам: размер, потребление памяти, производительность и сама «реактивность».

Для начала обратимся к js-framework-benchmark. Подробнее ознакомиться с методикой измерений этого бенчмарка можно в его описании. Для нас он удобен тем, что позволяет сравнить несколько решений, работающих в одинаковых условиях. Мы возьмем те, что работают с React.js.

Важно отметить, что среди доступных решений:

• Не все являются агностиками — многие завязаны на хуках React;

• Только два решения — MobX и Observable — работают на "автопилоте", то есть умеют самостоятельно отслеживать зависимости, подписываться и отписываться.

Размер

Observable в общем зачете на четвертом месте, что достаточно неплохо. Но есть нюанс. Давайте вооружимся парой инструментов и разберемся.

Возьмем bundlephobia.com и bundlejs.com. Наша цель — вычесть из общего размера решения размер библиотеки и размер React, чтобы получить чистый объем кода задачи.

import { createRoot } from 'react-dom/client';

const container = document.getElementById('main');
const root = createRoot(container);
root.render({});

На bundlephobia.com смотрим размер двух библиотек для сравнения: Zustand и Observable:

• kr-observable 2.0.0 — 3.2 kB

• zustand 5.0.2 — 0.6 kB

Копируем реализации на Zustand и Observable, вставляем в bundlejs.com и получаем общий размер:

• zustand — 60.1 kB

• kr-observable — 62.3 kB

Применяем нашу формулу: (общий размер) - (размер React) - (размер библиотеки)

• zustand = 60.1 - 58.3 - 0.6 = 1.2 kB

• kr-observable = 62.3 - 58.3 - 3.2 = 0.8 kB

То есть, чтобы решить задачу с использованием Zustand, пришлось написать на 50% больше кода, чем с Observable. В этом и заключается нюанс. Сам по себе маленький размер бесполезен, если он компенсируется бойлерплейтом.

Производительность

По производительности Observable также на четвертом месте.

Проведем еще один небольшой, синтетический тест, сравнив Vue, MobX и Observable - библиотеки с наиболее схожим API. Суть проверки проста: создаем наблюдаемый объект, изменяем одно свойство и считываем оба значения. Результат печатаем в консоль, чтобы JIT не хулиганил:

for (let i = 0; i < 1000; i++) {
  const obj = makeObservable({ a: i, b: i });
  obj.a += 1;
  console.log(obj.a + obj.b);
}

Оба бенчмарка показывают, что удобство, и хороший Developer Experience в Observable достигается не в ущерб производительности.

Потребление памяти

С потреблением памяти тоже все хорошо. Zustand, например, потребляет на 6% больше, а Redux – на 38%.

Даже без учёта уменьшения бандла (за счёт сокращения бойлерплейта), переход с Redux на Observable повышает производительность на 20% и снижает потребление памяти на 38%. Масштабируя это на несколько миллионов приложений использующих Redux, выигрыш для их пользователей был бы значительным.

Реактивность

Оценить "реактивность" сложнее, чем размер или потребление памяти, но, к счастью, есть и такой инструмент.

Какие аспекты реактивности учтены в тесте:

• Batch Changes — возможность обновить несколько состояний разом

• Order Independent — порядок изменений не влияет на пересчет

• Ignore Unrelated — изменение независимых данных не вызывает пересчет

• Collapse Double — отсутствие лишних вычислений

• Skip Untouched — если зависимость не нужна, она не вычисляется

• Skip Redundant — если новое значение эквивалентно предыдущему

• Reuse Moved — изменение порядка обращений не вызывает пересчет

• Single Source — множественные подписки не ведут к множественным вычислениям

• Effect Once — побочный эффект выполняется один раз на изменение

Более подробно с этим можно ознакомиться в Big State Managers Benchmark.

Если система реактивности соответствует критериям, в консоли мы должны увидеть "H" и "EH". Чем больше букв в консоли – тем хуже. Из 29 библиотек только 7 справляются с этой задачей, а 22 других (например, RxJS, Redux, SolidJs, Effector) — нет.

Тот же RxJS, который показывает отличные результаты в js-framework-benchmark, катастрофически плохо справляется с тестом на реактивность – его результаты выглядят как HEEEHFHEEHFF и HEEEHFHJHEHEHHFHJF.

Observable входит в топ и проходит тест с H и EH.

Безопасность и предсказуемость

Еще одно преимущество Observable — он терпимо относится к ошибкам. Не токсик, короче ?

Например, рассмотрим код с типичной ошибкой: наблюдаемое значение изменяется внутри эффекта.

import { reactive, watch } from 'vue';

const state = reactive({ count: 0 });

watch(
  () => state.count,
  () => console.log('effect', state.count = state.count + 1)
);

state.count += 1; // увеличиваем count

При выполнении этого кода Vue вызовет эффект 102 раза и сгенерирует ошибку.

Observable, напротив, отработает корректно, не выполняя лишних реакций:

import { makeObservable, autorun } from 'kr-observable';

const state = makeObservable({ count: 0 });

autorun(() => console.log('effect', state.count = state.count + 1));

state.count += 1; // увеличиваем count

Observable справляется и с более сложными случаями:

class Test extends Observable {
  a = 0;

  get b() {
    return `computed from ${this.a}`;
  }
  
  change() {
    this.a += 1
  }
}

const $res1 = document.getElementById('res1')
const $res2 = document.getElementById('res2')
const $btn1 = document.querySelector('button')

$btn1.onclick = foo.change;

autorun(() => {
  foo.a += 1
  $res1.innerText = `${foo.a} | ${foo.computed}`;
});

autorun(() => {
  $res2.innerText = `${foo.a} | ${foo.computed}`;
})

Что здесь происходит:

• Есть свойство a со значением 0.

• Есть computed свойство b, которое вычисляется при изменении a.

• Первый autorun зависит от a и от b , и должен срабатывать при их изменении. Но при срабатывании он изменяет свойство a снова.

• Второй autorun также зависит от a и от b .

autorun – регистрирует функцию, которая будет немедленно вызвана один раз, а затем – каждый раз, когда изменяется любое из отслеживаемых значений.

При выполнении этого кода:

1. Сначала сработают оба autorun, и значение a станет 1.

2. Далее при каждом нажатии на кнопку значение a будет увеличиваться на 2:

   • Один раз в методе change,

   • Второй раз в первом autorun.

3. При этом оба autorun будут выполняться по одному разу на каждое нажатие кнопки. Демо на codepen.io

То есть Observable корректно и без лишних эффектов обработал ситуацию, в которой другие решения сломались бы из-за переполнения стека.

Или другой пример – случайно зарегистрируем одну реакцию несколько раз:

import { reactive, watch } from 'vue';

let called = 0;
const state = reactive({ count: 0 });
const getter = () => state.count;
const effect = () => console.log('effect', state.count, ++called);

for (let i = 0; i < 10; i++) {
  watch(getter, effect);
};

state.count += 1; // увеличиваем count

При выполнении этого кода Vue вызовет эффект 10 раз, и не почувствует подвоха.

Observable, напротив, отработает корректно, не выполняя лишних реакций:

import { makeObservable, autorun } from "kr-observable";

let called = 0;
const state = makeObservable({ count: 0 });
const effect = () => console.log('effect', state.count, ++called);

for (let i = 0; i < 10; i++) {
  autorun(effect);
};

state.count += 1; // увеличиваем count

Еще один пример – потеря контекста:

const state = someReactiveObjectFactory({
  value: '',
  onChange(event) {
    this.value = event.target.value;
  },
  doSomething() {
    console.log(this)
  }
});

input.addEventListener('change', state.onChange);

setTimeout(state.doSomething);

На что ссылается this в методе onChange, на input или state? Что произойдет при вызове, если свойство value есть и у input и у state? На что ссылается this в setTimeout?

В Observable нет такой проблемы, this всегда ссылается на state, если только мы намеренно не переопределим его с помощью call, bind или apply.

const state = makeObservable({ 
  doSomething() { 
    console.log(this);
  }
});

const { doSomething } = state

queueMicrotask(state.doSomething) // state
queueMicrotask(doSomething) // state

setTimeout(state.doSomething) // state
setTimeout(doSomething) // state

input.addEventListener('change', state.doSomething); // state
input.addEventListener('change', doSomething); // state

Простое API

Есть два способа создать наблюдаемый объект

import { makeObservable, Observable } from 'kr-observable'

const foo = makeObservable({
  // ...
})

class Foo extends Observable {
  // ...
}

Наблюдатели – autorun, subscribe и listen

import { autorun, subscribe, listen } from 'kr-observable'

autorun(effect);

subscribe(foo, callback, keys);

listen(foo, callback)

HOC observer для React

import { observer } from 'kr-observable'

function Component() {}

export default observer(Component)

А также низкоуровневый API для интеграций. На нём, например, реализован упомянутый выше HOC для React. Это API пока не экспортируется наружу, но появится в одном из следующих релизов — как только допишу соответствующий раздел в документации.

Всё это делает Observable простым, удобным, но мощным решением для реактивности. А state-менеджмент — лишь одно из возможных применений.

Полезные ссылки

• Подробная документация

• GitHub

• NPM

Спасибо всем, кто так или иначе внёс свой вклад в развитие Observable — будь то ценные комментарии или практическая помощь: @DmitryKazakov8, @Alexandroppolus, @clerik_r, @nin-jin, @supercat1337