Closed tmbull closed 5 years ago
Any updates on this?
@tmbull thanks for putting this together. I've not tried elm-bridge
but I'm not against supporting it in this project.
However it'd be a shame to break things for people already committed to elm-export
. I know there is a fork out there that adds support for sum types.
I would consider a PR that factors out the type- and decoder- generation parts, leaving only the HTTP request function generation, where the user provides their own generator mechanism via elm-export
or elm-bridge
.
If that's too much boilerplate for the user, I'd also consider a PR that adds two new libraries, servant-elm-export
and servant-elm-bridge
that provide that boilerplate.
I've not looked into how technically feasible it would be to factor out the common API generation part, however.
Hi @mattjbray thanks for taking a look at this. I agree that factoring out the type- and decoder- generation is the best approach. I'll give it a try, but it will probably be a few days before I can update the PR as I'm pretty busy with other projects at the moment.
Ok, so it looks like elm-export
is not keeping up (partly my fault as I'm a maintainer), so let's go ahead with this swap.
@tmbull can you get the travis tests to pass? It looks like stack.yaml
is pointing to a private elm-bridge
repo.
FYI I'm continuing this work in https://github.com/haskell-servant/servant-elm/pull/49
I submitted issue #39 a while back, because I find
elm-bridge
to be a lot more complete in terms of the types that it supports (namely sum types). Additionally, it uses the same options for code generation asaeson
.I'm not sure if this is something you are interested in or not, but I've gone ahead and done the work to migrate from
elm-export
toelm-bridge
.I also have a PR open on
elm-bridge
, at which point I can update the dependency in the stack yaml.