вообще домены при ssr нужны для того, чтобы гарантировать отсутствие изолированных «островов» графа связанных непрозрачными императивными вызовами

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

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

вообще домены при ssr нужны для того, чтобы гарантировать отсутствие изолированных «островов» графа связанных непрозрачными императивными вызовами

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

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

Ну на самом деле даже крупные црм, с которыми приходилось работать, использовали стм где-то на 10%

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

с процентами кстати есть один нюанс — у каждого эти 10% свои, в итоге, если стейт менеджер покрывает 80% кейсов всех пользователей, то вероятность столкнуться с ограничениями стремительно растёт по мере использования)

вот такое апи будет у нового effector-storage 🙂 на npm я пока не опубликовал, буду рад пока отзывам по ридми 🙂
https://github.com/yumauri/effector-storage/tree/next

я думал, что в новом api ты сделаешь возможность просто передавать готовый стор, что дало бы возможность юзать effector-forms

Может есть метод точно найти места в графе схлопнув которые мы приедем к планарности?

Жил-был один компонент, и была у него модель, которая была написана с помощью эффектора. И эта модель зависела от одного толстого сервиса, который тоже был написан на эффекторе. А зависела она напрямую: import { thisFuckingServiceInstance } from '../../thisFuckingServiceInstance'. Всё бы ничего, но компонент выносится из проекта в виде отдельного пакета, и такая зависимость с этого момента неприемлема.

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

экспортировать из модели компонента нужные ивенты

А в коде приложения соединить instance и модель этого компонента, через forward