I'm storing logged in user's data in local database. And I need that user id in multiple composable ...

# compose

[rajesh]

I'm storing logged in user's data in local database. And I need that user id in multiple composable for future requests. Should I use CompositionLocal for this to pass userId?

[Zun]

I don’t think tagging anyone is really needed. Someone will surely answer this question

[jim]

You have a couple of design questions there.

The first design question is about the use of CompositionLocal.  Current user is a tricky one, because it is right on the edge of "acceptable use of CompositionLocal" and "still not justified".  Current user is used in enough places that it might be reasonable, but providing it as a CompositionLocal will almost certainly result in your widgets taking unnecessary dependencies on an app-specific data model that you probably wouldn't have taken if you had been forced to think about it and pass values explicitly.  I think I would lean in favor of the default rule, which is "don't use CompositionLocals", but this particular use case is debatable.

The second question is about using the database in your composables. Having your composables read from the database is very sketchy. It is a mix of sideways data loading, additional unnecessary coupling (in the form of unnecessary dependencies), etc. At the very least, you should have a separate data layer such that your widget is only dealing with an interface that looks like a POJO and your composables should know nothing about which database your users live in. Instead of passing in a UserID, you should pass in a UserObject which exposes whatever information you need for that user. Imagine in the future you wanted to be able to create a new memory-only implementation of your user object (maybe for testing purposes or for a redesign of your data layer); the question you should ask yourself is: "does the current API of my data layer allow for this redesign?"

[rajesh]

Thanks Jim for responding. My composable is not reading directly from database, but it is observing the loggedInUser variable (StateFlow in ViewModel that reads from repository). So I thought of like passing this variable as CompositionLocal but after searching some of your answers, I'm leaning towards explicit parameter pass.