Replies: 2 comments
-
Alternative options that I'm going to investigate is providing a separate module with extensions for SavedStateRegistry and ViewModelStore. So that we could have the best of the two worlds. |
Beta Was this translation helpful? Give feedback.
0 replies
-
The new 3.4.0-alpha03 release adds |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I have been thinking for a long time about completely migrating Decompose not only to
androidx.Lifecycle
(see #695), but also toSavedStateRegistry
,ViewModel
and the newNavigationEventDispatcher
. For those who don't like theViewModel
API like me, it should be possible to create extensions based onAutoClosable
from stdlib (likegetOrCreateCloseable
from Essenty). In a similar way, it should be possible to enhance theSavedStateRegistry
API.The idea is that
GenericComponentContext
will extend not only androidxLifecycleOwner
, but alsoSavedStateRegistryOwner
,ViewModelStoreOwner
andNavigationEventDispatcherOwner
.Pros:
SavedStateRegistry
seems to support passing aSerializersModule
(of course, I could do the same inStateKeeper
, but it's not straightforward). Also, in theory, it will also be easier to interop with the official navigation and other libraries. Easier adoption of Decompose.And, well, it seems to be a standard already.
Cons: the mentioned AAC API is quite messy, as it's been carried over for a long time since Java times. There are plenty of opinionated APIs that I don't quite like to be exposed from Decompose.
Anyway, at this point I'm not even 100% sure that this is even possible to implement, I will need to try.
Add 👍 if you think this is a good idea, add 👎 if you don't like it.
Beta Was this translation helpful? Give feedback.
All reactions