7 things to keep in mind while building jetpack composable’s.

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.

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.

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.

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.

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.

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.

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).

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 atoms as possible.

Thanks for reading, if you have my articles feel free to subscribe to my newsletter or share the article.