А можно подробнее про твой случай?

Вьюха Получает на вход какие варианты (типа список элементов, даты, все в обьекте input) На выход по клику кнопки дергает callback Все верианты что получает вьюха на вход можно менять и они соответственно сразу должны отображаться Со всеми пунктами работало нормально и без remember (менял напрямую в input) Но вот другая кастомная вьюха не захотела пересоздаватся таким образом И мне пришлось вынести даты в remember Я вот щас писал и понимаю что что то тут не так...

А можно засунуть весь input в mutableStateOf ? Или так и нужно?

А зачем что-то менять внутри вьюхи?

Что б менялось отображение И по нажатию кнопки вернуть результат целиком

так тебе внутрь вьюхи необязательно и не нужно ничего менять, это делается извне (как описывали ранее с помощью state hosting). И результат возвращать целиком тоже

Есть пример?

камон, обычный @Composable + ViewModel или подобные, это чтобы не было десяток параметров на чтение и калбэков, можно состояния обернуть в дата класс, но с калбэками не решится дело. Можешь описать задачу хорошо?

Экран использует ViewModel и state в data класе Кастомная вьюха (шит) Получает на вход какие варианты (типа список элементов, даты, все в обьекте input) На выход по клику кнопки дергает callback Она имеет в себе еще пару кастомных вьюх Типа DataPicker у которого есть разные параметры зависящие от состояния родительской вьюхи (минимальное, максимальное, выбраное значения) На выходе тоже коллбек

viewmodel содержит в себе state, передавай его в корневую вьюху свою и шарь его части по child. Все. Евенты прописываются во viewmodel и прокидываются также как и state (где нужен туда и прокидывай через родителя). Почитай state management в доке и про udf в кодлабе про state

Но таким образом все вьюхи будут завязаны на viewModel

зачем ей и вьюмодель и стейт? ViewModel - model for a view (~ state).

state это обьект которым передаются данные А VIewModel это класс который за эти данные отвечает

необязательно все, ну и что тут плохого? Не одна же ViewModel. Для каждой View своя ViewModel.

ну так ViewModel же и содержит эти данные и из нее ты и получаешь этот state

Ну то что кастомной вьюхе занть о viewmodel совершенно ни к чему Ее задача сильно проще

там где не ViewModel, там data class или что-то полегче + калбэк

Ну да Это выходит из того что я сказал

какие аргументы?

нет

Зачем мне эта связанность? Я хочу переиспользовать эту вьюху и с другими экранами и соответственно вьюМоделями

кто Вам мешает?