Нет

все понял, благодарю

Давай попробуем на тебе пояснение😄

Любые сторы нужно заполнять пейлоадами ивентов. С помощью редьюсеров в он или прямой установки связи через операторы forward, sample, guard, createApi, restore

Эффект с одной стороны является контейнером для сайд эффектов (например это любые async или операции в результате работы которых эксепшн - это норма).

К тому же эффект это структура связанных юнитов (сторов и ивентов) взаимодействующих по строгим правилам.

Ивент done и его производный doneData вызываются всегда после успешного резолва промиса от эффекта (даже если колбек в эффект передан синхронный, то он его для консистенции все равно обернет в промис, читай промисификация по эффекторски😄)

Ивент doneData (как и другие юниты составляющие структуру эффекта) по сути являются сигнальными. Т.е. модифицировать/вызывать их не следует, а только лишь реагировать встраивая в цепочки связей.

const fx = createEffect(() => ({id: 1, name: "Вася"}))

const name$ = createStore("")
.on(fx.doneData, (currentState, fxPayload)=>fxPayload.name)
// Установили связь

fx()
// После резолва, в сторе будет "Вася"

Привет! Как думаете, стоит ли в useStoreMap добавить функцию, которая будет экстендить сравнение результата от fn? Я юзаю вот fp-ts (подобные структуры, которые есть в ней) и в силу инородности монадок в js я не могу просто так через === сравнить две версии монады, делаю через отдельную функцию)

быстрым решением было бы самому заэкстендить useStoreMap у себя на проекте, но мб кому-то еще такого не хватает

"экстендить сравнение результата от fn? " - что это значит?
Может снипетом?

Интерфейсно вот так
```
useStoreMap({
   store: store,
   keys: [id],
   fn: (store, [$id]) => store[$id],
        comparator: (prevValue, newValue) => customFunc(prevValue, newValue)
})
```

Например если у меня union каких-то типов, а я не хочу расслаивать их на отдельные сторы (потому что это какой-то оверхед)

```
useStoreMap({
   store: store,
   keys: [id],
   fn: (store, [$id]) => pipe(store[$id], $value => isValueOfSomeType($value) ? some($value) : none),
        comparator: maybeMonadComparator
})
```

Эффектор наоборот поощряет дробление

Ты сам себе ограничения делаешь

И проблему, с которой героически борешься

Откуда берется id?

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

это уникальный ключ который спускается например из list.map в сабкомпонент, чтобы потом сабкомпонент забрал по id нужные значения и не триггерился на каждый чих того, что происходит со списком

Сделай все внутри модели, а во вьюху отдавай просто данные для рендера. Зачем туда ещё затаскивать логику сравнения

Хм можно было бы расширить useStoreMap доступом к updateFilter для подкапотного стора, возможно🤔

А как ты видишь экстенд?

пока не пробовал, но кажется, что хватит скопипастить это идобавить guard где source будет хранилищем prevValue clock - nextValue, а filter = та самая функция с фоллбеком на прямое сравнение ===