Relationship between molecule and Compose UI

[eygraber]

Considering the common confusion around Compose / Compose UI it might be helpful to add a small section to the README explaining the relationship between molecule and Compose UI:

• You don't need to use Compose UI in order to use molecule
• If your app is fully Compose UI you don't necessarily need to use molecule
  • If you don't need the output to be a StateFlow you don't need molecule and can call "presenter" functions (from Compose UI's composition) that return a State<T>
  • <Are there any pros to using molecule in this scenario?>
  • <Are there any cons to using molecule in this scenario?>
    • <The only one I can think of is increased complexity (however small) by introducing a new dependency, having an additional composition, etc...>

[ganfra]

To the question : Are there any cons to using molecule in this scenario?
I found using rememberSaveable wasn't working when the instance holding the moleculeScope is destroyed/recreated.
But maybe I did something wrong with my config.

[StylianosGakis]

Using molecule also gives you the power to scope that work to whatever class you're going to be holding it in. For example, as the PR here #274 shows, you can scope your molecule presenter to your AAC ViewModel, meaning that if the UI for whatever reason gets destroyed, like in a config change situation, your molecule presenter would persist for until the new UI comes on the screen after the config change.

So don't think it's as simple as, you're using compose UI -> No need for molecule.

[ganfra]

Using molecule also gives you the power to scope that work to whatever class you're going to be holding it in. For example, as the PR here #274 shows, you can scope your molecule presenter to your AAC ViewModel, meaning that if the UI for whatever reason gets destroyed, like in a config change situation, your molecule presenter would persist for until the new UI comes on the screen after the config change.

So don't think it's as simple as, you're using compose UI -> No need for molecule.

If you have a full compose UI app, most of the config changes are already handled at the Compose level, so you can avoid destroying the activity. Plus this is more the responsability of the data/domain layer to handle this properly instead of AAC ViewModel...

[StylianosGakis]

If you have a full compose UI app, most of the config changes are already handled

The key word here is "most", not all of them. So still relevant.