Serialize JSON keys to camelCase
karelianpie opened this issue · 8 comments
Spinoff this PR comment #251 (comment)
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.
Hey @karelianpie , can I be assigned to this ticket please? thanks :)
Hey @karelianpie , can I be assigned to this ticket please? thanks :)
Done 🙇
Since we dont want to create breaking changes for the current SDK version, we can either:
- Maintain both casings where it is needed in v2 (like in APY interface), and deprecate snake casing completely for v3.
- Merge this change until we do release v3.
What approach do you think works best here? @karelianpie
@xgambitox, how much effort would be to integrate this in our FE?
@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 #242 (comment) as an example.
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?
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.
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