Recomposition happens twice!

[hadilq]

I just pushed source code of a sample here. Everything looks good, except that if you run the code, and click the buttons, you'll see in the Logcat that recomposition is happening twice, once because we launched an action, which is expected, but the other one appeared to happen because of changing of the return value of the nested compose, which is unexpected! I made a workaround for the "previous page" button by launching two actions in a row!

    sealed interface PopStack : MainAction {
        object Flip : PopStack
        object Flop : PopStack
    }

To clarify the problem, I created this commit, so just check out to the-infinit-loop-problem branch. In this branch, after clicking the "previous page" button, it'll call the MainPresenter in some kind of a loop until the stack becomes empty! How can I avoid that infinit loop? Pull requests are welcome. By the way, thanks guys for this awesome library.

[mattprecious]

It looks like you have a lot of side-effects that are not contained within effects. This is likely causing or contributing to the issue. Please take a look at Side-effects in Compose.

[hadilq]

Thanks, but can you mention one of them? This sample doesn't have any IO call! No network or disk access, just the UI, which I cannot think of a way to launch a UI action as an affect! Just give me one example.

[mattprecious]

I misunderstood what your code was doing. The particular thing I thought was a side effect is not, at least not directly.

I believe the issue here is that you're passing in "actions" as parameters to composable functions, which has a side-effect on the upstream code, causing recomposition. Your MainPresenter is being composed with the Flop action, which then returns an updated MainState, which then re-composes MainPresenter with the new state and the old Flop action, which then executes the action again.

Actions are transient and should be handled within callbacks or effects. Instead of accepting an action as a parameter, you would accept a Flow<Action> and then use a LaunchedEffect:

LaunchedEffect {
  actions.collect {
    when (action) {
      // ...
    }
  }
}

This isn't a comprehensive code snippet because you need to do a lot of restructuring of your project.

This is an issue with your code at the Compose level. Molecule isn't contributing to this.

[hadilq]

Thank you. This is exactly what's implemented in the sample of Molecule in this repository. I want to follow these steps, but I have two problems!

• I need to somehow map the actions flow and pass it to the nested composables, which I can make it work I think!
• I need to call the nested composables in the LaunchEffect, which I have no idea how! In fact it looks like impossible!

do you have any idea?

[hadilq]

I think I can solve both of those problems. Will post here!

[hadilq]

I just merged hadilq/molecule-sample-app#1 and here is the update:

• As suggested above, I used Flow<Action> to steam the actions and used LaunchedEffect to collect them.
• It's using a variable named downstreamStates in all presenter composables to propagate the state, instead of returning the state by the composable functions, because I concluded returning states would trigger the recomposition, which is unnecessary!
• To hide the boilerplate code, I created some helper functions, that if you are agree, I'll create a PR and merge them to Molecule.

The main reason I created that sample is scoping the logic tree by using compose, so Build a StateFlow or Flow stream using Jetpack Compose that mentioned in the README of Molecule is irrelevant, IMHO! That's also why I ignored that feature all together and used the downstreamStates instead. I think compose is so good at scoping the logic tree that you should mention it in the README file.

[JakeWharton]

If you are referring to the remember-prefixed functions in that PR, they are not specific to Molecule and could be used with any Compose-based system (such as when working with Compose UI). We generally don't want to include anything but the bare minimum for running Compose outside of Compose UI. Any general-purpose helper functions should be in Compose itself or a third-party library that can be used with any Compose-based library.

[hadilq]

Thank you for your response. Totally makes sense.