feat: dummy pricing provider #32
Conversation
| const dummyPricingSchema = baseSchema.extend({ | ||
| PRICING_SOURCE: z.literal("dummy"), | ||
| DUMMY_PRICE: z.coerce.number().optional().default(1), | ||
| }); | ||
|
|
||
| const coingeckoPricingSchema = baseSchema.extend({ | ||
| PRICING_SOURCE: z.literal("coingecko"), | ||
| COINGECKO_API_KEY: z.string().min(1), | ||
| COINGECKO_API_TYPE: z.enum(["demo", "pro"]).default("pro"), | ||
| }); | ||
|
|
||
| const validationSchema = z | ||
| .discriminatedUnion("PRICING_SOURCE", [dummyPricingSchema, coingeckoPricingSchema]) | ||
| .transform((val) => { | ||
| if (val.PRICING_SOURCE === "dummy") { | ||
| return { pricingSource: val.PRICING_SOURCE, dummyPrice: val.DUMMY_PRICE, ...val }; | ||
| } | ||
|
|
||
| return { | ||
| pricingSource: val.PRICING_SOURCE, | ||
| apiKey: val.COINGECKO_API_KEY, | ||
| apiType: val.COINGECKO_API_TYPE, | ||
| ...val, | ||
| }; | ||
| }); | ||
|
|
There was a problem hiding this comment.
We can move this into a different file in the future(not now), to have a more readable and modular code.
| @@ -13,5 +13,7 @@ INDEXER_ADMIN_SECRET=testing | |||
|
|
|||
| IPFS_GATEWAYS_URL=["https://ipfs.io","https://gateway.pinata.cloud","https://dweb.link", "https://ipfs.eth.aragon.network"] | |||
|
|
|||
| PRICING_SOURCE= #coingecko | dummy | |||
There was a problem hiding this comment.
is # for comment, in next PR i'll add a whitespace
| if (!deps?.logger) { | ||
| throw new MissingDependencies(); | ||
| } |
There was a problem hiding this comment.
I'm wondering if we should standardize the dependencies validation with some kind of generic pattern (with the help of zod maybe?) while initializing objects.
There was a problem hiding this comment.
you mean inside constructors or having a zod schema here instead of if (!deps?.logger)
There was a problem hiding this comment.
Zod schema could be a solution yeah. I'm thinking in general, whenever a service needs dependencies and those dependencies might need to accomodate themselves to some particular schema (like optional dependencies, some dependencies need to be present based on some other dependency value, etc)
I guess that applying a zod schema could cover 99% of the cases, I'll apply it in my code and I'll let you know how happy/sad it is to use it lol
| constructor(private readonly dummyPrice: number = 1) {} | ||
|
|
||
| /* @inheritdoc */ | ||
| async getTokenPrice( |
There was a problem hiding this comment.
Extremely minor detail but the async keyword here is not necessary given the Promise.resolve() usage
There was a problem hiding this comment.
ooo didn't know that
🤖 Linear
Closes GIT-136 GIT-144
Description
timestampEndoptional forIPricingProviderChecklist before requesting a review