Composable Function: What It Is, Function Syntax, and Rules

What Is a Composable Function in Jetpack Compose

A Composable Function is a function in the Kotlin language, marked with the @Composable annotation, that describes a part of the user interface in a declarative way. Instead of creating and configuring View objects through Java code or XML markup, the developer simply writes how the UI should look for each state of the data.

The main difference between a Composable function and the traditional Android View system lies in the update model. In the classic approach, the developer manually called findViewById, changed text via setText, and managed visibility via setVisibility. Composable Function frees you from this routine: when data changes, the system itself determines which functions need to be recomposed and executes only those.

The Kotlin compiler, processing the @Composable annotation, generates additional code that integrates the function into the composition mechanism. This code includes reading and writing to slots — special memory cells that store the state and parameters of each Composable function in the current UI tree. Thanks to this integration, Compose knows which functions depend on which data.

Composable Function Declaration Syntax

The syntax of a Composable function is extremely concise: just add @Composable before the fun keyword. The function can accept any parameters, include other Composable calls in its body, and use Kotlin constructs — conditions, loops, when-expressions — for conditional UI rendering.

@Composable
fun ProductItem(
    product: Product,
    modifier: Modifier = Modifier,
    onAddToCart: () -> Unit
) {
    Card(modifier = modifier.padding(8.dp)) {
        Row(modifier = Modifier.fillMaxWidth().padding(12.dp),
            verticalAlignment = Alignment.CenterVertically) {
            Column(modifier = Modifier.weight(1f)) {
                Text(text = product.name, style = MaterialTheme.typography.titleMedium)
                Text(text = "${product.price}", color = MaterialTheme.colorScheme.primary)
            }
            Button(onClick = onAddToCart) {
                Text("Add to cart")
            }
        }
    }
}

In this example, the ProductItem Composable function accepts a Product object, a modifier, and a callback. All three parameters are immutable, which guarantees predictable behavior during recomposition. The modifier is passed as a parameter with a default value — this is a standard practice that allows the caller to customize padding and sizes.

Components and Modifiers in Composable Functions

Inside a Composable function, built-in Material Design components (Text, Button, Card, TextField) or fundamental primitives (Canvas, Layout) are used. Each component accepts parameters for configuring appearance and behavior, as well as one or more modifiers through the modifier parameter.

Modifiers are a chain of functions that change the size, position, event handling, and appearance of a component. The order of modifiers in the chain matters: clickable.semantics works differently than semantics.clickable, and padding.background paints both the area and the background including padding, which is critical when designing.

Inside a Composable function, you can use if and when conditions for conditional rendering of UI parts, as well as for loops for dynamic lists. All these constructs work naturally because Kotlin is a full-fledged programming language. However, it is important to remember: if a condition or loop contains Composable function calls, they also participate in recomposition.

@Composable
fun ProductList(
    products: List<Product>,
    modifier: Modifier = Modifier
) {
    LazyColumn(modifier = modifier) {
        items(products, key = { it.id }) { product ->
            ProductItem(
                product = product,
                onAddToCart = { /* add to cart */ }
            )
        }
    }
}

Composable Function Examples for Real Screens

Let’s consider an example of a product search screen using several Composable functions. Typical patterns are shown here: an input field with state, list filtering, handling of empty results, and loading.

data class Product(
    val id: String,
    val name: String,
    val price: Double,
    val category: String
)

@Composable
fun SearchScreen() {
    var query by remember { mutableStateOf("") }
    val products = remember(query) { getFilteredProducts(query) }

    Column(modifier = Modifier.fillMaxSize().padding(16.dp)) {
        OutlinedTextField(
            value = query,
            onValueChange = { query = it },
            label = { Text("Search products") },
            modifier = Modifier.fillMaxWidth()
        )

        Spacer(modifier = Modifier.height(16.dp))

        when (products) {
            is Loading -> CircularProgressIndicator()
            is Empty -> Text("No results found")
            is Result -> LazyColumn {
                items(products.items, key = { it.id }) { product ->
                    ProductItem(product = product, onAddToCart = {})
                }
            }
        }
    }
}

This example demonstrates several idioms at once: remember for preserving the search query state, remember(query) for filtering with a key, when for three UI states, and LazyColumn for efficient list rendering. Each of these idioms is the result of practical experience in developing Compose applications.

Parameters and Slot API

Composable functions accept parameters just like regular Kotlin functions, but with one important difference: a parameter can be another Composable function passed through a lambda with the @Composable annotation. This mechanism is called Slot API and is the main pattern for creating reusable containers.

The Slot API solves the problem that in the traditional View system was solved through ViewGroup and adding child Views programmatically. Instead of addView methods, Compose uses content lambdas — the last parameter with the @Composable () -> Unit type. The caller passes any UI into this lambda, and the container only defines its layout.

Composable function parameters can have default values, which simplifies their use in different contexts. It is recommended to make required only those parameters without which the function cannot perform its task, and provide reasonable default values for the rest.

Composable Function Idioms in Kotlin

Several established idioms have emerged in the Compose community that make Composable functions more readable and predictable. The first is State Hoisting: the state is lifted to a higher level, and the Composable function receives it through parameters. This makes the function pure and reusable in different contexts.

The second idiom is Event-driven parameters. Instead of passing a ViewModel or useCase to a Composable function, only specific callbacks are passed: onSave, onDelete, onNavigateToDetail. This reduces coupling and simplifies testing — a test for ProductItem does not need a ViewModel, only a lambda stub.

The third idiom is CompositionLocal for passing shared data through the composition tree. Theme, screen density, current Route — all of this is passed through CompositionLocal, avoiding parameter chains through dozens of Composable functions. However, CompositionLocal should not be overused: explicit parameters are always preferable to implicit dependencies.

// State Hoisting: state lifted to the parent function
@Composable
fun CounterDisplay(
    count: Int,
    onIncrement: () -> Unit
) {
    Column(horizontalAlignment = Alignment.CenterHorizontally) {
        Text(text = "Counter: $count", style = MaterialTheme.typography.headlineLarge)
        Button(onClick = onIncrement) {
            Text("+1")
        }
    }
}

// Usage with State Hoisting
@Composable
fun CounterScreen() {
    var count by remember { mutableStateOf(0) }
    CounterDisplay(
        count = count,
        onIncrement = { count++ }
    )
}