WrapResponses in TypeScript Client

[ml-dev]

I would like to use the

• WrapResponses
• GenerateResponseClasses
• ResponseClass

settings when generating a TypeScript client. I see the settings are only available to the CSharp client generation.

I need to read the response headers for paging information and status codes.

[BringerOD]

Same here. +1

[ml-dev]

@RSuter Any timeframe on getting this feature worked into the TypeScript generator?

[BringerOD]

This is pretty import with restful services.

[quails4Eva]

I have implemented this for the Angular client in my branch, though I have only really tested it on the project I am working on and haven't tried all the different combinations of options. Are there some more examples I should test it on? Should I make a pull request?

quails4Eva@d3eddb7

[RicoSuter]

Looks good so far, please remove/do not commit the changes in the .tt autogenerated .cs files to make it more readable.. we should at least also support this for the fetch template. Thank you very much.

[RicoSuter]

Please create a PR and ill look into it.

[RicoSuter]

Ref: #891

[quails4Eva]

Thanks, done.

I did start looking into what's needed for Fetch, but only got about as far as realising that it isn't the same thing as Aurelia (I've been fairly busy recently).

[RicoSuter]

Ok, the feature is implemented in the master branch. Now we have to test this. Guys? :-)

[RicoSuter]

Please open specific issues if you encounter problems with this feature...

[RicoSuter]

Should be supported for all TypeScript templates

[RicoSuter]

And also added WrapResponseMethods setting

[quails4Eva]

I tested the new version and it seems to work fine for what I want.
I notice that the keys are all coming through as lower case regardless of the casing in the headers themselves, I guess this is probably deliberate?
I also notice that the header is now a plain object rather than an Angular Header object, presumeably for consistency with the other clients.
I don't have any problem with either of those, they were just the two things I had to update when using the new code.

[ml-dev]

This looks great! Thanks @quails4Eva and @RSuter for getting these change implemented!

[RicoSuter]

1. Using a plain headers object makes it easier to use it in all templates and id like to keep the api of the generated clients as technology independent as possible
2. The casing of the headers is not changed - it seems that angular converts them (?)

[RicoSuter]

Btw: You can use WrapResponseMethods to enable this feature for specific operations

[quails4Eva]

2. I Googled it and you are correct. I think the Angualr header class was probably ignoring the case of the keys I passed which was why my mixed case keys were working before.

[RicoSuter]

So the generated code is fine?

[quails4Eva]

Yes, it works fine for me.

[RicoSuter]

Do you think the casing is the same between different browsers? Otherwise we have to lower case all keys for safety...

[quails4Eva]

I have done some testing (and reading up).
Apparently Chrome always converts headers to lower case; Firefox, IE and Edge were not doing this in my testing. But headers are supposed to be case-insensitive so Firefox and IE are handling this some other way.

So to get it to work consistently across browsers you need to have some Header class that abstracts away the casing, or you can probably just lower case them all. Angular does the former, but if Chrome is lowercasing them anyway then you can never guarentee you are getting the original casing if you support Chrome, so lower casing should be fine.

[RicoSuter]

OK, I've created a new issue: #916

We should implement this fast to avoid breaking changes for users...