но кмк нужно более детально этот момент описать в доке https://effector.now.sh/docs/api/effector/event#filtermapfn

а то Returns: new event

само собой с шашкой на голо я побежал его вызывать и слушать в сторе

а то что в примере принял за опечатку

ну тут по идее нужно обозначить концепцию вычисляемых сущностей вообще

например таким образом было обосновано почему нельзя вызывать эвенты внутри мапов https://effector.now.sh/docs/glossary#pureness

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

то есть это в принципе общая идея в рамках библиотеки

в общем, есть теперь над чем поразмыслить 👌 постараюсь придумать, как это лучше сформулировать

@ZeroBias а сейчас реально в таком примере что произойдет?

при вызове эвента будет определено откуда он вызван?

и рантам exception какой то например кидать

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

а ну то есть эвент просто в конец очереди размещается?

ага

это происходит сплошь и рядом в ватчерах, и пусть там и остаётся))

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

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

то есть в этом примере воспроизводится ситуация когда в слишком большом приложении мы напетляли в грязном коде и начали запускать submitLoginSize ожидая что loginSize (или любые другие данные) уже вычислились, запускать из середины процесса их вычисления

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

чтобы те не нарушали процесс вычисления состояния и сами не ломались от использования неконсистентных данных посередине рассчётов

ну это то понятная проблема