Closed onno-vos-dev closed 6 months ago
Solicited opinion: the output comparison of an erlang module looks good enough to me.
I think that it will likely be unreasonably hard to code anything that can "prettify" the "flat", "expanded" generated types, and the point should be more "easier doc generation" than the code itself being small... I didn't check, and I am still not using aws-erlang
but perhaps one can offer a minified version of the library without types in that case.
Good job! 😄
Solicited opinion: the output comparison of an erlang module looks good enough to me.
I think that it will likely be unreasonably hard to code anything that can "prettify" the "flat", "expanded" generated types, and the point should be more "easier doc generation" than the code itself being small... I didn't check, and I am still not using
aws-erlang
but perhaps one can offer a minified version of the library without types in that case.Good job! 😄
I tried to generate the edocs
(using rebar3 ex_doc
) for the generated types but apparently edoc
explodes trying to parse the binaries <<"BinaryThingy">>
as if it's an XML-tag so I gotta figure out how to deal with that 👍 But then yes, the idea would be to have good docs on the types and hence aid developers in having more information on what's expected as input into the APIs 👍
Thank you for the comment 🙇♂️
Updated generated code examples that are in the description.
Main changes pushed are:
Reception from colleagues, @LostKobrakai and @philss have been good 👍 I haven't seen anyone yelling "NOOOOO!" on Elixir/Erlang Slack so I'll polish this up over the coming days so we can get this into a mergeable shape 👍 I'm quite happy with how the output looks, just need to polish up some of the cr*ppy code I wrote in this branch 😄
.eex
modulesrest_service.ex
to types.ex
or a similar module rest_service:join_parameter_types
to not have as much nestingShapes
could probably be moved to one module and hence reduce the clauses in types.ex
collect_shapes/2
is the same across both post and rest similar with is_input/1
Util
really living in the right place?Declined in favor of #109 due to wrong branch naming.
Triggering the build and for now this should be considered a DRAFT and a Request For Feedback. The code is a mess and needs some cleaning up and combing over but opening it up in order to get feedback from others.
Generated aws-elixir code as an example: comparison Generated aws-erlang code as an example: comparison