Composable Function: wat is het, functiesyntaxis en regels

Auteur: IT Sectr Gepubliceerd: 2026-06-27 Leestijd: 8 min

Composable Function — is de fundamentele eenheid van de gebruikersinterface in Jetpack Compose, die bepaalt hoe een deel van het scherm eruit moet zien en zich moet gedragen. Elke dergelijke functie is gemarkeerd met de @Composable annotatie en wordt uitgevoerd in een speciale context, waardoor Compose afhankelijkheden kan bijhouden en automatisch de UI kan herbouwen wanneer gegevens veranderen. Volgens Google Android Developers, 2026, beïnvloedt het correct opbouwen van Composable-functies direct de prestaties van de applicatie en de efficiëntie van recompositie.

Belangrijkste punten

  • Composable Function — Kotlin-functie met @Composable annotatie die UI-boom bouwt
  • Parameters moeten onveranderlijk zijn, veranderlijke gegevens via state
  • Aanroep is alleen mogelijk vanuit de context van een andere Composable-functie
  • Volgorde van uitvoering is niet gegarandeerd — elke functie moet onafhankelijk zijn
  • Modifier wordt aanbevolen om als parameter door te geven voor aanpassing

Wat is Composable Function in Jetpack Compose

Composable Function — is een functie in de programmeertaal Kotlin, gemarkeerd met de @Composable annotatie, die een deel van de gebruikersinterface op een declaratieve manier beschrijft. In plaats van View-objecten te maken en te configureren via Java-code of XML-markup, schrijft de ontwikkelaar eenvoudigweg hoe de UI eruit moet zien bij elke gegevenstoestand.

Het belangrijkste verschil tussen een Composable-functie en het traditionele Android View-systeem zit in het updatemodel. In de klassieke benadering riep de ontwikkelaar handmatig findViewById aan, wijzigde tekst via setText, beheerde zichtbaarheid via setVisibility. Composable Function bevrijdt van deze routine: bij gegevenswijziging bepaalt het systeem zelf welke functies opnieuw moeten worden gestart en voert alleen deze uit.

De Kotlin-compiler genereert bij het verwerken van de @Composable annotatie extra code die de functie integreert in het compositiemechanisme. Deze code omvat het lezen en schrijven naar slots — speciale geheugencellen die de status en parameters van elke Composable-functie in de huidige UI-boom opslaan. Dankzij deze integratie weet Compose welke functies van welke gegevens afhankelijk zijn.

Syntaxis van het declareren van een Composable-functie

De syntaxis van een Composable-functie is uiterst beknopt: voeg gewoon @Composable toe voor het sleutelwoord fun. De functie kan elke parameter accepteren, andere Composable-aanroepen in zijn lichaam bevatten en Kotlin-constructies gebruiken — condities, loops, when-expressies — voor voorwaardelijke weergave van UI.

kotlin
@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("Toevoegen aan winkelwagen")
            }
        }
    }
}

In dit voorbeeld accepteert de Composable-functie ProductItem een Product-object, een modifier en een callback. Alle drie parameters zijn onveranderlijk, wat voorspelbaar gedrag garandeert bij recompositie. De modifier is doorgegeven als parameter met een standaardwaarde — dit is een standaardpraktijk die de aanroepende partij in staat staat om marges en afmetingen aan te passen.

Componenten en modifiers in Composable-functies

Binnen een Composable-functie worden ingebouwde Material Design-componenten (Text, Button, Card, TextField) of fundamentele primitieven (Canvas, Layout) gebruikt. Elke component accepteert parameters voor het configureren van uiterlijk en gedrag, en een of meer modifiers via de modifier-parameter.

Modifiers — zijn een keten van functies die de grootte, positie, gebeurtenisafhandeling en het uiterlijk van een component wijzigen. De volgorde van modifiers in de keten is belangrijk: clickable.semantics werkt anders dan semantics.clickable, en padding.background kleurt de achtergrond van het gebied inclusief padding, wat cruciaal is bij het ontwerpen.

Binnen een Composable-functie kunnen if- en when-condities worden gebruikt voor voorwaardelijke weergave van UI-delen, en for-loops voor dynamische lijsten. Al deze constructies werken van nature, omdat Kotlin een volwaardige programmeertaal is. Het is echter belangrijk te onthouden: als de conditie of loop aanroepen van Composable-functies bevat, nemen deze ook deel aan de recompositie.

kotlin
@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 */ }
            )
        }
    }
}

Voorbeelden van Composable-functies voor echte schermen

Laten we een voorbeeld bekijken van een productzoekscherm met behulp van meerdere Composable-functies. Hier worden typische patronen getoond: invoerveld met status, filteren van de lijst, afhandeling van leeg resultaat en laden.

kotlin
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("Producten zoeken") },
            modifier = Modifier.fillMaxWidth()
        )

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

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

Dit voorbeeld demonstreert meerdere idiomen tegelijk: remember voor het opslaan van de zoekopdrachtstatus, remember(query) voor filteren met sleutel, when voor drie UI-toestanden en LazyColumn voor efficiënte lijstweergave. Elk van deze idiomen is het resultaat van praktische ervaring in het ontwikkelen van Compose-applicaties.

Parameters en Slot API

Composable-functies accepteren parameters net als gewone Kotlin-functies, maar met één belangrijk verschil: een parameter kan een andere Composable-functie zijn die wordt doorgegeven via een lambda met @Composable annotatie. Dit mechanisme heet Slot API en is het belangrijkste patroon voor het maken van herbruikbare containers.

Slot API lost het probleem op dat in het traditionele View-systeem werd opgelost via ViewGroup en het programmatisch toevoegen van kind-Views. In plaats van addView-methoden gebruikt Compose content-lambdas — de laatste parameter met het type @Composable () -> Unit. De aanroepende partij geeft elke UI door aan deze lambda, en de container zelf bepaalt alleen de plaatsing ervan.

Parameters van een Composable-functie kunnen standaardwaarden hebben, wat het gebruik ervan in verschillende contexten vereenvoudigt. Het wordt aanbevolen alleen die parameters verplicht te maken zonder welke de functie zijn taak niet kan uitvoeren, en de andere te voorzien van redelijke standaardwaarden.

ParameterTypeVoorbeeld
VerplichtElk typename: String
OptioneelMet standaardwaardemodifier: Modifier = Modifier
Content@Composable () -> Unitcontent: @Composable () -> Unit
CallbackLambda zonder @ComposableonClick: () -> Unit

Idiomen van Composable-functies in Kotlin

In de Compose-gemeenschap zijn verschillende gevestigde idiomen ontstaan die Composable-functies leesbaarder en voorspelbaarder maken. De eerste — State Hoisting: de status wordt naar een hoger niveau getild en de Composable-functie ontvangt deze via parameters. Dit maakt de functie puur en herbruikbaar in verschillende contexten.

Het tweede idioom — Event-driven parameters. In plaats van ViewModel of useCase door te geven aan de Composable-functie, worden alleen specifieke callbacks doorgegeven: onSave, onDelete, onNavigateToDetail. Dit vermindert koppeling en vereenvoudigt testen — voor het testen van ProductItem is geen ViewModel nodig, alleen een lambda-stub.

Het derde idioom — CompositionLocal voor het doorgeven van gemeenschappelijke gegevens door de compositieboom. Thema, schermdichtheid, huidige route — dit alles wordt doorgegeven via CompositionLocal, waardoor parameterketens door tientallen Composable-functies worden vermeden. Men moet CompositionLocal echter niet misbruiken: expliciete parameters hebben altijd de voorkeur boven impliciete afhankelijkheden.

kotlin
// State Hoisting: status verhoogd naar bovenliggende functie
@Composable
fun CounterDisplay(
    count: Int,
    onIncrement: () -> Unit
) {
    Column(horizontalAlignment = Alignment.CenterHorizontally) {
        Text(text = "Teller: $count", style = MaterialTheme.typography.headlineLarge)
        Button(onClick = onIncrement) {
            Text("+1")
        }
    }
}

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

Veelgestelde vragen

Kan return worden gebruikt in een Composable-functie?

Ja, return is toegestaan, maar met voorzichtigheid. Compose optimaliseert recompositie op het niveau van individuele functies en een vroege return kan deze optimalisatie verstoren. Het is beter om voorwaardelijke operatoren if of when in het functielichaam te gebruiken.

Wat is het verschil tussen Unit-return en void in Java?

In Kotlin is Unit een singleton-object, geen leeg type. Composable-functies retourneren Unit, wat technisch betekent dat ze het Unit-object zelf retourneren. In de praktijk maakt dit echter niet uit — de retourwaarde wordt genegeerd door het compositiesysteem.

Kan mutableListOf worden doorgegeven aan een Composable-functie?

Het doorgeven van veranderlijke collecties is mogelijk, maar het is een slechte praktijk. Als de collectie verandert, zal Compose dit niet weten omdat de referentie naar het object hetzelfde blijft. Gebruik immutable lijsten of mutableStateListOf voor te volgen wijzigingen.

Hoe debug ik een Composable-functie?

Gebruik voor debugging Android Studio met Layout Inspector, die de huidige boom van Composable-functies, parameterwaarden en redenen voor recompositie toont. Ook de gewone Kotlin-debugger werkt — breekpunten binnen Composable-functies worden correct geactiveerd bij elke recompositie.

Is het verplicht om het return type van een Composable-functie te specificeren?

Een Composable-functie retourneert altijd Unit, dus het return type wordt niet gespecificeerd. Een poging om een ander type te retourneren zal een compilatiefout veroorzaken, omdat de @Composable annotatie niet compatibel is met niet-Unit retourtypes.

Samenvatting

  • Composable Function — declaratieve bouwsteen van UI, gemarkeerd met @Composable
  • Parameters moeten onveranderlijk zijn voor voorspelbare recompositie
  • Modifiers en Slot API bieden flexibiliteit en herbruikbaarheid zonder overerving
  • State Hoisting — status naar boven tillen voor zuiverheid en testbaarheid
  • Event-driven callbacks verminderen koppeling met ViewModel en bedrijfslogica
  • CompositionLocal wordt gebruikt voor gemeenschappelijke gegevens, maar expliciete parameters hebben de voorkeur
  • Idiomen Compose maken code voorspelbaar, testbaar en performant

We ontwikkelen een mobiele applicatie turnkey

IT Sectr creëert sinds 2017 iOS- en Android-applicaties voor startups en bedrijven. We adviseren u en stellen de beste oplossing voor.

Bespreek het project

Lees ook