Retrieve response headers

[aDogCalledSpot]

The whole topic is covered quite extensively here.

TLDR: The specification allows for receiving data from both the body and the headers of a response. The headers are part of the interface of the function and should be accessible to the caller.

[mrlubos]

@aDogCalledSpot Yeah, this is one of the main design flaws of the original package. We hope to resolve it with #308

Can you share your configuration?

[aDogCalledSpot]

Fair point... 😅

How do you envision offering the "raw" response? Wouldn't this also mean adding an extra indirection from which the "raw" response and the parsed response can both be accessed?

[mrlubos]

What do you mean by indirection? Regardless, we do have to return an object so that we can return all these new resources. I will update docs later today with Fetch API client beta, you can check it out then and let me know what you think?

[mrlubos]

@aDogCalledSpot here are the Fetch API client docs, mind giving it a try? You can also check out the demo if you don't have time right now. Would love to hear your thoughts!

[aDogCalledSpot]

I played around with it a bit (not extensively by any means) and I've noticed two things:

My query parameters in the backend use snake case (i.e. page_size). The generator maps these to the for TS more common camelCase (pageSize) for the types. However, they aren't mapped back when making the request. So my backend is receiving a query parameter called pageSize when it should be page_size.

The other one is very minor: VSCode can't seem to reason about the types being used in requests whereas that wasn't an issue before.

I'll work some more with it over the next few days and keep you updated.

[mrlubos]

Ah yes, I was planning to have a look at that. Thanks for confirming that's an issue. Are you able to provide details about the VSCode types issue?