Оперативно, спасибо 👍

effector 21.6.0effector 21.6.0

• Add support for user-defined factories in fork api. Starting from this release, application developers can use their own functions and be sure that their content will be properly serialized and hydrated by fork api.
New field "factories" in effector/babel-plugin accepts array of module names which exports will be treated as custom factories therefore each function call will provide unique prefix for sid properties of units inside them

{
 "plugins": [
   ["effector/babel-plugin", {
     "factories": ["src/createEffectStatus"]
   }]
 ]
}

// ./src/createEffectStatus
import {rootDomain} from './rootDomain'

export function createEffectStatus(fx) {
 const $status = rootDomain.createStore('init')
   .on(fx.finally, (_, {status}) => status)
 return $status
}

// ./src/statuses
import {createEffectStatus} from './createEffectStatus'
import {fetchUserFx, fetchFriendsFx} from './api'

export const $fetchUserStatus = createEffectStatus(fetchUserFx)
export const $fetchFriendsStatus = createEffectStatus(fetchFriendsFx)

createEffectStatus from './createEffectStatus' was treated as factory function so each store created by it has its own sid and will be handled by serialize independently, although without factories they will share the same sid

factories in documentation

• Add user-friendly unit name in fork api error messages when given unit is not found in scope. This improves error messages in both effector and effector-react

• Add validation for values and handlers fields in fork and for values field in hydrate

• Add type support for createEffect<typeof handler, Error>(handler) to infer Params and Done types from given handler and provide custom Fail type at the same time

createEffect and custom errors in documentation

• Improve guard return type inference (PR 406 (thanks @doasync))

• Fix void params support for createEffect(name, config) (issue 404)

• Allow to use Event<void> in cases when only () => void is accepted (PR 400 (thanks @doasync))

• Add support for merge to effector/babel-plugin

о, но как это будет работать?

store = newState

Точно так же как в твоём снипете

const items = createStore([])
const limit = createStore(20);
const limitChanged = createEvent<number>();

У меня всегда для селектов есть дисплейВелью и велью. Иногда даже на уровне вью

А подскажите, мне надо как-то послать определённый event, дождаться пока store обновится, обработав этот event и потом вызвать определённый код. Как лучше сделать? Что-то вроде вот этого, но вынеся bindPersistAction из обработчка rehydrate event

const rehydrate = createEvent<State>("@PERSIST/REHYDRATE");

const bindPersistAction = store.watch((state) => {
  config.storage.setItem(persistKey, JSON.stringify([Date.now(), state]));
});

if (persistedState != null) {
  store.on(rehydrate, (_state, data) => {
    bindPersistAction();
    data;
  });
  rehydrate(parsedState[1]);
}

Не могу придумать как красиво это сделать.

Но в доке пишут, что тут должна быть чистая функция. А подскажите, rehydrate() вернёт управление после того, как обновится store? Оно такое же синхронное как в redux? Я по-идее могу вызвать bindPersistAction() сразу после rehydrate(parsedState[1]);?

функция в watch может быть любой

но в редюссере да, никаких сайд эффектов быть не должно

угу, я перепутал с on. Получается watch тоже может принимать trigger! Да, это сильно всё упрощает.

Там в доке опечатка, нет trigger https://effector.dev/docs/api/effector/store#watchwatcher

это следующий оверлоад https://effector.dev/docs/api/effector/store/#watchtrigger-watcher

Ой :)

Там вот так, trigger написан, но не показано где он в параметрах.

ой, действительно

Мне кажется эти два раздела есть смысл объединить. Я б ни за что не посмотрел на второй overload :) Просто не ожидал, что он есть :)

скорее переместить вотчер с триггером повыше

объединять такое себе
ибо у них разное поведение