Modifiers should have default parameters in Compose

[Wadeewee]

What happened

Currently, we are not aware of providing a Modifier parameter in the element function's parameter list when we create a Compose function:

Why should we have default parameters in Compose? 💭 Here's the reason why we should have it: 👇

• Modifier document official ⬅️ See more

  Composables that accept a Modifier as a parameter to be applied to the whole component represented by the composable function should name the parameter modifier and assign the parameter a default value of Modifier. It should appear as the first optional parameter in the parameter list; after all required parameters (except for trailing lambda parameters) but before any other parameters with default values. Any default modifiers desired by a composable function should come after the modifier parameter's value in the composable function's implementation, keeping Modifier as the default parameter value.

• A best practice from API Guildeline for Jetpack Compose ⬅️ See more

  Elements accept and respect a Modifier parameter

  Element functions MUST accept a parameter of type Modifier. This parameter MUST be named “modifier” and MUST appear as the first optional parameter in the element function's parameter list. Element functions MUST NOT accept multiple Modifier parameters.

• Jetpack Compose in Compass, We also have the rule in compass, but we don't have a part of the example what should we be aware of it.

• Twitter Compose Rules, This's a good guideline from Twitter to make it easier for us to understand. So, Let's dive deep into the concept. 🚗 💨

  When should we expose modifier parameters? 🤔

  Modifiers are the beating heart of Compose UI. They encapsulate the idea of composition over inheritance, by allowing
  developers to attach logic and behavior to layouts.

  They are especially important for your public components, as they allow callers to customize the component to their wishes.

  What should we be aware of it? 🚨

  Don't re-use modifiers

  Modifiers which are passed in are designed so that they should be used by a single layout node in the composable function. If
  the provided modifier is used by multiple composables at different levels, unwanted behaviour can happen.

  How should we implement it? ⚒

  In the following example we've exposed a public modifier parameter, and then passed it to the root Column, but we've also
  passed it to each of the descendant calls, with some extra modifiers on top:

   @Composable
   private fun InnerContent(modifier: Modifier = Modifier) {
       Column(modifier) {
           Text(modifier.clickable(), ...)
           Image(modifier.size(), ...)
           Button(modifier, ...)
       }
   } 

  This is not recommended. Instead, the provided modifier should only be used on the Column. The descendant calls should
  use newly built modifiers, by using the empty Modifier object:

   @Composable
   private fun InnerContent(modifier: Modifier = Modifier) {
       Column(modifier) {
           Text(Modifier.clickable(), ...)
           Image(Modifier.size(), ...)
           Button(Modifier, ...)
       }
   } 

More ref:

• Basic layouts in Compose
• Always provide a Modifier parameter

Who Benefits?

Developers

What's Next?

• Always provide a default parameter modifier: Modifier = Modifier when we create a Compose function.
• Update the rule for Modifier to add the part of what should we be aware of it in Jetpack Compose in Compass.

[luongvo]

@Wadeewee Voted 👍

[chornerman]

@Wadeewee Voted 🚀

[lydiasama]

Voted. 🙌🏻

[toby-thanathip]

@Wadeewee Voted, good job on providing the resources 🚀

Note: Enough votes have been made 🌟

[toby-thanathip]

@ryan-conway @Wadeewee Should we resolve/lock this discussion only after the issue has been created?

I'm worried we might forget about it otherwise 🙇

[ryan-conway]

Issue created here