-
Notifications
You must be signed in to change notification settings - Fork 0
feat: implement token lists management with fetcher and parser support #10
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
base: master
Are you sure you want to change the base?
Conversation
f3313c0
to
b07c664
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #10 +/- ##
===========================================
+ Coverage 19.64% 45.96% +26.32%
===========================================
Files 17 34 +17
Lines 1181 2195 +1014
===========================================
+ Hits 232 1009 +777
- Misses 945 1125 +180
- Partials 4 61 +57
🚀 New features to boost your workflow:
|
7c0e25d
to
15d894a
Compare
8753428
to
a572056
Compare
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.
Thanks for splitting the logic into files. I feel we could go one step further and create packages with self-contained single-responsibility functionality, that way these modules become reusable in a more granular level.
I haven't though too much about it, but I imagine something like:
- A package in charge of fetching/parsing lists of token lists
- A package in charge of fetching/parsing token lists (doesn't care whether they come from, could be downloaded or a local file selected by the user)
- A package in charge of merging multiple token lists
The "Service" part that runs the timers and triggers periodical fetches. Hmm I've avoided putting such stuff in the wallet-sdk for now, and I haven't thought too much about it yet, but my general feeling is that something like that belongs more in the consumer (ie status-go) than the wallet-sdk. Anyway, it's a discussion I'd like to have!
return c | ||
} | ||
|
||
func (c *Config) WithCommunityTokenStore(store CommunityTokenStore) *Config { |
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.
haven't finished reviewing, but this is a red flag. The concept of a community is something status-specific, it most likely doesn't belong in the wallet-sdk
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 concept of a community is something status-specific
Yes it is, and the wallet-sdk is here to simplify Status' needs. Was thinking whether to keep it on the stautsgo side or not, but then moved it here and let tokenlists
package to take care of everything token-related.
|
||
"go.uber.org/zap" | ||
) | ||
|
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 config struct should probably be defined here for clarity
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.
It can be, but added it to types.go since all types for the package are there.
@@ -1,5 +1,15 @@ | |||
package common | |||
|
|||
const ( | |||
EthereumNativeCrossChainID = "eth-native" |
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.
hmm if this really needs to be in common, it should probably be in a separate file.
My impression is this is token-related, so it should be in some token-related package
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.
Yes, can be moved there.
LogoURI string `json:"logoUri"` | ||
|
||
CustomToken bool `json:"custom"` | ||
CommunityData *CommunityData `json:"communityData,omitempty"` |
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.
yeah this definitely doesn't belong here. If Status wants community data for some specific token it should get it from some community service.
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.
As said in the previous comment, was thinking which approach to go with, but then wallet-sdk is here mainly for our needs and is aware of custom tokens and community tokens and knows how to handle them if they are provided. If the client doesn't need them, there are default custom and community token storer that can be used. In that case the package behaves as a regular token manager.
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.
but then wallet-sdk is here mainly for our needs
I think we should treat this as a general-purpose library (that’s what an SDK is for). Ideally it should stay flexible enough so it can also be used in the Market-Proxy or even in Logos core, without assumptions about Status-client specific needs.
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.
as we claim in https://github.com/status-im/go-wallet-sdk/blob/master/docs/specs.md
Go Wallet SDK is a modular Go library intended to support the development of multi‑chain cryptocurrency wallets and blockchain applications. The SDK exposes self‑contained packages for common wallet tasks such as fetching account balances across many EVM chains and interacting with Ethereum JSON‑RPC.
- Added new package `tokenlists` for managing token lists. - Implemented `tokensList` struct for thread-safe state management. - Introduced `refreshWorker` for background updates of token lists. - Created fetchers for remote token lists and individual token lists. - Added parsers for CoinGecko, Uniswap and Status list token formats. - Included configuration options for token lists management. - Implemented validation for token lists against JSON schemas. - Added comprehensive tests for all new functionalities.
a572056
to
52bb6d6
Compare
We can, ofc, if there is a need for that. That's how it is organized in stautsgo now. |
tokenlists
for managing token lists.tokensList
struct for thread-safe state management.refreshWorker
for background updates of token lists.