Closed bn-bmagee closed 10 months ago
Give some examples to illustrate your issue, please.
An example of an object implementing json.Marshaler without exposing fields:
type Object struct {
name string
type string
}
func (o *Object) MarshalJSON() ([]byte, error) {
s := struct {
Name string `json:"name"`
Type string `json:"type"`
}{
Name: o.name,
Type: o.type,
}
return json.Marshal(s)
}
There are obviously any number of reasons why a struct might have unexported fields that are exposed in UnmarshalJSON(); perhaps the author wants to control how they're set. I see in the documentation that there is a way to reference structs defined inside of a function. Does that extend to methods? And can it reference anonymous structs?
I just conclude your point that you want some private fields of a struct to be exposed via swaggo, is that right?
I want a way to represent models that do not necessarily resemble the structs that generate them, whether that be exposing private fields or exposing an entirely different structure. Another example could be:
type Object struct {
name string
}
func (o *Object) MarshalJSON() ([]byte, error) {
s := struct {
Name string `json:"name"`
Type string `json:"type"`
Version string `json:"version"`
}{
Name: name,
Type: "object",
Version: "2.0",
}
return json.Marshal(s)
}
Here the issue isn't that the fields are unexported, it's that they don't exist at all, there are just static fields in the returned object. The only way to know they exist is to either observe the result of MarshalJSON or document them with a new struct. Perhaps you are using anonymous structs in MarshalJSON because you don't want to document a new struct for every type of response. Perhaps you're not even using structs at all because you need field names to dynamically change in the response. I don't have an actual use case to point to, I just think it's worth noting that the types generating the responses don't necessarily marshal into JSON using just struct tags. It's fine to say this is a use case not covered by swaggo.
If used in response, model composition may meet your requirements, I think.
type EmptyStruct struct{
}
@success 200 {object} EmptyStruct {name=string,type=string,version=string} "desc"
otherwise, It seems impossible.
The scenario I have is somewhat unique; I created a struct with a single field that is private that marshals into a string so that I could basically force users of this type to normalize the string when creating the type. This results in a type that is troublesome for swaggo as it appears to be an empty struct. It would be helpful if swaggo had the option to attempt to use the object generated by calling MarshalJSON on an empty type to generate a sample model. Obviously this would have to be optional as fields omitted when empty would not be present. An even further improvement would be to allow the specification of a default object to be generated. Besides representing private fields and types that marshal into other types like in my scenario this would also allow for the specification of static fields not present in the struct. Obviously there are alternative methods of achieving the same outcome. To represent the type in my scenario I can simply override the type to instead be represented as a string, and in most scenarios I imagine if the user isn't using a struct as-is they are creating an intermediate struct to marshal instead and that struct can be the one exposed via swaggo. Still, this is a feature I could foresee being useful in projects I work on.