Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: support exported json:-tag-less fields to fully reflect / align-with Go's actual json.Marshal behavior #90

Closed
metaleap opened this issue Nov 13, 2023 · 4 comments

Comments

@metaleap
Copy link

metaleap commented Nov 13, 2023

Glad this exists and is in such mature shape!

Would you be open to (implementing, or a PR implementing) support for json:-tag-less struct fields for request/response structs?

There are surely a few encoding/json users other than me out there who are quite fine with the standard upper-case naming being Marshaled for exported fields without json: tags, and don't need or want to ensure the more-common "js(on) field camelCasing aesthetic", and don't want to busy themselves with the endless chore of field-tag maintenance (linter-assisted or not).

Right now, for openapi31 to emit something (that shows up in the swagger-ui-ish rendition of editor-next.swagger.io) for one's AddReqStructure/AddRespStructure calls, those tags are necessary — imho unnecessarily.

@metaleap metaleap changed the title Support exported json:-tag-less fields to fully reflect / align-with Go's actual json.Marshal behavior Suggestion: support exported json:-tag-less fields to fully reflect / align-with Go's actual json.Marshal behavior Nov 13, 2023
@metaleap
Copy link
Author

metaleap commented Nov 13, 2023

OK found a workaround via:

myreflo.JSONSchemaReflector().DefaultOptions = append(myreflo.JSONSchemaReflector().DefaultOptions, jsonschema.ProcessWithoutTags)

Guess that closes this Issue (your call! =), though this progress now has me stuck on #91 ...

@vearutop
Copy link
Member

Thank you for raising this issue, tagless JSON behavior is indeed important aspect. And unfortunately might be not smooth enough in this library.

One of the potential problems (as far as I remember, did not check the code on this) is that in some places there are checks like hasJSONFields based on the presence of json tags which guides decision on whether the structure should be treated as JSON or a form data. This is not a blocker, but it may need some logic re implementation to properly support tagless JSON.

Please feel free to share more issues/details on your experience with tagless approach, it would be very useful to inform proper implementation.

@metaleap
Copy link
Author

metaleap commented Nov 13, 2023

Ah, in that case, might be best to "capture them" earliest right during the first struct reflection, ie. adding the implied-by-its-absence "default tag" at runtime as if it was explicitly there, iif it indeed wasn't. (Perhaps behind an option if preferred.)

@vearutop
Copy link
Member

vearutop commented Dec 4, 2023

Done in #93.

@vearutop vearutop closed this as completed Dec 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants