В реактивных системах существуют специальные функции, такие как watchEffect во Vue или autorun в MobX, которые умеют автоматически отслеживать зависимости и перезапускать «эффект» при их изменении. Принцип их работы следующий:

1. Регистрация эффекта
   Функция принимает другую функцию (так называемый «эффект») и сразу её выполняет.

2. Трекинг зависимостей
   Во время выполнения эффекта система фиксирует все обращения к реактивным свойствам и подписывается на их изменения.

3. Перезапуск
   При изменении любого наблюдаемого значения эффект выполняется заново, и процесс повторяется бесконечно, пока эффект не будет явно остановлен.

Это похоже на useEffect в React-е, только вместо того, чтобы требовать явного указания зависимостей, система определяет их автоматически. Такой подход создаёт мощный и удобный механизм, но имеет свои ограничения.

1. Нельзя мутировать наблюдаемые значения внутри эффекта
   Изменение наблюдаемого значения внутри эффекта приводит к бесконечному циклу и переполнению стека (эффект изменяет значение → вызывает перезапуск → снова изменяет значение и т.д.).

2. Зависимости отслеживаются синхронно
   Переданный в качестве аргумента «эффект» может быть как синхронной, так и асинхронной функцией, но autorun/watchEffect могут определить только те наблюдаемые значения, к которым произошло обращение во время синхронной части выполнения эффекта:

   // MobX
   autorun(() => {
     fetch(url)
       .then(() => {
         // обращение к state.value невидимо для autorun-а
         if (state.value) { /.../ } 
       })
   })
   
   // Vue
   watchEffect(async () => {
     await fetch(url);
     // обращение к state.value невидимо для watchEffect-а
     if (state.value) { /.../ }
   })

Фундаментальные ограничения

На первый взгляд, эти ограничения кажутся непреодолимыми, они же заложены в самой природе языка, а не в конкретных реализациях реактивности. И всё же, мне удалось обойти первое ограничение.

Я обратил внимание на Proxy, где каждый метод в хэндлере по сути является эффектом. Когда мы изменяем значение внутри set-тера — всё работает. Если такой подход работает там, почему бы не попробовать применить его в реактивной системе? Оказалось — можно! Я реализовал это в библиотеке Observable. Она позволяет изменять наблюдаемые значения внутри эффектов без переполнения стека и лишних перезапусков (подробности здесь).

После этого мне стало любопытно: а можно ли обойти второе ограничение? Не потому что это критически важно, а из чистого любопытства. Насколько глубоко можно переосмыслить механизм реактивности? Как далеко мне удастся зайти, прежде чем упрусь в непреодолимые ограничения рантайма? Спойлер – не все так безнадежно.

Отслеживаем зависимости в асинхронном коде

Итак, у нас есть такой интерфейс:

// autorun возвращает функцию dispose для остановки эффекта
type Disposer = () => void;

// эффект может быть синхронной или асинхронной функцией
type Effect = () => void | Promise<void>;

// сам autorun: принимает эффект и возвращает disposer
type autorun = (effect: Effect) => Disposer;

Задача – отслеживать зависимости в том числе во время выполнения асинхронной части эффекта.

Мы могли бы обернуть эффект в Promise, но это сломает синхронный код. Если эффект синхронный, он должен выполняться синхронно. Значит, первое, что нам нужно сделать — определить тип эффекта и выполнять его по-разному в зависимости от того, синхронный он или асинхронный. Это можно сделать так:

const isAsync = effect.constructor.name === 'AsyncFunction';

Это работает для всех асинхронных функций, кроме асинхронных генераторов. У них тип AsyncGeneratorFunction, но autorun изначально не поддерживает генераторы поэтому нас все устраивает.

Теперь зная тип эффекта, мы можем выбирать соответствующую стратегию для его выполнения. Что-то вроде этого:

function autorun(effect) {
  if (effect.constructor.name === 'AsyncFunction') {
    await effect();
  } else {
    effect();
  }
}

Но работать это не будет. Рассмотрим простой пример:

autorun(
  // асинхронный эффект запустится при создании
  async function asyncEffect() {
    // дожидаемся промиса
    await new Promise(resolve => setTimeout(resolve));
    console.log(state.value);
  }
)

autorun(
  // синхронный эффект
  function syncEffect() {
    console.log(otherState.value);
  }
)

В этом примере синхронный эффект второго autorun выполнится в то время, пока мы ожидаем разрешения промиса внутри асинхронного эффекта первого autorun. Из-за этого первый autorun может ошибочно подписаться на зависимость из второго эффекта (otherState.value), что приведёт к некорректному поведению реактивной системы.

Однако такая проблема возникает не только в асинхронном коде, но и в синхронном — например, при рендере вложенных компонентов в React:

function Componen1() {
  return <span>{state.value}</span>
}

function Component2() {
  return (
    <div>
      <span>{otherState.value}</span>
      <Componen1 />
    </div>
  )
}

В этом примере Component2 может ошибочно подписаться на зависимость, которая на самом деле относится к Component1. В библиотеке Observable эта проблема решена благодаря опоре на модель выполнения JavaScript: executor использует стек LIFO, что позволяет корректно отслеживать контекст выполнения. Но и этого не всегда достаточно: конфликт всё равно может произойти, если два асинхронных эффекта запустятся одновременно:

autorun(
  async () => {
    await new Promise(resolve => setTimeout(resolve));
    console.log(state.value);
  }
)

autorun(
  async () => {
    await new Promise(resolve => setTimeout(resolve));
    console.log(otherState.value);
  }
)

Если вы ознакомились с этой статьёй и библиотекой Observable в целом, то, возможно, заметили, что в ней практически отсутствует собственный DSL. Это не случайность — такова философия библиотеки. Мне хотелось, чтобы она была максимально нативной и предсказуемой. Для решения проблемы из приведённого выше примера я также стремился найти простой и предсказуемый подход — и он нашёлся!

Что будет напечатано в консоль?

Вспомните одно из своих собеседований — велика вероятность, что там был похожий вопрос. Обычно он сопровождается примерно таким кодом:

console.log('start');
fetch('google.com').then(() => console.log('data'));
console.log('end');

Промисы уже давно стали частью повседневного инструментария разработчика, и сегодня любой опытный JavaScript-программист без раздумий ответит: в консоли будет выведено start, затем end, и только потом — data. А типичное исправление для синхронного поведения будет выглядеть так:

console.log('start');
await fetch('google.com').then(() => console.log('data'));
console.log('end');

Именно эту стратегию я и применил для решения описанной выше проблемы — использовать await. Просто и предсказуемо:

await autorun(
  async () => {
    await new Promise(resolve => setTimeout(resolve));
    console.log(state.value);
  }
)

await autorun(
  async () => {
    await new Promise(resolve => setTimeout(resolve));
    console.log(otherState.value);
  }
)

Чтобы сделать использование более удобным, добавим немного магии через TypeScript. С помощью перегрузок функций мы добьёмся того, чтобы редактор сам подсказывал: если эффект асинхронный — не забудь про await.

function autorun(effect: () => Promise<void>): Promise<() => void>;
function autorun(effect: () => void): () => void;

Результат

Я приведу здесь лишь три из 36 тестов, которые проверяют корректность работы этого механизма. Все тесты можно посмотреть в репозитории библиотеки на GitHub.

it('tracks across multiple awaits', async () => {
    const m = makeObservable({
      a: 1,
      b: 2
    });
    const logs = [];

    await autorun(async () => {
      await Promise.resolve();
      logs.push(`a=${m.a}`);
      await Promise.resolve();
      logs.push(`b=${m.b}`);
    });

    m.a = 10;
    m.b = 20;
    await new Promise(r => setTimeout(r, 10));

    assert.deepStrictEqual(logs, ['a=1', 'b=2', 'a=10', 'b=20']);
  });

it('isolates dependencies between different observable classes', async () => {
    class A extends Observable { value = 1 }
    class B extends Observable { value = 2 }

    const a = new A();
    const b = new B();
    const aLogs = [];
    const bLogs = [];

    await autorun(async function foo() {
      await new Promise(r => setTimeout(r));
      aLogs.push(a.value);
    });

    await autorun(async function bar() {
      await new Promise(r => setTimeout(r));
      bLogs.push(b.value);
    });
    
    a.value = 10;
    b.value = 20;
    await new Promise(r => setTimeout(r, 10));

    assert.deepStrictEqual(aLogs, [1, 10]);
    assert.deepStrictEqual(bLogs, [2, 20]);
  });

it('tracks independent sync/async autoruns without conflicts', async () => {
    class User extends Observable { name = 'Alice' }
    class Product extends Observable { price = 100 }

    const user = new User();
    const product = new Product();
    const userLogs: string[] = [];
    const productLogs: string[] = [];

    // Sync autorun tracking user.name
    const disposeSync = autorun(() => {
      userLogs.push(`SYNC: ${user.name}`);
    });

    // Async autorun tracking product.price
    const disposeAsync = await autorun(async () => {
      await Promise.resolve();
      productLogs.push(`ASYNC: ${product.price}`);
      await delay(50);
      productLogs.push(`ASYNC (late): ${product.price}`);
    });

    // Initial state verification
    assert.deepStrictEqual(userLogs, ['SYNC: Alice']);
    assert.deepStrictEqual(productLogs, ['ASYNC: 100', 'ASYNC (late): 100']); // Async hasn't resolved yet

    await delay(10); // Let async autorun start

    // Make changes
    user.name = 'Bob';
    await delay(10);
    product.price = 150;
    await delay(100); // Wait for all async operations

    // Verify isolation
    assert.deepStrictEqual(userLogs, [
      'SYNC: Alice',
      'SYNC: Bob'  // Only reacted to user change
    ]);

    assert.deepStrictEqual(productLogs, ['ASYNC: 100', 'ASYNC (late): 100', 'ASYNC: 150', 'ASYNC (late): 150']);

    // Cleanup
    disposeSync();
    disposeAsync();
  });

Разумеется, это решение не идеально. На данный момент оно умеет отслеживать зависимости в асинхронных эффектах с несколькими await или цепочками then, если эффект возвращает промис:

await autorun(async function() {
  return fetch('habr.com')
   .then(() => state.value) // отследит
   .then(() => otherState.value) // отследит
})

А вот с таймаутами или интервалами уже проблема — зависимости внутри них он отследить не может:

await autorun(async function() {
  setTimeout(() => {
    state.value // невидимо для autorun-а
  })
})

Но умеет отслеживать зависимости внутри queueMicrotask:

await autorun(async () => {
  await fetch('google.com')
  queueMicrotask(() => {
    console.log(m.value) // отследит
  });
});

Заключение

Эксперимент показывает, что даже в асинхронных сценариях можно добиться частичной автоматизации трекинга зависимостей.

Полный код библиотеки Observable и все тесты доступны на GitHub. Если у вас есть идеи, как улучшить этот механизм, — welcome to contributions! Этот функционал доступен только в бета версии 3.0.10-beta.2

Буду признателен, если поделитесь мыслями в комментариях или предложите новые тесты.