In complex scenarios our team always ends up worki...
# compose
m
In complex scenarios our team always ends up working around this forced limitation of navigation args and I wonder how to best handle it. As a simple example, you navigate from a
ProductsDetailsScreen
to
SubscribeToProductAvailabilityBottomSheet
- let's say the sheet requires the complex domain model
Product
to perform its work. Here I would not like the
Product
to be passed in global scope, it's a transient object shared between those two destinations only. So
ProductRepository
(like your
PersonRepository
) will keep it in the global scope and requires some manual cleanup when they are done using it - the responsibility of this class and it's behavior will be strictly working around how the navigation works, there will be no other function for it. Therefore I would argue that it's not a clean solution (we've implemented these
SthTransientRepository
classes and all agree they look hacky as hell). Of course if I cached these Products at least for the lifetime of the app, this repository would make sense, but they are very volatile, only need to be there as long as user views them. It would be very different if these "repositories" could be scoped to navgraph. But afaiu there is no way to scope anything but viewmodel to the navgraph without significant amount of boilerplate, right? I understand the "deeplink" rationale for the design decision that led to limiting passing complex objects via nav args, but there are screens which show modals, dialogs, bottomsheets - and I'm struggling to find elegant patterns to pass data to these secondary destinations of navgraph and back - every solution feels like workaround. If anyone has any hints or snippets, I'd appreciate them.
☝🏽 1
☝️ 1