Rough edges for swagger documentation

[piotr-yuxuan]

Hi, thanks for this project which definitely is awesome! I've stumbled across this behaviour which one might counter-intuitive:

One can't describe a map attribute like this:

(malli.swagger/transform
  [:map [:my-uuid {:optional true
                   :swagger/example #uuid"eb4acd14-5321-4317-82e2-5895269f18a8"
                   :swagger/description "your most awesome uuid"}
                  uuid?]])

;; =>
{:type "object", 
 :properties {:my-uuid {:type "string", :format "uuid"}}, 
 :required []}

:optional is taken into account but :swagger/* keywords are ignored. As a result one has to follow this syntax with two attribute maps:

(malli.swagger/transform
  [:map [:my-uuid {:optional true}
                  [:and {:swagger/example #uuid"eb4acd14-5321-4317-82e2-5895269f18a8"
                         :swagger/description "your most awesome uuid"}
                        uuid?]]])
;; =>
{:type "object",
 :properties {:my-uuid {:type "string",
                        :format "uuid",
                        :x-allOf [{:type "string", :format "uuid"}],
                        :example #uuid"eb4acd14-5321-4317-82e2-5895269f18a8",
                        :description "your most awesome uuid"}},
 :required []}

For the sake of completion, this following syntax doesn't produce the expected result either as :optional now is ignored:

(malli.swagger/transform
  [:map [:my-uuid [:and {:optional true
                         :swagger/example #uuid"eb4acd14-5321-4317-82e2-5895269f18a8"
                         :swagger/description "your most awesome uuid"}
                        uuid?]]])

;; =>
{:type "object",
 :properties {:my-uuid {:type "string",
                        :format "uuid",
                        :x-allOf [{:type "string", :format "uuid"}],
                        :example #uuid"eb4acd14-5321-4317-82e2-5895269f18a8",
                        :description "your most awesome uuid"}},
 :required [:my-uuid]}

Would you agree with me to qualify this as a bug? would you be interested in fixing it, or open to pull requests about that?

Using version "0.4.2"

Cheers!

[ikitommi]

Thanks for reporting, this is duplicate to #86. Need to figure out a clean solution for this, options being:

1. implement the parent/child relationship between entry & child schema (complex?)
2. copy all but :optional entry-defintions to child schema properties (child m/form and m/properties show the entry-derived props, a surprise)
3. same as 2 but move those (map m/form and m/properties don't show the entry props, a surprise)
4. distinguish props from "derived props" (dunno how to make that work)

ideas welcome how to resolve this elegantly.