Replies: 4 comments 1 reply
-
Please don't :-) Decompose components are close to Android fragments. The reason is the ability to pass Context/Resources/etc (and anything else that depends on that) via constructors. This is not possible with ViewModels only, which is a significant limitation. |
Beta Was this translation helpful? Give feedback.
-
Sad to hear it. In my opinion save components from configuration changes gives more props than passing activity/fragment context via component constructor. In android we can only provide Application context in ViewModel constructor and it is more than enough in most cases. Will be great if components will have same lifecycle that android ViewModels. P.S You made really nice library and here is only one point that stop me to using it. |
Beta Was this translation helpful? Give feedback.
-
Decompose |
Beta Was this translation helpful? Give feedback.
-
Using the following code you can have way less boiler plate when using Instances.
|
Beta Was this translation helpful? Give feedback.
-
Hi,
I considered Decompose components to be similar to ViewModels in Android. They contain the logic and expose a state to the ui component. Interestingly ViewModels are preserved during Android state changes, but components are not. To achieve the same behavior for components you have to use instanceKeeper.
Why not make components be preserved during state changes by default? I don't really see a case where you don't want that. Using instanceKeeper as an additional layer adds a lot of boiler plate, as you have to copy all exposed functions and state variables.
I think a lot of my components will be similar to this:
Beta Was this translation helpful? Give feedback.
All reactions