search

swaggest / openapi-go

OpenAPI structures for Go
https://pkg.go.dev/github.com/swaggest/openapi-go/openapi3
MIT License
223 stars 18 forks source link

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

Closed metaleap closed 6 months ago

metaleap commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

Done in #93.