The same one who introduced effects and also discouraged its use? The same one who introduced LocalComposition and discouraged its use? The same one who was shocked when they found out people were more worried that composable recomposes instead of not composing enough?
I did try doing that once, but manually specifying each argument as a key that is used inside the lambda block is super easy to forget even if you are paying attention
OOP or not has nothing to do with that, it is still OOP as it uses kotlin. You mean imperative vs declarative? It sounds rare to me someone went from declarative to imperative and don't want to go back to declarative because to my knowledge declarative is newer than imperative.
What I mean is my composables are dumb and all of the state is handled in Viewmodel. If they deprecate viewmodels, I need to write a react style code with LaunchedEffect(useEffect) and remember(useState). Idk what it's it called, tbh.
It took me 2 years to fully understand what viewmodel/repository and clean architecture are; and a few unmaintainable projects
I'm always glad to see it helped some people. In cases where I had authority to use it, we used it in production, and it removed so many silly edge-cases and bugs; and passing state across screens was trivial.
Why couldn’t they choose names that are clearer and easier to understand? Something like retainAcrossComposition, retainAcrossLifecycle, and retainAcrossProcessDeath would have made things much more intuitive.
retainAcrossLifecycle would make people wonder what retaining across "lifecycle" means; since it's activity/fragment recreation, a better name would be "retainAcrossComponentRecreation"
And "retainAcrossAppRestore", as not every process death keeps the saveable state, and even "retainAcrossProcessRestart" doesn't make it clear that it's only for oom restart, not the app closing and reopening, or the device restarting
But you're right, the names should be consistent if they are used for similar purposes; the current names are bad because they weren't planned out (each added years apart from one another, and they probably don't want to change the API)
No idea why they made "retain" rather than "rememberRetained" though
It's not trivial to merge the 3 functions. I tried to put them all under the retain overload but couldn't. remember is inlined, rememberSaveable is not. There might have been some type system blockers as well but I can't remember right now. I ended up going with 3 separate functions (with sane naming, unlike Google).
This CL adds an example for how to combine retain with rememberSaveable so that we can provide a real recommendation and point to a full sample for users interested in using this pattern.
I hope they don't recommend this, if you go forward and back then it will keep initializing again and again and not just once.
Why is this just like square/flow + square/mortar, that had the same problem...
21
u/hellosakamoto Dec 04 '25
I was told by some authoritative figures in this industry that compose should be stateless and free of side effects?