You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Generally JSON APIs allow multiple standard conventions for naming keys, the most common ones in my experience being the snake case and lower camel case. Go provides a bit of a struggle working with these because it uses the less common upper camel case. The work around for this is to augment each field in a struct with the corresponding tag, but that quickly becomes tedious.
My idea would be to allow the encoder/decoder, as well as the global marshaller/unmarshaller to be configured in choosing this standard. Some example code that would go into encoding/json:
The json package is almost completely done. If you need significantly extended semantics, then it would be fine to copy the current one and make your own modifications, creating a new package customized to your use case.
Or maybe write a tool that adds struct tags to specific structs. I find it hard to believe that forcing a default onto everything in the entire tree of types being encoded is likely to remain correct in large programs.
Generally JSON APIs allow multiple standard conventions for naming keys, the most common ones in my experience being the snake case and lower camel case. Go provides a bit of a struggle working with these because it uses the less common upper camel case. The work around for this is to augment each field in a struct with the corresponding tag, but that quickly becomes tedious.
My idea would be to allow the encoder/decoder, as well as the global marshaller/unmarshaller to be configured in choosing this standard. Some example code that would go into
encoding/json
:Where
Default
is the current setting withUpperCamelCase
. SnakeCase would be thesnake_case
and CamelCase would be the JavaScript standardcamelCase
.Then we could augment the encoder/decoder (and perhaps a global function too) to work in a way similar to:
And so on. Thoughts?
The text was updated successfully, but these errors were encountered: