-
Notifications
You must be signed in to change notification settings - Fork 25
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
Reconsider RootStore
update behavior
#858
Comments
This needs carefully investigation in order to keep the current and long time established behaviour stable. I am in favor of some flag or somehow "store"-overloading / variant / behaviour approach right now. On the other hand besides "legacy" code we want to support users with our framework to write idiomatic code. That would mean that the current behaviour should rather be treated and branded as deprecated, which in dead would mean some API change. |
In an internal meeting @Lysander suggested to change the default behavior of the This way the stores would always update but identical contents would not be rendered multiple times. |
Another use case that is currently unnecassary hard to solve with the store behaviour: Imagine some "trigger", that should start some process on any new impulse. The naive but rational approach would look like this: val trigger = storeOf(Unit)
// some UI that should reacts to the trigger
// below the trigger element
button {
clicks handledBy trigger.update // the "new" Unit gets swallowed :-/
} To overcome the false "distinctUntilChanged" logic of the store, you could rely on the val trigger = storeOf(Unit).handleAndEmit<Unit, Unit> { _, _ -> emit(Unit) } Looks complicated and cumbersome imho! |
Current insights:
We would need to change both code places therefore. |
Current behavior
Currently, a
RootStore
's value is only updated (i.e.data
flow emits a new value) if the Store receives a new value.If the Store receives a value that is equal to the current value, no value is emitted.
This is due to the fact that a
MutableStateFlow
is used to keep track of the current value which is explicitly designed to behave this way.Why this is problematic
Imagine a
Lens
that is used to strip illegal characters from an input (e.g. characters from a phone number). The expected behavior would be like this:Instead, the following happens:
Example code
Proposal
Consider one of the following options:
The text was updated successfully, but these errors were encountered: