search

yearn / yearn-sdk

🦧 SDK for the yearn.finance platform. WIP
https://npm.im/@yfi/sdk
MIT License
53 stars 56 forks source link

Serialize JSON keys to camelCase #257

Closed karelianpie closed 1 year ago

karelianpie commented 2 years ago

Spinoff this PR comment https://github.com/yearn/yearn-sdk/pull/251#discussion_r829682479

In summary, we would like to have this rule enabled "@typescript-eslint/camelcase": "off"

However, in order to achieve that we need to serialize the JSON keys (snake_case) to camelCase

A possible solution is using a library such as https://github.com/typestack/class-transformer, but we could also have a go at implementing something similar ourselves.

PsyopTom commented 2 years ago

Hey @karelianpie , can I be assigned to this ticket please? thanks :)

karelianpie commented 2 years ago

Hey @karelianpie , can I be assigned to this ticket please? thanks :)

Done 🙇

xgambitox commented 2 years ago

Since we dont want to create breaking changes for the current SDK version, we can either:

What approach do you think works best here? @karelianpie

karelianpie commented 2 years ago

@xgambitox, how much effort would be to integrate this in our FE?

xgambitox commented 2 years ago

@xgambitox, how much effort would be to integrate this in our FE?

On our end, it would be easy IMO (although we have multiple repos that use it, like yearn-watch), but we do have other external integrators that use the SDK, and we should aim not to be a pain for them when upgrading. See https://github.com/yearn/yearn-sdk/issues/242#issuecomment-1063956309 as an example.

karelianpie commented 2 years ago

On our end, it would be easy IMO (although we have multiple repos that use it, like yearn-watch), but we do have other external integrators that use the SDK, and we should aim not to be a pain for them when upgrading. See #242 (comment) as an example.

Definitely it would need to be a major release. As this is not high priority, I would suggest we could do this piece of work and then bundle it with changes for v3, seems a bit too much work to support both in parallel and then deprecate the old way once we're ready for v3. What are your thoughts?

xgambitox commented 2 years ago

Yeah, agree. How about we create a v3 branch, and start bundling those changes into there? We do want to plan and write issues about other breaking changes we want, such as named parameters, and release them once we are comfortable with all changes.

karelianpie commented 2 years ago

How about we create a v3 branch, and start bundling those changes into there?

Good idea, done https://github.com/yearn/yearn-sdk/tree/v3