Improve m.request to simplify access response headers

[rickhall]

I was using m.request and I needed to access the response headers to access the etag to get the version of my requested entity to avoid overwriting concurrent changes with an "If-Match" header on my subsequent put request.

While adding headers to a request is easy with the headers option, the only way I could find to access headers was with the extract option. The downside with this approach is that I then had to start handling both the parsing and error handling of the server responses, which is not really germane to what I was trying to accomplish.

A simple approach to resolving this would be to return a slightly more complicated response object, for example, this is what axios returns:

{
  // `data` is the response that was provided by the server
  data: {},

  // `status` is the HTTP status code from the server response
  status: 200,

  // `statusText` is the HTTP status message from the server response
  statusText: 'OK',

  // `headers` the HTTP headers that the server responded with
  // All header names are lower cased and can be accessed using the bracket notation.
  // Example: `response.headers['content-type']`
  headers: {},

  // `config` is the config that was provided to `axios` for the request
  config: {},

  // `request` is the request that generated this response
  // It is the last ClientRequest instance in node.js (in redirects)
  // and an XMLHttpRequest instance in the browser
  request: {}
}

After some discussion about this topic on gitter, there may be other issues that could be improved (e.g., the overlapping nature of deserialize and extract), but I don't have enough experience with Mithril to comment on other improvements too deeply. At a minimum, making headers as easy to read as they are to set, seems like a reasonable enhancement.

[rickhall]

You could imagine implementing this in a non-breaking way. For example, add some sort of flag property to the request options to indicate whether you want a "full" response or not and default to sending the current "simple" response. However, I admit that making it a breaking change would result in a cleaner API.

[dead-claudia]

@rickhall

You could imagine implementing this in a non-breaking way. For example, add some sort of flag property to the request options to indicate whether you want a "full" response or not and default to sending the current "simple" response. However, I admit that making it a breaking change would result in a cleaner API.

Keep in mind, multiple prototypes like that would also bloat the bundle size, and that is a concern as well.

[duron600]

Maybe you can choose to use fetch() ?

[rickhall]

It is not that it isn't possible with m.request(), it is that is is more complicated than it needs to be. I might be able to use fetch(), but if I'm using m.request() everywhere else, then it would be sort of a bummer to have to do it differently in just this one case to access the response headers more easily. However, with that being said, I'm fine if this issue is closed due to lack of interest.

[borriglione]

I faced this problem now too.

I would like to use m.request, processing the response headers with an async function, but nevertheless keeping the same m.request XMLHttpRequest response handling like before. This is important as I would like to have the same resolve / reject handling like original https://github.com/MithrilJS/mithril.js/blob/main/request/request.js component to keep it compatible.

Currently I would need to duplicate this in my custom extract.

An interception function parallel to regular behavior onResponse: (xhr) => {...} would help me.