Open sbrunk opened 5 years ago
I've started working on a proof-of-concept prototype.
@sbrunk Looking forward to what you'll find. I've tended to be a bit wary of code generation stuff, especially if they generate end-user API. That said, switching to contraband would put many definitions in JSON files, so it's likely parts of those can be automatically generated…
Some other things I was thinking about before https://github.com/alexarchambault/plotly-scala/issues/44 were either generating dummy JSON structures from the plotly schema, and feed them to plotly-scala decoders, or tweak the encoders / decoders, so that they can be inspected, and check that some of them have all / most of the fields of the plotly schema.
Plotly maintains the declarative json chart schema, which seems to be the authorative source for their API bindings.
See plot-schema.json via API (Firefox renders this nicely as tree) or via GitHub.
plotly.py for instance generates part of its API from plot-schema.json since version 3.0. See also the code generation code for plotly.py. I haven't looked into the other language bindings.
I'm wondering whether makes sense to try a similar approach to generate (part of) the Scala domain code. While this would bring some upfront effort, it might pay of in the long run because of
A possible switch to contraband #44 requires recreating most of the domain code anyway, so it might make sense to consider converting from plotly json schema to contraband directly.
What do you think?