Openapi-generator: [REQ] [dart] add option to generate dart with dio library

[lingster]

I'd like to add new templates to generate dart code to use the dio http library instead of the http lib, as this library has additional useful features compared to the standard http lib.

In addition, I'd like to generate the output code so that it generates bloc code as I'm currently finding that I'm writing much boiler plate code which could be automated.

[auto-labeler[bot]]

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

[wing328]

@lingster thanks for the suggestions

cc @ircecho (2017/07) @swipesight (2018/09) @jaumard (2018/09)

[jaumard]

The title is not correct, it should be "Add a dart DIO generator" as it will not replace the one with http only.

That's a good idea, you can take example of what I've done to add dart-jaguar generator should be the same technic here.

But I'm not agree with generating bloc code, it's not the purpose of openapi generator, the purpose is to generate the network stack from a definition, it shouldn't force any particular architecture.
Most people don't use bloc as there is alternative (MobX, provider, redux...). If you generate bloc code that will prevent all users to use DIO generator if they don't want bloc architecture.

IMHO it's better to create a small build runner package to generate your bloc code, like this you can run it after the openapi generation if you want.

[wing328]

The title is not correct, it should be "Add a dart DIO generator" as it will not replace the one with http only.

Shall we take this opportunity to consolidate the Dart client generator with the library option instead creating a new one for every HTTP library available on Dart?

[lingster]

@jaumard : ok I agree with your point about bloc(title updated too), so it would be better to just have the dio code generated, and keep the code gen for architecture separate.

[jaumard]

@wing328 might be interesting indeed but they all have differences in the Java code too, not only in templates. Might be a huge refactoring for this no ?

[wing328]

Might be a huge refactoring for this no ?

Not sure. I've not reviewed the code yet.

We just did that for Ruby to add another library support: Faraday.

TypeScript is doing the same but there are too many HTTP libraries to support so it's definiltey not easy.

My suggestion is to do it earlier (now) to make a swappable ApiClient class and that will make our life easier afterward.

[wing328]

cc @nickmeinhold as well

[wing328]

To elaborate a bit more, for Ruby we only need to implement one function in the HTTP library template (e.g. faraday):

    def call_api(http_method, path, opts = {})

Ref: https://github.com/OpenAPITools/openapi-generator/blob/master/modules/openapi-generator/src/main/resources/ruby-client/api_client_faraday_partial.mustache#L5

It's not that hard to support multiple HTTP libraries.

[nickmeinhold]

It would be really cool to have a library option. I think chopper is pretty popular too (haven't used it myself).

So are we talking about a library cli option, with a new set of templates and a check in DartClientCodegen.java that determines which set of templates is used?

I've been working on a dart generator that creates the models as value types with built_value - I have it basically working and only made minimal changes to DartClientCodegen.java so I was thinking it could be a cli option. Anyway the point I'm trying to make is I would be interested in learning more about how to make a cli option and would be happy to contribute to a library option if that's what we're talking about.

Thanks!

[jaumard]

@wing328 not sure it will be that simple as (at least in jaguar) the parsing (so models) are also tight to the api calls. Also jaguar is supported JSON and Protobuf protocols. I had to change "a lot of" stuff in the Java to make it work.

I'm not saying it's impossible, just that is not trivial :)

[wing328]

@jaumard Agreed it's not trivial as you've made some features exclusively for Dart Jaguar generator.

What about using Jaguar as the Dart base generator and refactor it to allow a swappable API client class to support other HTTP libraries?

[wing328]

So are we talking about a library cli option, with a new set of templates and a check in DartClientCodegen.java that determines which set of templates is used?

@nickmeinhold most of the templates (e.g. models, README, etc ) will be shared among all HTTP libraries. Usually, it's the API client template that needs to be specified to a particular HTTP library.

[jaumard]

We can use dart jaguar as a base without problem, we'll still need a Java abstraction to handle particularities of the chosen http api I think, for example jaguar is using jaguar_serializer to do proto/json parsing where the raw dart is doing the parsing/mapping manually without third library.

So either we chose to use jaguar_serializer for all http libraries, or we will have different models templates per http libraries. I can understand that some user didn't want to use jaguar_serializer as it's an additional dependency

[wing328]

So either we chose to use jaguar_serializer for all http libraries, or we will have different models templates per http libraries.

For Java, the user can choose gson or jersey so I think we can do the same with Dart.

[nickmeinhold]

@lingster this would be really cool, are you working on this? I'd like to have a go at it but wanted to check with you first.

[lingster]

@nickmeinhold I've not started working on this yet as there's been a bit of discussion above on how best to tackle it. Feel free to give it a go in the meantime!

[nickmeinhold]

Awesome, thanks for the response! I was checking out Dio and really impressed. I'd like to start using it. I'll let you know if I get anywhere with adding it.

[ayushin]

@lingster I came to the same point that I'd like to see my bloc boiler plate to generated - did you make any progress on this?

By the way what's the problem with generating bloc classes by default and then just not using them if you don't want to? It creates no more overhead than the doc currently generated

[jaumard]

This one can be closed, DIO generator is done and live since a while now :)