-
Notifications
You must be signed in to change notification settings - Fork 73
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
Create token-specific entities #2309
base: main
Are you sure you want to change the base?
Conversation
type: z.literal('NATIVE_TOKEN'), | ||
decimals: z.number(), | ||
}); | ||
|
||
const Erc20TokenSchema = BaseTokenSchema.extend({ | ||
type: z.literal('ERC20'), | ||
decimals: z.number().catch(DEFAULT_ERC20_DECIMALS), | ||
}); | ||
|
||
const Erc721TokenSchema = BaseTokenSchema.extend({ | ||
type: z.literal('ERC721'), |
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.
String type
s are now preferred due to type complaints when using different enums from the domain vs. route layers.
Erc20 = 'ERC20', | ||
NativeToken = 'NATIVE_TOKEN', | ||
} | ||
import { z } from 'zod'; |
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.
This is the "core" change, from which everything else implemented.
Summary
Resolves #2307
We currently parse native, ERC-20 and ERC-721 tokens as one, meaning we cannot safely assume decimals should they not exist.
This splits
TokenSchema
into three specific schemas per token type with the following assumptions:From the parsed token, token-specific entities are mapped for Swagger.
Changes
TokenSchema
intoNativeTokenSchema
,Erc20TokenSchema
andErc721TokenSchema