You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is an issue with the lifecycle in version 2.5. The lifecycle is now cross-platform and is propagated through CompositionLocal by default by Compose itself. However, libraries (such as Essenty) define their own lifecycle.
This results in the following:
If FlowMVI uses this CompositionLocal, it will not be aware that the lifecycle should be different (as provided by the navigation library). This will introduce resource leaks when subscribing to stores. The biggest downside is that this local lifecycle is ALREADY being used on Android.
If FlowMVI does NOT use this lifecycle, then it will be necessary to create yet another duplicate of half of the lifecycle code and force the user to convert their lifecycle into FlowMVI's lifecycle and manually pass it as an argument on each screen. This will lead to the deprecation of the subscription function, which is used on every screen, boilerplate during subscriptions, and also the exposure of part of the library's internals to users, who will now have to implement this (yet another) lifecycle.
I encourage everyone to provide their feedback on how they would like to see this resolved, which option to choose and how to gracefully migrate users to the new API
This discussion was converted from issue #59 on April 19, 2024 21:13.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
There is an issue with the lifecycle in version 2.5. The lifecycle is now cross-platform and is propagated through
CompositionLocal
by default by Compose itself. However, libraries (such as Essenty) define their own lifecycle.This results in the following:
If FlowMVI uses this
CompositionLocal
, it will not be aware that the lifecycle should be different (as provided by the navigation library). This will introduce resource leaks when subscribing to stores. The biggest downside is that this local lifecycle is ALREADY being used on Android.If FlowMVI does NOT use this lifecycle, then it will be necessary to create yet another duplicate of half of the lifecycle code and force the user to convert their lifecycle into FlowMVI's lifecycle and manually pass it as an argument on each screen. This will lead to the deprecation of the subscription function, which is used on every screen, boilerplate during subscriptions, and also the exposure of part of the library's internals to users, who will now have to implement this (yet another) lifecycle.
I encourage everyone to provide their feedback on how they would like to see this resolved, which option to choose and how to gracefully migrate users to the new API
Beta Was this translation helpful? Give feedback.
All reactions