[typescript-fetch] Add support for file (application/octet-stream) response types

[macjohnny]

See swagger-api/swagger-codegen#8409

Solution: adapt PR swagger-api/swagger-codegen#8410

[Place1]

I've created a fork of typescript-fetch that fixes this issue and a bunch of others such as model property naming etc. I've already mentioned it in #347 but there seems to be a little bit of interest. Would this fork solve the issue for you? I'm keen to gauge interest :)

[macjohnny]

@Place1 thanks for the fork. I haven't tried it, yet.

but there seems to be a little bit of interest.

I wouldn't say that. I think any improvement is welcome and wanted.
I think it would be good to file a PR here that incorporates all your code, don't you think so @wing328 ?

[Place1]

i'll start working on a PR. Something I've done in my fork is make sure the generated client is a single .ts file which is quite different to what typescript-fetch currently does. What's the best practice for openapi-generator in this situation? Should I make my PR introduce a new generator to avoid causing a breaking change in the current typescript-fetch generator?

[macjohnny]

single .ts file which is quite different to what typescript-fetch currently does

We recently included a change to #363 to split the api up into separate files, as it can cause issues with inheritance if the files are all in the same file and in the wrong order, see #350

[Place1]

Perhaps the generator could alternatively support hoisting of all parent classes. It partially gives up on alphabetical ordering but there's a benefit in a single file output in terms of simplicity. This suggestion is for typescript-fetch

[macjohnny]

@Place1 I personally think that splitting the apis into multiple files does not add complexity, it adds simplicity, but apart from personal preference, if any technical problems can be sorted out, why not.

[macjohnny]

maybe @TiFu can give his opinion about this, too

[TiFu]

PRs which improve the structure of the generators are always welcome. Especially, the change proposed by @Place1 would make it easier to implement the redesign of all ts-generators, so I'd be happy to review it (which I'll do, later see the PR above).

I personally also prefer having multiple files - it makes searching for a specific API or model far easier.

Background: We want to unify all ts-generators into one generator, so that we don't have to copy bug fixes to 5 other generators. Having a better basis would make this work so much easier.

[Place1]

Background: We want to unify all ts-generators into one generator, so that we don't have to copy bug fixes to 5 other generators. Having a better basis would make this work so much easier.

This sounds great. How might it work with something like typescript-angular which is intrinscally very different; i.e. uses dependency injection, a dedicated HTTP client, Observables rather than promises and has multple 3rd party dependencies?

[TiFu]

The idea looks like this (feedback welcome):

https://gist.github.com/TiFu/44abab1bc3a430f7ecad5fed06416445
(you'll probably have to download the image - it looks weird on Github)

It's not very fleshed out, but in general, I'd like to try to isolate certain modules (e.g. HTTP) and hide them behind a common API so that every generator can just include whatever it needs, possibly removing dependencies. The other advantage is that this would allow us to implement the API once and then simply add framework specific code in an additional layer (e.g. for Angular), which just proxies the calls to the right methods of the underlying API.