12

So it seems like the recommended thing in Jetpack Compose is to hoist state out of your composables, to make them stateless, reusable, and testable, and allow using them in previews easily. So instead of having something like

@Composable
fun MyInputField() {
    var text by remember { mutableStateOf("") }
    TextField(value = text, onValueChange = { text = it })
}

You'd hoist the state, like this

@Composable
fun MyInputField(text: String, onTextChange: (String) -> Unit) {
    TextField(value = text, onValueChange = onTextChange)
}

This is fine, however what of some more complex uses? Let's pretend I have a screen represented by a composable, with multiple interactions between the View and the ViewModel. This screen is split into multiple inner composable (think for instance one for a header, one for the body, which in turn is split into several smaller composables)

  • You can't create a ViewModel (with viewModel() at least, you can instantiate one manually) inside a composable and use this composable in a Preview (previews don't support creating viewmodel like this)
  • Using a ViewModel inside the inner composables would make them stateful, wouldn't it ?

So the "cleanest" solution I see, would be to instantiate my viewmodel only at the highest composable level, and then pass to the children composables only vals representing the state, and callbacks to the ViewModel functions.

But that's wild, I'm not passing down all my ViewModel state and functions through individual parameters to all composables needing them. Grouping them in a data class for example could be a solution

data class UiState(
  val textInput: String,
  val numberPicked: Int,
  ……

and maybe create another one for callbacks ? But that's still creating a whole new class just to mimic what the viewmodel already has.

I don't actually see what the best way of doing this could be, and I find nothing about that anywhere

Matteo Melis
  • 176
  • 1
  • 9

2 Answers2

2

A good way to manage complex states is to encapsulate required complex behavior into a class and use remember function while having stateless widgets as most as you can and change any properties of state whenever it's required.

SearchTextField is a component that uses only state hoisting, SearchBar has back arrow and SearchTextField and also itself is a stateless composable. Communication between these two and parent of Searchbar is handled via callback functions only which makes both SearchTextField re-suable and easy to preview with a default state in preview. HomeScreen contains this state and where you manage changes.

Full implementation is posted here.

@Composable
fun <R, S> rememberSearchState(
    query: TextFieldValue = TextFieldValue(""),
    focused: Boolean = false,
    searching: Boolean = false,
    suggestions: List<S> = emptyList(),
    searchResults: List<R> = emptyList()
): SearchState<R, S> {
    return remember {
        SearchState(
            query = query,
            focused = focused,
            searching = searching,
            suggestions = suggestions,
            searchResults = searchResults
        )
    }
}

remember function to keep state for this only to be evaluated during the composition.

class SearchState<R, S>(
    query: TextFieldValue,
    focused: Boolean,
    searching: Boolean,
    suggestions: List<S>,
    searchResults: List<R>
) {
    var query by mutableStateOf(query)
    var focused by mutableStateOf(focused)
    var searching by mutableStateOf(searching)
    var suggestions by mutableStateOf(suggestions)
    var searchResults by mutableStateOf(searchResults)

    val searchDisplay: SearchDisplay
        get() = when {
            !focused && query.text.isEmpty() -> SearchDisplay.InitialResults
            focused && query.text.isEmpty() -> SearchDisplay.Suggestions
            searchResults.isEmpty() -> SearchDisplay.NoResults
            else -> SearchDisplay.Results
        }
}

And change state in any part of UI by passing state to other composable or by ViewModel as

fun HomeScreen(
    modifier: Modifier = Modifier,
    viewModel: HomeViewModel,
    navigateToTutorial: (String) -> Unit,
    state: SearchState<TutorialSectionModel, SuggestionModel> = rememberSearchState()
) {


    Column(
        modifier = modifier.fillMaxSize()
    ) {
            
        SearchBar(
            query = state.query,
            onQueryChange = { state.query = it },
            onSearchFocusChange = { state.focused = it },
            onClearQuery = { state.query = TextFieldValue("") },
            onBack = { state.query = TextFieldValue("") },
            searching = state.searching,
            focused = state.focused,
            modifier = modifier
        )

        LaunchedEffect(state.query.text) {
            state.searching = true
            delay(100)
            state.searchResults = viewModel.getTutorials(state.query.text)
            state.searching = false
        }

        when (state.searchDisplay) {
            SearchDisplay.InitialResults -> {

            }
            SearchDisplay.NoResults -> {

            }

            SearchDisplay.Suggestions -> {

            }

            SearchDisplay.Results -> {
 
            }
        }
    }
}
Thracian
  • 43,021
  • 16
  • 133
  • 222
  • 1
    I really like this approach as it allows us to group different screen elements in a single state object. Would it be possible to make `SearchState` non-`@Composable` and use it also in a ViewModel to reduce its verbosity? I wonder if there is a way to take a data class and decompose all of its properties to state w/o having to white a ton of boilerplate – quealegriamasalegre Feb 16 '22 at 11:26
  • Yes, you are right about `@Composable`, it was a mistake. `@Composable` annotation should be used with `rememberSearchState ` since `remember` returns ` @Composable invocations can only happen from the context of a @Composable function`. This approach is the one used with `rememberScrollState` or `rememberImagePainter` from Coil, or `rememberPagerState` from Accompanist. If you don't want to remember state you can just put it inside ViewModel either or use it as other rememberables. – Thracian Feb 16 '22 at 16:03
0

Jetmagic is an open source framework that deals exactly with this issue while also solving other major issues that Google neglected when developing Compose. Concerning your request, you don't pass in viewmodels at all as parameters. Jetmagic follows the "hoisted state" pattern, but it manages the viewmodels for you and keeps them associated with your composables. It treats composables as resources in a way that is similar to how the older view system treats xml layouts. Instead of directly calling a composable function, you ask Jetmagic's framework to provide you with an "instance" of the composable that best matches the device's configuration. Keep in mind, under the older xml-based system, you could effectively have multiple layouts for the same screen (such as one for portrait mode and another for landscape mode). Jetmagic picks the correct one for you. When it does this, it provides you with an object that it uses to manage the state of the composable and it's related viewmodel.

You can easily access the viewmodel anywhere within your screen's hierarchy without the need to pass the viewmodel down the hierarchy as parameters. This is done in part using CompositionLocalProvider.

Jetmagic is designed to handle the top-level composables that make up your screen. Within your composable hierarchy, you still call composables as you normally do but using state hoisting where it makes sense.

The best thing is to download Jetmagic and try it out. It has a great demo that illustrates the solution you are looking for:

https://github.com/JohannBlake/Jetmagic

Johann
  • 27,536
  • 39
  • 165
  • 279