https://github.com/GTOsss/srr-effector-next-example

ну у меня какая-то хрень получилась)

делал аналогично этому
https://github.com/vercel/next.js/tree/canary/examples/with-redux

не понимаю что я упускаю и почему у меня пустой объект по результату выполнения:

serialize(fork(root))

ребят  а может кто то продублировать портяночку начальную требований к эффектору как к стейт менеджеру?  можно в лс

Лучше здесь

Это оно?

децентрализованность, декларативность, эффективность. требовался инструмент, позволяющий управлять данными в сложных приложениях без опасности раздуть монолитный центральный стор, с явным control flow, нормальной типизацией и емким апи
— сторы для приложения должны быть лёгкими, насколько это возможно — не должна пугать мысль о том, что нужно добавить ещё один стор для конкретных нужд
— сторы должны свободно совмещаться — идея в том, что данные, которые потребуются приложению, можно распределить статически, заранее показав как данные будут преобразоваться во время работы приложения
— принцип работы должен by design исключать необходимость в reselect, оповещая об изменениях только тех, кому они необходимы. это позволяет не задумываться о том, что у тебя будет триггериться всё приложение если ты захочешь вынести  стейт модалки из реакта. по совместительству это означает что приложения избавлены от проблем с перфомансом, возникшим у react-redux при переходе на контекст
— возможность, место, и способ вынести любую требуемую бизнес-логику из view, максимально упрощая компоненты
— независимость от спорных концепций — никаких декораторов, никаких зависимостей от реакта/rxjs либо необходимости юзать классы или прокси — ничего из этого не требуется для управления состоянием приложения и поэтому апи библиотеки использует только функции и простые js объекты
— предсказуемость апи. небольшое число базовых принципов переиспользуются в различных кейсах, снижая нагрузку на юзера и повышая узнаваемость. зная как работает .watch  в эвентах, можно догадаться, что делает функция .watch у стора
— приложение строится из комбинации базовых элементов и возможности строить новые.
нет никакого смысла стремиться выдать всё за стрим, за редьюсер или за обсервабл, в приложении требуются они все, и библиотека предлагает решение чтобы управлять структурой данных, а не скрывать её

Разве не было нигде про провайдеры и контекст?

и отличие эффектора от контекста, и разница с внутриреактовыми сторами сводятся к одному: зонам ответственности. концепция реакта подразумевает, что фронтенд-разработчики — это части гигантского организма, в котором всё предопределяется наверху, а разработчики могут максимум лишь реагировать (reacts) на то, что им свалилось сверху на этот раз, не имея ни малейшего шанса повлиять на это

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

а ещё понял, что феномен zombie childs из реакта имеет фундаментальную природу

когда я начал с этим разбираться, я понял, что zombie childs это не эдж кейс а верхушка айсберга, принцип, которому подчиняется вся асинхронная система апдейтов

возьмём граф состояний приложения. часть состояний обновляется синхронно, часть — асинхронно. сплошными линиями обозначена синхронная связь, пунктиром — асинхронная

в коде это будет

const a = createStore([0, 1, 2])
const b = a.map(
 items => items.map(() => ({selected: false}))
)

list(a, ({store, key: index}) => {
 const c = combine(
   b, index,
   (items, index) => items[index].visible
 )
 h(div,  {visible: c})
})

то есть мы комбинируем данные из стора, который обновляется синхронно с данными из стора, обновляемого асинхронно, как результат — при удалении элемента из списка, стор b быстро лишится нужного значения в своём массиве и вычисление c будет падать на неконсистентном промежутке времени, закрашенном пунктиром

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

соответственно, нам нужен механизм, который бы позволял нам указывать, с каким темпом будет обновляться состояние. и тут нам на помощь приходит sample)

так как в реакте диктат пропсов, то им такое решение не доступно, отсюда фундаментальные затыки, так как такая ситуация возникает повсеместно)

после обновления A стор B обновляется немедленно, а сквозь лист и его элемент апдейты проходят с задержкой, это проявление асинхронности рендеринга

соответственно путь A → list → item → C будет гораздо дольше, чем A → B → C

это и есть то, что создаёт зомби чайлдов