Мне нравится такой подход: создавать юниты эффектора в одном файле, а их взаимодействия - в другом.

Выглядит это так:
model.js - интерфейс модели (сущности),
init.js - модель поведения (связи)

Удобно, когда в одном файле описано, что из себя представляет модель. Заглянув в этот файл, можно  быстро получить представление о модели, её состояниях и методах, до погружения в бизнес-логику.  Создавая юниты в одном файле, мы описываем интерфейс модели (как интерфейс объекта в типах).

Получается, что вся логика  находится в одном файле (init), а создание сущностей мы выносим в отдельный (model), чтобы видеть структуру модели, т.е. что она из себя представляет. В итоге, интерфейс и поведение разделены.

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

Сергей Недашковский - Data Scientist, Santiment, Москва

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

Полезные ссылки:
Сайт конференции - https://gdg-russia.com
GDG сайт - http://gdg.community.dev
Telegram чат со спикерами и участниками - https://t.me/gdgrussiachat
Telegram канал для анонсов - https://t.me/gdgrussia

The Playground lets you write TypeScript or JavaScript online in a safe and sharable way.

так, короче по ходу удалось реализовать такой вариант:

const apiCallFx = createEffect<typeof apiCall, AxiosError>(apiCall)