Это как

Ну в библиотеке сразу код писать с расчётом на сср

А как это сделать грамотно?

Создавать все сущности в домене и экспортировать его? А потом что с ним делать ?

Ну вот как вариант - потыкать сюда

И спросить @sovasergey

вообще, достаточно пользователю дать возможность передать свой домен, наверное

то есть фабрику экспортировать из либы?

ну да

++

што-то домены мне начинают хоки напоминать

а в svelte разве нельзя управлять значением стора передав в компонент эвенты? то есть чтобы условный value у input читался из стора, а при вводе текста срабатывал onChange в который передан эвент

стм нужен всегда

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

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

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

view библиотеки это стм на минималках вокруг обвязок к dom api

проблемы идут как раз из того, что view библиотеки не осознают себя как стейт менеджеры

forest вроде бы создавался с такими мыслями

да

очень показательно то, что биндинги к дом апи занимают лишь пару процентов кода https://github.com/zerobias/effector/blob/master/src/forest/bindings.ts#L48

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