Passing `Resources` into a composable as a parameter? :thumbsup: or :thumbsdown:

# compose

[Colton Idle]

Passing Resources into a composable as a parameter?

👍 or 👎

[Adam Powell]

to get what out of it?

[Colton Idle]

In this case, I have a composable that is putting three `Image`s next to each other + a piece of text. Image takes a bitmap = imageFromResource(resources, R.drawable.image1)

Which is weird since the same composable also has Text() with text = stringResource(id = R.string.mystring)

So really only images require a Resource

[Adam Powell]

If that's just the android framework Resources object I wouldn't bother over just doing AmbientContext.current.resources where you need it. The benefits you'd usually get from making it a parameter can't really materialize since both Context and Resources objects in Android are so weird and tied to requirements that the system gives you one and you can't meaningfully construct your own to alter behavior like other dependencies

[Adam Powell]

If this is your own resources type that gives you a different abstraction over what you need, the answer changes

[Adam Powell]

One thing some teams at Google are finding is that there's a measurable performance difference between doing one off resource loads from the simple compose loading functions vs the batch context.obtainStyledAttributes calls that views perform at construction. The batch operations have less overhead

[Adam Powell]

In most cases it's fine but it's a question of how it scales

[Adam Powell]

So if you had a type specific to your app that performed the batch load instead, you'd get a bit of a perf bump on the whole and a more compose friendly dependency to work with

[Adam Powell]

All of these things are things we'd like to explore further for compose android APIs, but some of the things we'd like to do would be better accomplished in closer collaboration with the aapt and resource tooling in the long run, so some of the existing APIs are of the, "simplest thing that can work" variety, leaving the door open to more in the future

[Colton Idle]

If that's just the android framework Resources object I wouldn't bother over just doing

Yep. It's just the android framework Resources

[Colton Idle]

I'm going to give AmbientContext.current.resources a shot.
I was trying to only pass in Resources because I was trying to write a unit test for this simple composable that basically just displays a string + some images, but thought that surfacing the Resources as a param would be best.

[alorma]

I would move to create a slot (lambda) to create the Image in a way they want

[Colton Idle]

Yeah. I 've thought about that, but at this point this is almost to the point where this entire composable is like a ContactUsScreen composable. So the screen is crazy simple and I just want the composable to be able to set everything up itself. but maybe Im over thinking it for now and I should just ship it. 😄

Adam Powells answer of using the Ambient makes sense for now.