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

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

я правильно понимаю, что паттерн index, state, init нам разрешает связывать “модули” друг с другом? )

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

Так для авторизации у меня есть файл с экспортами публичного API, login, logout, readToken, getSession, session, примерно так. И есть несколько файлов с реализациями, при импорте конкретного файла в них создаются нужные связи. Так для авторизации у меня есть пара файлов jwtAuthFlow и kerberosAuthFlow.

В коде приложения в зависимости от нужды импортирую тот или иной модуль.  Из минусов - так как связи создаются статически при импорте, то нет возможно по условию импортировать нужный файл (динамические импорты не рассматриваю). Была мысль обернуть объявления связей в функцию-фабрику, но это как-то криво. Вот как в таких случаях быть?

у меня в проекте нету циклических зависимостей вообще, а где нужно общее состояние, то это определенно вне фич вообще в bootstrap )

О у меня похожий кейс ))
функции-фабрики ок

То есть хочется DI, но это не сочетается совершенно со статическим объявлением на уровне модуля

мы же createEffect используем, почему бы и не определить createAuth )

это получается poor man’s DI

Ага, но пока не нашёл лучшего решения

Ну в целом с фабриками мне понравился подход, но тут не одобряют такое. То есть фабрика принимает объект с публичным апи, а внутри определяет все связи

Как не одобряют? далеко ходить не надо, какой-нибудь createThrottle из effector-throttle самая настоящия функция-фабрика

Возможно надо меньше парится и пробовать разные подходы

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

да ну нет конечно

DI это poor man's graph linking

модули тоже по сути di

я именно про это и говорю, я не считаю концепцию di чем либо кроме эмпирически выявленных совпадений, вызванных недопониманием более общей картины

«зависимость» это даже на смысловом уровне неверно, кто сказал, что т.н. зависимому модулю эта связь нужна больше, чем предоставляющему зависимость?)

то есть di это просто один из способов представить связи в графе приложения (граф приложения неявно существует у всех, всегда, эффектор просто делает его явным)