ну проблемы проектов, уже использующих реакт не менее важны чем наличие альтернативного решения

просто с анонсом новой версии реакта пришло понимание что в этом промежуточном состоянии с варнингами мы надолго

соответственно все всё понимают про реакт, но это не отменяет необходимости учитывать меняющиеся условия

Я поражен как ты красиво сделал отмену операций рендера в очереди

Это то, что не хватает во многих библиотеках(

спасибо 🙈🙈🙈 я над ней очень долго размышлял)

я похожую штуку поверх реакта пилил, когда запиливал виртуализацию скролла

Только это все равно через жопу и форсапейты было

Я так и не пойму прикола с этими 3 файлами

Почему в init навешиваем обработчики

я просто апдейнтул пример)
можешь по соседству сделать альтернативный вариант

чтобы связи были только в нём, как минимум это избавляет от циклов

я думаю это скорее просьба развернуть в доке мысль поподробнее

мысль в том, что мы разделяем бизнес-логику на зоны ответственности, а каждую зону ответственности на декларацию и инициализацию
в которую входит хэндлеры эффектов, обработчики сторов и операторы(forward, sample etc)

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

Не, так переименовывать проще, нежели объекты

Я не понял

он имеет в виду, что тот же sample имеет объектный апи sample({ source, clock, target })

а combine принимает аргументами сторы и функцию
combine(a, b, c, fn)