Rupert, I've been doing something very similar and it is proving very worthwhile, > so I would encourage you to pursue this. >
Thanks (: > For Elm, I output one (big) file called Model.elm, that gives me the data > model mapped onto Elm, and encoders and decoders for it. Then for each > grouping of endpoints (each service implemented in Java provides the > grouping) I generate one Elm file that implements the Http logic for the > service. > I've come to the same file structure, because JSON API allows for included resources. For example, articles can include their author an vice versa, which means those decoders have to be defined in a common file. I'm trying to wrap them in one module per resource, though. > Each service requires a set of callback functions to be passed in - one > for each endpoint, plus one for each endpoint when it results in an error, > plus a default error handler for cases when the endpoint specific error > handler doesn't process the error. > I'm taking a different approach. I'm using the RemoteData library to track the (possibly error) state of each ID'd resource, so if there's an error, it's just stored. You won't know until you try to get that ID and you wind up with the Failure case of the RemoteData type. I'm also planning on having an error log that's written to in opaque events and exposed read-only through an API. > Another possibility would be to use an API description meta-data such as > Swagger. A Swagger codegen for Elm could easily output something useable. > I've used both Swagger and JSON API before, and I'll say that JSON API has almost no downsides but Swagger is much more an engineering tradeoff. An Elm swagger codegen is something that should exist but I'm taking a different approach. > I think Elm will be well suited to writing code generators - in a manner > similar to how it 'codegens' Html. You can design a set of functions for > constructing the component parts of the output language you are working > with. Elm is good for doing complex AST manipulation and it can be set up > to guarantee correctly formed output. Code generation of Elm in Elm will be > a mind bender. > I'm hesitant to rely on server-side rendering Elm when it's not officially supported (I say that as the co-author of Elm test and Richard's shell utility for it does exactly that, so maybe I'm not being consistent). I'm also a little less concerned with well-formed output, since elm-format can smooth over a lot of bumps in a hacked-together system. I'm more comfortable in Ruby but Noah Hall has written some JSON tools in Python that I'd like to build on if it makes sense to do so (he's left NRI so maybe not?). Thanks again for your encouragement! -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
