Compose Basics: Stability Configuration File for Multi Module

Hello folks ✌️,

Class stability is a core concept we must know when it comes to understanding and improving performance⚡️in Compose. If you are not sure what is that about, read this first.

In brief words:

Compose considers types to be either stable or unstable. A type is stable if it is immutable, or if it is possible for Compose to know whether its value has changed between recompositions. A type is unstable if Compose can’t know whether its value has changed between recompositions.

Compose uses the stability of a composable’s parameters to determine whether it can skip the composable during recomposition.

There are some cases in which Compose can't ensure that the state was unchanged:

• It contains a mutable property,
• It contains a property wrapped in an unstable class like List,
• The class is in a different module and that module does not run the compose compiler.

In this article, we are covering how to solve the last case using a new approach introduced in the version 1.5.5 of the Compose Compiler: The Stability Configuration file.

To illustrate how to take advantage of this new feature, let's take a look at this diagram of a modularized app.

In the :feature:login module, representing the ui layer, built in Compose, you might be using some classes from the :models or the :data module, like the User model or DTO.

The issue is that Compose will flag User as unstable, because it is on a different module. Causing unnecessary recompositions, therefore affecting the performance.

You have two ways to solve this: The first is enabling the compose compiler in :models or :data. And the second is defining a rule for those modules in the Stability Configuration file.

Let's create the compose_compiler_config.conf file in the root folder of the project:

We specify that all the classes under the models and data packages should be marked as stable whenever possible. I'm assuming that the package name is the same as the module name. You might need to adjust it if your package name is different than your module name.

The next step is to specify this file in the kotlinOptions block in the build.gradle.kts file:

Just like that, being on a different module will no longer be a limitation to consider a class stable.

This is not limited to your classes, you can also specify standard library classes in the file:

Important Considerations

• This approach doesn't guarantee that the classes will be marked as stable if it contains a mutable or unstable property. This will only remove the different module limitation.
• You can specify different config files for different modules or just having a common config file for all your modules, like in the example above
• The stability config file is a better approach because that is one less module to run the compose compiler on, reducing the build time

To learn more about fixing stability issues, read this page.

If this helped you, please drop a like 👍🏻, a comment 📝 and share it 🔗 with your colleagues.

See you in the next one ✌🏼

Stackademic 🎓

Thank you for reading until the end. Before you go:

• Please consider clapping and following the writer! 👏
• Follow us X | LinkedIn | YouTube | Discord
• Visit our other platforms: In Plain English | CoFeed | Venture | Cubed
• More content at Stackademic.com