Skip to content
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

Difficult to differentiate between old default, updated default and user set value #309

Open
mohlson opened this issue Oct 12, 2022 · 2 comments

Comments

@mohlson
Copy link

mohlson commented Oct 12, 2022

Hi! We have a bit of a conundrum.

When requesting a Toggle the first time, it will store itself with a default value. Any subsequent request to that toggle will then reply with the same stored value, regardless of any new default passed. As there is no way to determine if the value actually comes from an old default or from a user actively toggling the toggle, it becomes difficult to update the default.

Here is a a scenario

  1. A query for the Boolean Toggle for key "thought-experiment-A-roll-out" is added in a client application with default set to the value of the feature flag, which is false as the feature has not yet been rolled out.
  2. The feature is rolled-out to the test environment, and trying to respect the user's wishes, we check the toggle, using the updated value of the feature flag as the default parameter to Toggles.
  3. Toggles fetches the old default value, and since we have a return value, the new default is simply discarded. Now we cannot determine if the returned value is an old default or something the local developer has set, so we also have to discard the new default.

Maybe it would be possible to separate a Toggle's value from its default value, and to always update the default it it no longer matches?

@erikeelde
Copy link
Owner

Interesting conundrum! Ill give it a thought. Been missing similar thing from the exposed api so been contemplating similar problem statements lately.

Sorry for my late response (haven't had much collab in this repo so your issue was as surprising as welcome!).

Also just preparing for releasing some updated binaries - both maven artifacts and apps. App is fully rewritten to compose.

Out of interest - would you be upset ifthere is no UI facility to change scopes any more? Scopes were poorly documented and I wasnt using it much myself so I haven't readded it in the compose UI.

@mohlson
Copy link
Author

mohlson commented Mar 21, 2023

Interesting conundrum! Ill give it a thought. Been missing similar thing from the exposed api so been contemplating similar problem statements lately.

Much appreciated!

Sorry for my late response (haven't had much collab in this repo so your issue was as surprising as welcome!).

No need, I absolutely understand that! If you need anything, just ping me and I will try to help out as I can.

Also just preparing for releasing some updated binaries - both maven artifacts and apps. App is fully rewritten to compose.

Very nice! And isn't Compose just wonderful compared to the old Android View system?

Out of interest - would you be upset ifthere is no UI facility to change scopes any more? Scopes were poorly documented and I wasnt using it much myself so I haven't readded it in the compose UI.

I don't think anyone over at ours is actually using that feature at all, so no, I don't think it would be missed. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants