State hoisting in Kotlin onSearchChange: (String) -> Unit

Question

I am trying to use state hoisting in android

---

I am new to android development using jetpack compose

onSearchChange: (String) -> Unit,
onCategoryChange: (Category) -> Unit,
onProductSelect: (Product) -> Unit,
    
    
composable(Screen.Home.route) { MainPage(navController = navController, searchQuery = "",
                productCategories = categories, selectedCategory = Category("","",0),
                products = pros, /* what do I write here for the 3 lines above?? :( the onSearch,etc I have an error bc of them */
                )}

Answer 1

In addition to the answer, apologies, this is a bit long, as Ill try to share how I design my "state hoisting"

Lets simply start first with the following:

A: First based on the Official Docs

State in an app is any value that can change over time. This is a very broad definition and encompasses everything from a Room database to a variable on a class.

All Android apps display state to the user. A few examples of state in Android apps:

• A Snackbar that shows when a network connection can't be established.
• A blog post and associated comments.
• Ripple animations on buttons that play when a user clicks them.
• Stickers that a user can draw on top of an image.

B: And personally, for me

"State Hoisting" is part of "State Management"

Now consider a very simple scenario, We have a LoginForm with 2 input fields, and have its basic states like the following

• Input will be received from the user and will be stored in a mutableState variable named userName
• Input will be received from the user and will be stored in a mutableState variable named password

We have defined 2 requirements above, without doing them, our LoginForm would be stateless

@Composable
fun LoginForm() {

    var userName by remember { mutableStateOf("")}
    var password by remember { mutableStateOf("") }

    Column(
        modifier = Modifier
            .fillMaxWidth()
            .wrapContentSize()
    ) {

        TextField(
            value = userName,
            onValueChange = {
                userName = it
            }
        )

        TextField(
            value = password,
            onValueChange = {
                password = it
            },
            visualTransformation = PasswordVisualTransformation()
        )
    }
}

So far, everything is working but nothing is "Hoisted", their states are handled inside the LoginForm composable.

State Hoisting Part 1: a LoginState class

Now apart from the 2 requirements above, lets add one additional requirement.

• Validate user name and password
  • if login is invalid, show Toast "Sorry invalid login"
  • if login is valid, show Toast "Hello and Welcome to compose world"

This can be done inside the LoginForm composable, but its better to do the logic handling or any business logic in a separate class, leaving your UI intact independent of it

class LoginState {
    var userName by mutableStateOf("")
    var password by mutableStateOf("")


    fun validateAction() {
        if (userName == "Stack" && password == "Overflow") {
            // tell the ui to show Toast 
        } else {
            // tell the ui to show Toast
        }
    }
}

@Composable
fun LoginForm() {

    val loginState = remember { LoginState() }

    Column(
        modifier = Modifier
            .fillMaxWidth()
            .wrapContentSize()
    ) {

        TextField(
            value = loginState.userName,
            onValueChange = {
                loginState.userName = it
            }
        )

        TextField(
            value = loginState.password,
            onValueChange = {
                loginState.password = it
            },
            visualTransformation = PasswordVisualTransformation()
        )
    }
}

Now everything is still working and with additional class where we hoisted our userName and password, and we included a validation functionality, nothing fancy, it will simply call something that will show Toast with a string message depending if the login is valid or not.

State Hoisting Part 2: a LoginViewModel class

Now apart from the 3 requirements above, lets add some more realistic requirements

• Validate user name and password
• if login is invalid, show Toast "Sorry invalid login"
• if login is valid, call a Post login network call and update your database
• if Login is success from backend sever show a Toast "Welcome To World"
• But when the app is minimized you have to dispose any current network call, no Toast should be shown.

Take note that the codes below won't simply work and not how you would define it in a real situation though.

val viewModel = LoginViewModel()

data class UserLogin(
    val userName : String = "",
    val password : String = ""
)

class LoginViewModel (
    val loginRepository: LoginRepository
) {

    private val _loginFlow = MutableStateFlow(UserLogin())
    val loginFlow : StateFlow<UserLogin> = _loginFlow

    fun validateAction() {
        // ommited codes
    }

    fun onUserNameInput(userName: String) {
    }

    fun onPasswordInput(password: String) {
    }
}


@Composable
fun LoginForm() {

    val loginState by viewModel.loginFlow.collectAsStateWithLifecycle()

    Column(
        modifier = Modifier
            .fillMaxWidth()
            .wrapContentSize()
    ) {

        TextField(
            value = loginState.userName,
            onValueChange = {
                viewModel.onUserNameInput(it)
            }
        )

        TextField(
            value = loginState.password,
            onValueChange = {
                viewModel.onPasswordInput(it)
            },
            visualTransformation = PasswordVisualTransformation()
        )
    }
}

But that's the most top level state hoisting you can do where you would deal with network calls and database.

To summarize:

• You don't need to consider hoisting up your mutableStates if its just a simple composable doing simple thing.
• But If the logic gets bigger consider using a State Class like the LoginState class to make your UI independent of the business logic.
• If you have to perform some network calls, database updates and making sure such use-cases are bound to a LifeCycle, consider using a ViewModel

Another thing to mention but out of topic is when you are hoisting states, there is a thing called scoped re-composition where you want a specific composable to get updated without affecting the others around, it is where you will think your composable designs on how you would handle mutableStates.