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.
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:
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.