Мини-сигналы

Реализуй signal() и effect() с автоматическим отслеживанием зависимостей через глобальную переменную 'currently-executing'. Сигнал хранит значение и множество подписчиков; effect(fn) ставит глобальную в себя, запускает fn, и любой сигнал, прочитанный внутри fn, проверяет глобальную и добавляет эффект в свои подписчики — без явного списка `effect.subscribe(signal)`. Запись сигнала (`signal.value = x`) перезапускает ровно зависимые эффекты. Зависимости динамические: перед каждым перезапуском предыдущее множество подписчиков эффекта очищается, так что сигнал, условно читаемый в одной ветке (например, `if (flag.value) a.value else b.value`), перестаёт запускать эффект, когда эта ветка больше не проходится — без очистки устаревшие подписки вызывают лишние перезапуски и мешают GC пока сигналы живы. Докажи: эффект, читающий сигнал A в ветке true и B в ветке false, отписывается от непроходимой ветки при переключении условия, тест где сигнал перестают читать перестаёт запускать эффект.

Добавь computed(): ленивый, кешируемый, транзитивно отслеживаемый и никогда не пересчитываемый пока источник реально не изменился. Computed хранит thunk `() => value`, флаг dirty и собственное множество подписчиков; вычисляется только при чтении (лениво) и возвращает кешированное значение если ни один источник не испачкал его с последнего чтения. При вычислении он также участвует в отслеживании зависимостей — так что чтение computed внутри эффекта транзитивно подписывает эффект на исходные сигналы computed, а не только на сам узел computed. Цепочка: запись источника → пометить computed грязным → запланировать эффект → при сбросе computed лениво пересчитывается (один раз) до чтения эффектом. Докажи: computed чей источник не менялся возвращает кеш с нулём пересчётов (посчитай вызовы thunk); чтение computed внутри эффекта заставляет эффект перезапускаться при изменении источника, но не при изменении несвязанного сигнала; измени источник, дважды прочитай computed и убедись что thunk сработал ровно один раз.

Реализуй батчинг так, чтобы несколько записей сигнала внутри `batch(() => {...})` запускали каждый эффект ровно один раз, после всех записей, без устаревших промежуточных чтений (глюков). Глюк: в наивном push-графе запись A немедленно распространяется на B и C, которые немедленно запускают подписчиков. Если D зависит от B и C (ромб A→B, A→C, B&C→D), D запускается при обновлении B (читая устаревший C) и снова при обновлении C — два вычисления, одно с несогласованным промежуточным состоянием. Фикс — отложить сброс: пометить грязные узлы, отсортировать реактивный граф топологически и сбросить в топологическом порядке, чтобы computed никогда не вычислялся пока хотя бы один из его источников ещё грязный. Докажи ромбовидным тестом: A→B, A→C, B&C→D обновляет D один раз без устаревшего чтения при изменении A внутри batch, плюс подсчёт что эффект D сработал ровно один раз за две записи внутри batch. Объясни, почему наивный BFS/push без топологической сортировки порождает глюки.

Добавь untrack() для чтения сигнала без подписки и onCleanup(), чтобы эффекты освобождали ресурсы перед повторным запуском. untrack(() => signal.value) вычисляет функцию с временно обнулённой глобальной currently-executing, так что чтение невидимо для отслеживания зависимостей — нужно когда эффект должен прочитать значение не становясь реактивным к нему (например, сигнал логгера или кеш предыдущего значения). onCleanup(fn) регистрирует колбэк, выполняющийся перед следующим перезапуском эффекта (и при dispose), так что подписки, таймеры или abort-контроллеры, созданные в предыдущем прогоне, прибиваются до следующего — без этого каждый перезапуск утекал бы. Докажи оба: чтение сигнала B через untrack внутри эффекта, подписанного на A, не заставляет записи B перезапускать эффект; эффект создающий таймер и регистрирующий onCleanup(() => clearTimeout) чистит ровно один раз на перезапуск без утёкших таймеров.

Докажи масштабируемость библиотеки и сделай реактивный граф наблюдаемым. Бенчмарк: создай 10k сигналов с графом computed веером и измерь стоимость batch — топологическая сортировка и сброс должны быть O(узлы + рёбра), а не O(узлы × записи), так что батчинг 100 записей всё равно запускает каждый эффект один раз, стоимость пропорциональна размеру графа, а не числу записей. Снимай лёгкие метрики самой библиотеки: число запусков эффектов, число вычислений computed, число и длительность сбросов batch. Затем отработай инцидент: создай цепочку 1000 узлов и убей батчинг (пиши без batch), чтобы увидеть как та же цепочка триггерит 1000 каскадных обновлений против 1 батчированного сброса — обрыв производительности и есть доказательство что батчинг несущий. Задокументируй сложность: маркировка на запись O(подписчики), сброс O(отсортированных грязных узлов) и почему виртуализованный рендеринг графа (не библиотеки) — отдельный вопрос.