Hi all, I've been learning about Compose and found the docs make an incorrect claim that they are pure functions: https://android.googlesource.com/platform/frameworks/support/+/androidx-master-dev/compose/README.md I've sent a pull request to fix that: https://android-review.googlesource.com/c/platform/frameworks/support/+/958319 Would be great to get someone to review that.

+2

Thanks!

Yes I was also thinking that during presentation

The point we were trying to make is that the only side-effect the function should have is producing the tree. There isn't really a well understood term for that. The closest is monad but then only 5 people know what that means.

Why not: fun Greeting(name: String): Composable { return Text(text = "Hello $name") }

@Chuck Jazdzewski [G] partially pure functions, then?

The closest is monad but than only 5 people know what that means

But who would think that so many people know what pure function means and now they are giving you hard time for not being transparent... referentially 🧌

@themishkun Pragmatically pure :)

@romainguy yeah, kotlin fans LOVE the word "pragmatically" :)

@Jeremy That would work and is the approach take by React and Flutter. However, there is more opportunity for optimization along the line we took. For example if "name" is the same on recomposition we can skip the call entirely. We don't need to compare its result from last time to tell that it doesn't change. This is similar to the approaches taken by, for example, Ember and Angular.

@Chuck Jazdzewski [G] is this really takes so much work to compare two `id`s in two generated data structures? In my team most screens consist of root recyclerviews with adapters for buttons, galleries, texts and titles, etc. and we see no perfomance impact on that.

🤔 I think I just need to dig into more. Its just less clear from example what its actually doing

The

RecyclerView

is doing a lot of work behind the scenes to deliver this performance.

Is there any examples of unit tests? If multiple tests are executing does any global state need to be reset?

@Jeremy There are many unit tests in the repository and they can be found in the

androidTest

directory of the various modules. The memoization information is stored in the composer's slot table and is local for the composition. It is not global. However, currently we use a global to simplify the code generation of composable functions so only one composition can be occurring at a time. We plan to change this to rewrite composable functions to take the composer as a parameter. This will remove global as well as speed up composition.

Thanks for response. I'll dig through the androidTest code a bit more

There will be a synthetic function produced with the parameter. The API will remain that same at the source level. We will redirect calls to composable functions to the synthetic.

Sorry I missed the chatter here. It's definitely not monadic either. I don't think we should try to use any FP terms since the FP zealots will freak out. I'm not quite a zealot, just an advocate of using terms correctly.