Elm clients for multiple specs will collide with one another

[abingham]

The elm client code that swagger-to generates is always in a file called 'Client.elm' and always has the module name 'Client'. This means that if I generate bindings for more than one spec, they can't be used in the same program (without modifying the generated code).

One way to address this is to let the user specify a module name, i.e. something besides "Client". So if the user specified "PetStoreAPI" as the module, they would get a file names "PetStoreAPI.elm" with the statement "module PetStoreAPI exposing (...whatever...)" in it.

[mristin]

Hi @abingham , I suppose a command-line option --module_name in swagger-to-elm (with a default value "Client") incorporated in the template and file name should suffice? What about the package json file?

Different clients live in different directories?

[abingham]

I was imagining a command-line option, though I'm not sure of the pros and cons of using package.json.

Different client bindings will likely live in different directories, though it's not strictly necessary. If we allow users to specify nested module names like "MyProgram.Comms.MyApi", we could generate a file names "MyApi" with the module specification "module MyProgram.Comms.MyApi", and this file could be placed in the "MyProgram/Comms" directory of an Elm project.

Actually, I've got a number of changes that are needed to the existing Elm client that have to do with updates to the Elm APIs it uses. I think I'll start by writing my own standalone Elm client generator, and we can roll ideas from that into your client generator if necessary.

[mristin]

@abingham:

Actually, I've got a number of changes that are needed to the existing Elm client that have to do with updates to the Elm APIs it uses. I think I'll start by writing my own standalone Elm client generator, and we can roll ideas from that into your client generator if necessary.

The current Elm client code uses Elm 0.18. If you are targeting 0.19 or 0.19.1, maybe you can just call it swagger-to-elm-0.19.1? It would actually make more sense to exclude package.json since that would allow the user to pack in other packages as well, add more modules etc. This would make your idea with nested modules actually quite simple to implement, wouldn't it?

[mristin]

P.S. it would be great if you could contribute your client generator to swagger-to (unless it's very application-specific) -- please let me know if you need any help, pointers etc.

[abingham]

The changes have to do with 0.19 and some associated changes to Http and Json APIs (and possibly more). After looking through the existing elm client generator, I've decided that it'll be faster and cleaner to write a new one; this may turn out to be incorrect, but I'm also just intellectually curious to do it.

In any event, once I'm happy with it I'll be happy to contribute it to swagger-to.

[mristin]

Hi @abingham , Do you still plan to contribute back the Elm client for Elm 0.19, or should we rather close the issue?

[abingham]

The work I have is here if you want to look at it.

The work I did it for is mothballed for now, but I'll take a look at the work and see what kind of state it's in. It definitely did work quite well last time I used it.

[mristin]

Hi @abingham , Thanks for the update! Let's leave the issue open then. Even if you don't have time, perhaps somebody else might pick your source code and integrate it eventually.

[abingham]

That sounds good. If the project that precipitated my work comes back to life, I may have time to put towards integrating it with swagger-to.

[mristin]

@abingham I'll close the issue due to inactivity. I suppose the project has been closed. Please feel free to re-open the issue.