-
Notifications
You must be signed in to change notification settings - Fork 0
feat: add util to fetch global and chain feature flags at once #229
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
Merged
Merged
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
c8aeffb
feat: add util to fetch global and chain feature flags at once
infiniteflower 0577f20
fix: lint errors
infiniteflower e5aabef
fix: lint errors
infiniteflower fe21b10
fix: wrong test
infiniteflower 6c37292
Merge branch 'main' into feat/stx-mobile-fetchSwapsFeatureFlags
legobeat 34c4794
fix: make fallback_to_v1 optional to avoid breaking change
infiniteflower 6d7bfa7
chore: improve test names
infiniteflower 71f40f2
chore: revert back to original interface for fetchSwapsFeatureLivenes…
infiniteflower File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest making these
snake_casefor consistency and the changing all of them (including the_activeflags above) tocamelCasein a follow-up PR.That way:
fallback_to_v1plusfallBackToV1)camelCaseThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was just dumping all of the raw feature flags from the endpoint directly so that's why there's all these sort of overlapping values.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah. So maybe it makes sense to make two types: One to interface with that API (using something like here) and one used internally and everywhere else (using a consistent, internal API). The consumption of the API would then involve parsing one to the other. Does that make sense?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea makes sense, I'll adjust the types so there's no breaking changes.
To provide some context around this function, I just wanted to give clients the ability to consume the raw API directly, otherwise it necessitates we would have to update to the
SwapsControllerif things fall outside of the current utils function such as in the STX case where the STX feature flags are outside of any chain specific feature flags.So to just give the clients more flexibility, this util function just gives the raw endpoint result back to the client.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I suggest refactoring the API in another PR as it would mean we need to refactor the clients as well. I just need
fetchSwapsFeatureFlagsto accommodate Smart Transactions.My type updates are simply reflecting the current state of the
SwapsControllerreturn values. Without the change to:The return values from
fetchSwapsFeatureLivenessare not properly typed.Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea here would be precisely to make the clients-facing API more stable. So in this first step, we can just stick to the existing interface, extended with flags necessary for the purpose of the functionality in this PR.
Then the types used to interface with the server API would be what you write here.
And any translation necessary (e.g. case-insensivity, supporting two different spellings of the same value, or response validation/error handling) could be handled in
fetchSwapsFeatureLiveness.This way:
fetchSwapsFeatureLivenessare not properly typed."Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If more flexibility and decoupling is desired for use of the data that is actually unrelated to the swaps controller itself, maybe the currently static feature flags could be made into optional runtime configuration, with the existing ones as default?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, I've reverted the interface for
NetworkFeatureFlagsandNetworksFeatureStatusforfetchSwapsFeatureLivenessback to their original states.I've added
NetworkFeatureFlagsAllandNetworksFeatureStatusAllfor use withfetchSwapsFeatureFlags, which would basically be the raw dump of the API endpoint's result.So nothing will change for existing methods. This PR only adds new a new method (
fetchSwapsFeatureFlags) and new interfaces (NetworkFeatureFlagsAllandNetworksFeatureStatusAll) that only apply to that new method.