не проще будет читаться?

у тебя есть экшены эффекты ивенты

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

если у тебя есть под рукой пример "бизнес логики" которая размазана по "слоям"

то можно было бы оттуда подступиться

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

ну вот приведи пример бизнес логики, вдруг там "достать данные из формочки"

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

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

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

и все это не на уровне хуков

хуки больше как клей или для всякой UI логики постенькой

где тогда это хранить и как

есть разные варианты. По дефолту конвеншен который я сча навязываю команде это "сделайте файлик Types.ts для описания общих типов в пределах фичи и Model.ts для всяких там сторов ивентов эффектов эффектора и там храните логику". При этом если фича большая и хочется больше декомпозировать все это - никто не мешает разбивать логику. Например в фиче "звонки" у меня будут какие-нибудь Participants папка в которой лежат те же Model.ts, Types.ts и т.д. мне нужен оч тупой конвеншен который удобно соблюдать по сути

Можно сделать папку Model и внутри дробить логику по модулям. опять же главный движетель это SRP/Information hiding

во, супер

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

пусть хотя бы названия сторов и ивентов нормальными делают

а файлик пусть будет model.ts

как дергать эту логику в модельсах

в смысле?