Does every composable necessarily create UI?

# compose

[Mehdi Haghgoo]

Does every composable necessarily create UI?

[Halil Ozercan]

are you trying to summon Jake?

[Halil Ozercan]

Joking aside, the answer is no. Composables can return state, launch effects, etc. without drawing any UI at all.

[Denis]

Are there any public use cases for non-UI Composables?

[kioba]

stringResource

[Denis]

I thought maybe somebody could expand on what kind of projects are possible with it

Each of my three projects built on Compose do not use the new Compose UI toolkit.

https://jakewharton.com/a-jetpack-compose-by-any-other-name/

[jw]

The output of a Composable function call hierarchy is a tree of objects which have properties. What you do with those objects is up to you and your imagination.

[Denis]

What you do with those objects is up to you and your imagination

Yeah... That's exactly what I have problems with 😃

[jw]

You could build serialization trees and then send only diffs as the tree changes. You could use it as the output of your presentation layer and send diffs to the UI layer. You could target alternative UI rendering such as the View tree, RemoteView, Slices, GL, etc.

[jw]

You could maintain a binary tree and have an invert: Boolean and ace the Google interview

[Denis]

Thanks, Jake. I'm gonna meditate on this quote tonight: "The output of a Composable function call hierarchy is a tree of objects which have properties"

[jw]

Think about it like this: for Views, we imperatively instantiated objects and added them to their parents in code to create a tree. Or, we use a declarative tool like XML to do it for us. That tree was made up of objects which happen to know how to render themselves to a canvas. Each has properties to control things like text color, alignment, whatever.

Compose UI is very similar to Android Views in that regard. It's a tree of objects which have properties that happen to know how to render themselves. You could create a tree of them imperatively like we did with Android Views! But Compose UI also ships with Composables that allow us to declaratively build that tree using function calls instead of XML.

If we wanted to, we could build an XML schema that produced Compose UI trees. We also could create Composable functions that produced Android View trees. The difference is that the view system was tailored for XML whereas Compose UI is tailored for Composables.

[Mehdi Haghgoo]

@jw I am not sure if I get what you mean by "you could create a tree them (Compose objects) imperatively Like we did with Android views".

[jw]

Sure. The output of Compose UI's composable functions is a tree of objects which are called LayoutNode. They're somewhat akin to a View in the old system. If you wanted you could create and assign properties to all the LayoutNodes yourself, just like old views.