sushi token resolver #117
sushi token resolver #117
Conversation
…getComponents in token resolver interface
…-token-resolver # Conflicts: # .prettierignore
…-token-resolver # Conflicts: # .prettierignore # packages/core-sdk/resolvers/token-resolvers/resolvers/curve/src/query/__tests__/e2e/integration.spec.ts
packages/core-sdk/resolvers/token-resolvers/resolvers/sushi/src/query/constants.ts
Outdated
Show resolved
Hide resolved
...core-sdk/resolvers/token-resolvers/resolvers/sushi/src/query/functions/getTokenComponents.ts
Outdated
Show resolved
Hide resolved
| return [token0AddressResult.unwrap(), token1AddressResult.unwrap()]; | ||
| } | ||
|
|
||
| function getSushiSwapComponents( |
There was a problem hiding this comment.
I am wondering whether we should re-use the uniswap token resolver here?
There was a problem hiding this comment.
What is the best way to do that? They are in different packages, so should we add the uniswap token resolver to npm and then add it as a dependency in the sushi token resolver??
There was a problem hiding this comment.
Sorry, I just realized I misread your original comment. They are similar enough that we could combine them into one token resolver. I think same with linkswap. The main difference is in the contract addresses being queried, and sushibar is a little different.
There was a problem hiding this comment.
Exactly, but for now, let's keep it as it is and open an issue to investigate this further.
…-token-resolver # Conflicts: # .prettierignore
…-token-resolver # Conflicts: # .prettierignore
…-token-resolver # Conflicts: # yarn.lock
…-token-resolver # Conflicts: # .prettierignore
includes sushiswap and sushibar