-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Change rememberRetain not to retain the value of removed node #1794
base: main
Are you sure you want to change the base?
Change rememberRetain not to retain the value of removed node #1794
Conversation
Thanks for the contribution! Unfortunately we can't verify the commit author(s): roy.tk <r***@k***.com>. One possible solution is to add that email to your GitHub account. Alternatively you can change your commits to another email and force push the change. After getting your commits associated with your GitHub account, sign the Salesforce Inc. Contributor License Agreement and this Pull Request will be revalidated. |
50dc04e
to
affec25
Compare
Timeout failure occurred when attempting to launch the emulator in the CI.
It seems that have not enough space in CI machine. |
@ZacSweers Can you help me about this? |
Please be patient and don't tag maintainers, we will get to it when we get to it! |
As mentioned in #1783, I propose modifying the behavior of
rememberRetained
to improve consistency.Changes to rememberRetained Behavior
The following explanation is based on the code sample below.
Current Behavior
Before
saveAll
is called on the registryrememberRetained
added when the condition istrue
will be removed when the condition changes tofalse
.true
and the samerememberRetained
is called, the previous value is not retained.Test code for this behavior
After
saveAll
is called on the registryrememberRetained
added when the condition istrue
will be removed when the condition changes tofalse
.saveAll
is called on the registry.true
and the samerememberRetained
is called, the previous value is retained.Test code for this behavior
Challenges with the Current Behavior
saveAll
call on theRetainedStateRegistry
is unknown from the perspective of lower-level content, making retention depend on whethersaveAll
was called.remember
/rememberSaveable
, the node doesn’t retain the previous value when it’s removed and added back, making it easy to expectrememberRetained
to behave similarly.Due to these challenges, I propose modifying
rememberRetained
to behave likeremember
/rememberSaveable
, so thatrememberRetained
does not retain values when it is hidden and reshown in the compose node based on a condition.Internal Implementation Changes
Overall, I drew inspiration from the implementation of
SaveableStateHolder
andrememberSaveable
for these modifications.The following changes were made to achieve this goal:
1. Modify
RetainableSaveableHolder
to always unregister values from theRetainedStateRegistry
whenonForgotten
is called.In the previous implementation, if
rememberRetained
was removed from the node andonForgotten
was called, values were not unregistered from the registry ifcanRetain
wastrue
. As a result, all values were retained in the registry regardless of whetherrememberRetained
was present in the node whensaveAll
was called.Now, values are unregistered from the registry when
onForgotten
is called, so only values present in the composition node are retained whensaveAll
is called .2. Change the timing of
saveAll
inRetainedStateRegistry
Previously,
saveAll
was called on theRetainedStateRegistry
withinRetainableSaveableHolder
whenonForgotten
was invoked. However, due to the change in 1,onForgotten
of all childrememberRetained
nodes is called beforeonForgotten
ofrememberRetained { RetainedStateRegistry() }
, which would result in no values being retained.Therefore, I referenced the
SaveableStateHolder
implementation to create a separateDisposableEffect
to runsaveAll
, as shown below:By structuring it this way,
saveAll
can be called on theRetainedStateRegistry
before the child content's dispose stage. Thus, even ifonForgotten
is called on the child content'srememberRetained
and unregisters the value, it will still be retained.Compared to the existing implementation, this change needs to be applied to all cases where the
RetainedStateRegistry
is redefined in a nested way. To facilitate this process, I made theRetainedStateProvider
function public and modifiedNavigableCircuitContent
andPausableState
to use it. (24d8547)3. Change the timing of
saveAll
inAndroidContinuity
For the same reason as in 2,
continuityRetainedStateRegistry
also needs to callsaveAll
usingDisposableEffect
after declaring the child content.Example
However, in Android,
continuityRegistry
should always callsaveAll
whenonStop
is called. Since callingsaveAll
multiple times won’t cause issues, I modified it to callsaveAll
conveniently upononStop
or disposal.Changes to Test Code
Change 1
In
RetainedTest.kt
, parts wherenestedRegistry
is declared now useRetainedStateProvider
, assaveAll
must be manually called.affec25
Change 2
In
NestedRetainWithPushAndPop
andNestedRetainWithPushAndPopAndCannotRetain
, the tests assume the same value is retained regardless of theshowNestedContent
value, so I set the same key inRetainedStateProvider
to retain the values.However, since these assumptions may change with this PR, it may need verification to ensure correctness.
affec25
Change 3
To test
ImpressionEffect
, I modified the function attempting to recreate it. Previously, the condition was first set tofalse
to remove the child content and thensaveAll
was performed. In the modified behavior,saveAll
is performed first and then the child content is removed.465f98f
Additional Test Cases for the Reported Issue
I added test cases to cover the issue reported, which show which tests failed with the previous implementation and how they succeed with the modified implementation.
019c8cc, 5b279d4
When I initially reported this issue, I may have been somewhat aggressive due to the unexpected behavior. I apologize if it came across that way. Through working on this modification, I had the chance to explore the internal structure of
rememberRetained
and have come to appreciate how robust and well-designed many parts of thecircuit
library are. I have great respect for the efforts of the main contributors.After considering various approaches, I believe this change to the behavior of
rememberRetained
is the right direction. However, since the implementation ofrememberRetained
is a core part ofcircuit
, there may be differing perspectives on this.While having this PR approved would be ideal, if there are differing views, I hope we can use this as a foundation for further discussion.