Apply string casing to method params while deriving proxies and services#30
Apply string casing to method params while deriving proxies and services#30
Conversation
|
No idea how this magic works, so I'll have to try it out, which is a bit more work to do. Next week probably. |
|
Is this a breaking change for people that still use old casing? |
@blouflashdb I would consider this a local breaking change yes and not protocol breaking one. If a client uses snake casing, it has to be updated. However I'm assuming that most users are using positional parameters thus not affect many. |
|
Please make it backwards compatible. Deprecate the old casing and remove it completely in a major version and add it to the breaking changes section in the upgrade notes. I believe the next version will be a patch version? You can not expect from users to change their rpc usage in a patch version... |
668bcfa to
4762c06
Compare
4762c06 to
633794f
Compare
|
|
|
Would probably be good to have a transition period where we accept both to be backward compatible. |
|
This jsonrpc crate is published itself to crates.io. So it has it's own semver and @blouflashdb is right that this is a breaking change if the old style is not accepted anymore, requiring a new major version of this crate. |
When providing RPC method parameters as a client via named parameters
{"a": 1, "b": 2}, they had to besnake_cased since no string case renaming was applied to them inside the deriving macros. This PR changes this behaviour such that it adheres to therename_allattribute that can be provided to theProxyandServicemacros.Old input with
service/proxy(rename_all = "camelCase")applied:New input with
service/proxy(rename_all = "camelCase")applied: