With the introduction to Compose Google changed the way we wrote UIs in android. This lead to a bit of learning curve for developer meaning not all would start at the same page. Which is what happened here at SuperShare. So how do we manage to keep code in check? We’ll these are some of the checks we make for composable’s.
Always provide a modifier.
Any composable that provides a layout should always have a modifier as one of its parameters. This is so that who ever is consuming the composable can then modify the size, padding, background, etc… to match the rest of the screen.
| // ❌ | |
| @Composable | |
| fun HelloWorld() { | |
| Column { | |
| Text("Hello") | |
| Text("World") | |
| } | |
| } | |
| // ✅ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier) { | |
| Column(modifier = modifier) { | |
| Text("Hello") | |
| Text("World") | |
| } | |
| } |
Don’t emit to parent.
Make sure your composable layout are always packed inside a layout like column, row, box, etc… This is to prevent the recomposition of the whole parent layout.
| // ❌ | |
| @Composable | |
| fun HelloWorld() { | |
| Text("Hello") | |
| Text("World") | |
| } | |
| // ✅ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier) { | |
| Column(modifier = modifier) { | |
| Text("Hello") | |
| Text("World") | |
| } | |
| } | |
| // ✅ | |
| @Composable | |
| fun ColumnScope.HelloWorld() { | |
| Text("Hello") | |
| Text("World") | |
| } |
Don’t emit and return result.
Your composable should always have a single responsibility. Meaning it should either render a layout or return a value but should not do both at the same time.
| // ❌ | |
| @Composable | |
| fun HelloWorld(): String { | |
| Text("Hello") | |
| Text("World") | |
| return remember { "HelloWorld" } | |
| } | |
| // ✅ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier) { | |
| Column(modifier = modifier) { | |
| Text("Hello") | |
| Text("World") | |
| } | |
| } | |
| // ✅ | |
| @Composable | |
| fun rememberHelloWorld(): String { | |
| return remember { "Hello World" } | |
| } |
Say No MutableState as parameter.
Avoid passing mutable types as parameters because that MutableState could also be listened upon by other composable and changing the value in one place to cascade into multiple composable re-rendering. Instead use Generic types.
| // ❌ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier, sayHi: MutableState<String>) { | |
| Column(modifier = modifier) { | |
| Text(sayHi.value) | |
| } | |
| } | |
| // ✅ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier, sayHi: String) { | |
| Column(modifier = modifier) { | |
| Text(sayHi) | |
| } | |
| } |
Always use remember in your composable’s.
Recomposition can trigger anytime due to a bunch or reasons. If we have a value that was supposed to survive a recomposition then remember helps you retain it across recomposition.
| // ❌ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier) { | |
| val message = "Hello World" | |
| Column(modifier = modifier) { | |
| Text(message) | |
| } | |
| } | |
| // ✅ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier) { | |
| val message by remember { mutableStateOf("Hello World") } | |
| Column(modifier = modifier) { | |
| Text(message) | |
| } | |
| } |
Don’t reuse modifier instance.
The modifier that was passed as a parameter to the composable should only be used on the top level layout of the composition. We can add properties to it but we should not reuse them internally for other components the layout contains. This could break your code.
| // ❌ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier) { | |
| Column(modifier = modifier) { | |
| Text("Hello World", modifier = modifier.padding(8.dp)) | |
| } | |
| } | |
| // ✅ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier) { | |
| Column(modifier = modifier) { | |
| Text("Hello World", modifier = Modifier.padding(8.dp)) | |
| } | |
| } |
Job Offers
OUR VIDEO RECOMMENDATION
Jobs
Don’t use AndroidView for composable views.
If a view already has a composable view. There is no point in rendering it via AndroidView. The AndroidView is only to be used in case of view not having a composable implementation (3rd party libs and custom views for the most part right now).
| // ❌ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier) { | |
| Column(modifier = modifier) { | |
| AndroidView(::TextView){ ... } | |
| } | |
| } | |
| // ✅ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier) { | |
| Column(modifier = modifier) { | |
| Text(...) | |
| } | |
| } |
Bonus: No ViewModel in the composable.
We prefer not passing ViewModel into the composable as we want them to be as dumb as possible and broken down to the smallest of organism as possible.
| // ❌ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier, viewModel: HelloWorldViewModel) { | |
| Column(modifier = modifier) { | |
| Text(viewModel.sayHi) | |
| } | |
| } | |
| // ✅ | |
| @Composable | |
| fun HelloWorld(modifier: Modifier = Modifier, sayHi: String) { | |
| Column(modifier = modifier) { | |
| Text(sayHi) | |
| } | |
| } |
Feel free to drop a clap or comment or reach out to me on LinkedIn, Twitter, Website.
This article was originally published on proandroiddev.com on May 02, 2022
