Bonnes pratiques et pratiques à éviter avec les styles

Cette page décrit les bonnes pratiques à suivre pour travailler avec des styles qui assurent la cohérence de votre code, ainsi que les principes que nous avons suivis lors de la conception des API.

Conseillé

Appliquez les bonnes pratiques suivantes :

À faire : utiliser des styles pour les éléments visuels et des modificateurs pour les comportements

Utilisez l'API Styles pour la configuration visuelle (arrière-plans, marges intérieures, bordures) et réservez les modificateurs pour les comportements tels que la logique de clic, la détection des gestes ou l'accessibilité.

À faire : exposer les paramètres de style dans les systèmes de conception

Pour vos propres composants de système de conception personnalisés, vous devez exposer un objet Style après le paramètre de modificateur.

@Composable
fun GradientButton(
    modifier: Modifier = Modifier,
    // ✅ DO: for design system components, expose a style modifier to consumers to be able to customize the components
    style: Style = Style
) {
    // Consume the style
}
DosDonts.kt

À faire : remplacer les paramètres visuels par un style

Envisagez de remplacer les paramètres de vos composables par un seul paramètre Style. Exemple :

// Before
@Composable
fun OldButton(background: Color, fontColor: Color) {
}

// After
// ✅ DO: Replace visual-based parameters with a style that includes same properties
@Composable
fun NewButton(style: Style = Style) {
}
DosDonts.kt

À faire : privilégier les styles pour les animations

Utilisez le bloc animate intégré pour appliquer un style basé sur l'état avec des animations afin d'améliorer les performances par rapport aux modificateurs.

À faire : profitez de la règle "La dernière écriture l'emporte"

Profitez du fait que les propriétés style écrasent les propriétés précédentes au lieu de s'empiler. Utilisez-le pour remplacer les bordures ou les arrière-plans des composants par défaut sans avoir besoin de plusieurs paramètres.

Déconseillé

Les formats suivants sont déconseillés :

Ne pas utiliser de styles pour la logique d'interaction

N'essayez pas de gérer la détection de onClick ou de gestes dans un style. Les styles sont limités aux configurations visuelles basées sur l'état. Ils ne doivent donc pas gérer la logique métier, mais uniquement avoir un visuel différent en fonction de l'état.

À ne pas faire : fournir un style par défaut en tant que paramètre par défaut

Les paramètres de style doivent toujours être déclarés à l'aide de style: Style = Style :

@Composable
fun BadButton(
    modifier: Modifier = Modifier,
    // ❌ DON'T set a default style here as a parameter
    style: Style = Style { background(Color.Red) }
) {
}
DosDonts.kt

Pour inclure un paramètre "par défaut", fusionnez le style de paramètre entrant avec celui défini par défaut :

@Composable
fun GoodButton(
    modifier: Modifier = Modifier,
    // ✅ Do: always pass it as a Style, do not pass other defaults
    style: Style = Style
) {
    // ...
    val defaultStyle = Style { background(Color.Red) }
    // ✅ Do Combine defaults inside with incoming parameter
    Box(modifier = modifier.styleable(styleState, defaultStyle, style)) {
      // your logic
    }
}
DosDonts.kt

À éviter : fournir des paramètres de style aux composables basés sur la mise en page

Bien que vous puissiez fournir un style à n'importe quel composable, il n'est pas prévu que les composables basés sur la mise en page ou les composables au niveau de l'écran acceptent un style. Du point de vue du consommateur, l'effet d'un style à ce niveau n'est pas clair. Les styles sont conçus pour les composants, et pas nécessairement pour les mises en page.